我无法编程，因为我使用的代码使用旧的编码样式。这对程序员来说正常吗？

我是程序员，是第一份真正的工作，但是由于使用的编码风格，我无法解决任何问题。这里的代码：

• 没有评论
• 没有功能（依次执行50、100、200、300或更多行）
• 使用很多if带有很多路径的语句
• 有变数，就没有任何意义（例如：cf_cfop，CF_Natop，lnom，r_procod）
• 使用旧的语言（2002年的Visual FoxPro 8），但2007年有新版本。

我感觉自己已经回到了1970年。对于熟悉OOP，干净代码，设计模式等的程序员来说，以这种老式方式进行编码遇到麻烦是正常的吗？

编辑：所有的答案都很好。对于我的（未）希望，看来世界各地有很多这种代码库。所有答案中提到的一点是重构代码。是的，我真的很喜欢这样做。在我的个人项目中，我总是这样做，但是...我无法重构代码。程序员仅可在其设计任务中更改文件。

旧代码中的每个更改都必须在代码中保留注释（即使使用Subversion作为版本控制），还要保留与该更改相关的元信息（日期，程序员，任务）（这变得一团糟，其中的代码包含3条使用过的代码行和50条代码旧行评论）。我认为这不仅是代码问题，而且是软件开发问题的管理。

好吧，我会直率的。那是一个糟糕的工作场所...我一直在这种情况下，通常以您被这段代码吞噬为结尾。大约一年后，您将习惯它，并且将失去对如何使用现代替代品更轻松，更可维护的方式以及在运行时更快地完成同一任务的把握。大多数情况下。

我离开了这样的工作场所，因为仅仅一个月后，我感到自己被拖入了一个古老的笨拙代码中。我试着去尝试，但决定不这样做。由于缺少日常练习，我无法使用简洁的代码并开始失去技能。任何现代方法都必须经过三层开发人员的批准，这从未发生过，因为这种想法是，当使用现代方法时，事情可能会破裂。当您不使用现代方法时出现的代码的脆弱性非常令人恐惧。

不要误会我的意思，在某些情况下，人们会过度设计解决方案，而我全都反对。但是，如果将其拖入80年代的编码约定和样式中花费大量时间，将会阻止您的进步，而且我认为这也将阻止职业发展机会。

再说一次，你必须要赚钱，所以有时候你不得不做你不完全喜欢的事情。在这种情况下，请注意倦怠症状并将编码转换为平凡的任务。

这种编码样式（如果您甚至想称呼任何一种样式）都是不好的编码样式。

可以用大多数现代语言编写具有描述性变量名称和合理流控制的简短函数（Visual FoxPro是现代的，是的）。

糟糕的代码库是您遇到的问题，仅此而已。

这样的代码库存在并且有很多-您在使用它们时遇到的问题证明了它们的糟糕程度（并且您接受了良好的培训）。

您可以尝试做的是改进您可以做的事情-重命名变量，提取通用性并将大型功能划分为较小的功能，等等...获取“ 使用旧版代码有效工作 ”的副本...

我在一个C＃项目中，其结构非常糟糕，与您描述的内容相距甚远。只是组合12个单独的功能（明显复制-粘贴）到一个采用一个单一的参数。

这并不是真正的“老式”，只是（当前）良好的设计实践并不总是那么流行。那只是不好的代码。错误的代码会使任何人的速度变慢。您最终习惯了，但这仅仅是因为您习惯了特定系统中的特定怪癖。给定一个新项目，您可能会发现全新的编写不良代码的方法。好消息是您知道如何识别这些代码的味道。

您能做的最大的事情就是不要传播问题。除非您的团队同意，否则不要将这些不良做法作为惯例。以不会强制重构的方式保持新代码的清洁。如果那很糟糕并且您有时间，请考虑进行重大重构...但是实际上，您很少拥有这种奢侈。

在解决问题时，请考虑添加注释，并在实际中进行一点点的改动。除非您是独自编码，否则需要与团队一起解决。如果没有约定，则应该花一些时间提出这些约定，并且如果您仍然定期维护它们，则可能会致力于缓慢地改进代码库。

如果找到一个带有错误变量名的完全隔离的函数，并且无论如何都要对其进行修复，则最好使变量名有用，然后重构ifs。除非您要重构大部分功能，否则请不要对通用功能进行更改。

• 没有评论- 在学习时将其修复
• 没有功能（依次执行50、100、200、300或更多行）

这可能源自代码的先前迭代。在这一点上，我要提防已经成为“功能”的相似代码块之间的细微差别。但是，不管这种类型的结构有多么糟糕，它的理解都很简单……所以我不确定您在哪里遇到麻烦。

• 使用很多带有很多路径的if语句- 我实际上不确定您的意思
• 具有没有意义的变量（例如：cf_cfop，CF_Natop，lnom，r_procod）-

我要用“重命名变量”位强调谨慎。您很有可能根本不了解这些术语，并且在这里呆了一段时间后，变量名会变得更加有意义。并不是说变量名也不会出现问题，但是，如果您知道站点上的常见缩写词是什么，那么您的示例看起来就很合逻辑。如果您是1人组成的团队，这显然不那么重要。

• 使用我不熟悉的语言（2002年的Visual FoxPro 8）- 这是您的问题，而不是代码的

在我看来，这是一个机会。

显然，您已经看到很多有关如何完成和管理问题的问题。您可以抱怨这全是垃圾，什么也做不了，也可以以此为契机，向雇主真正展示自己的价值。

现在，如果您向雇主求助并告诉他一切都需要改变，那将无济于事。因此，诀窍是玩一会儿，问很多问题，当您需要编写代码时，需要根据他们的规则和所有注释进行操作，因为您需要保留其他开发人员可以使用他们目前喜欢的任何系统了解最新信息，同时您可以进行明智的重构，这不会给您带来任何风险。您可以提取两种方法，如果您的语言支持，请介绍一些单元测试。当被问到为什么这样做时，或者被告知您做错了什么时，请避免在为自己喜欢的编码风格正确表达自己的立场的同时，进行防御或争论。例如，您可以参考诸如Bob Martin的Clean Code之类的书，也可以参考Programmers.SE上遇到的其他书籍，文章，甚至是问题和答案。在与您一起工作的人的眼中，您发现的任何有用的事实都可能有助于您超越自己的经验。

关于过多的注释，如果您要为变量和方法添加一些描述性名称，则可以清除其中的一些内容，但是您也许还可以为一个好的版本控制系统辩护，并使用它保留更改和日期等的记录，并使用一种工具来比较源文件的不同版本（如果您选择的VCS尚未附带）。

就像我说的那样，这是为开发团队的改进做出贡献的机会，这听起来好像有点迷失了方向。您有机会以熟练和知识渊博的人以及能树立榜样的人脱颖而出。这些都是好东西，可以在您以后的职业发展中为您提供帮助。

欢迎来到丛林！

不幸的是，经常开始在公司工作意味着开始面对这种情况，除非您为结构合理且组织良好的公司工作，否则这种情况很常见。

我的建议是：

1. 开始学习并熟悉：所使用的编程语言（Clipper / dBase）和环境（Visual FoxPro）

2. 阅读并分析代码库并开始对其进行注释

3. 组织/重构代码（解决顺序执行过多行的问题）

在面对类似的代码库时遇到问题是正常的，但是在尝试提高代码质量并为程序提供“您的联系”以改善代码库并使其成为更好的程序时，这可能会成为一个巨大的挑战...

要回答您的问题：是的，各地的人/公司都使用可能基于糟糕的代码构建的基础结构。当使自己陷入这种情况时，可能很难对付。

去年夏天，我作为实习生开发了一个应用程序，该应用程序将由特定部门的质量检查团队使用。QA团队使用许多独立的脚本（VBScript，Perl，Bash）在数据库等上运行测试，他们希望将它们全部整合到一个应用程序中。但是，与此相关的问题是，这些脚本在公司的其他地方使用（因此核心功能/变量名称无法更改），并且代码“添加到”了将近10年。堆积了很多废话。

不过，您可以执行以下操作：

1. 寻求帮助：您的同事虽然不得不看一下这段代码，但他们可能熟悉其特质。对您来说，令人困惑和困惑的东西对他们来说是完全可以的。所以寻求帮助！
2. 尽可能进行重构：如果您需要长时间查看/维护该代码，请尽可能进行重构。即使您正在运行查找并替换变量名，也有一点点帮助。我去年夏天实习的那家公司也遇到了使用cr脚的变量名的类似问题。只要有机会，我就可以通过细齿梳来梳理它们的代码，更改变量名，优化逻辑（例如，将各种功能组合为1），等等。只要有机会，就这样做！

就像在各处一样，只要代码的外部功能正常工作，内部的工作方式就无关紧要。

我将发表一些与此处许多响应者不同的评论。我的许多评论可能对您很明显，但无论如何都需要说。

• 在更改您不了解的代码之前，请务必谨慎。
• 如果您在团队环境中工作，请使用与团队成员一起工作的代码，然后在进行更改之前与他们讨论您的更改。没有人喜欢一个“孤单的枪手”来更改其他人都熟悉的代码。这并不是说您的更改不被保证或要做“正确”的事情。
• 采纳您的想法。让每个人都接受您的想法，然后您就可以利用团队的技能进行重构，而不必承担所有工作量。
• 获得管理层的支持。他们也许能够为您分配资金以重新构建代码。
• 与管理层交谈时，他们了解重构代码库的好处。更具可维护性的代码意味着更少的时间用于解决错误，添加功能等。这意味着具有成本效益的开发。更快的周转时间等

在不了解您所处环境的情况下，很容易添加纯编码，最佳实践建议。与您一起工作的人可能不想更改或分配时间来更改代码库，但是在跳入并更改所有内容之前（先天固有风险）尝试将其推销给所有人。

希望这可以帮助。

值得一提的是您编辑的评论

旧代码中的每个更改都必须在代码中加上注释，以及与该更改相关的元信息（日期，程序员，任务）（这变得一团糟，其中有3条使用过的代码行和50条旧使用过代码行的代码）。我认为这不仅是代码问题，而且是软件开发问题的管理。

我还有一个项目，在该项目中继承了遗留的FoxPro代码库，其中包含您描述的许多问题。我向项目介绍的第一件事是一个好的源代码存储库。FoxPro可以与SourceSafe集成，但是该产品使用起来很麻烦。

我获取了Paul McNett的scx工具http://paulmcnett.com/scX.php的副本，并将其集成到我的开发周期中。将二进制FoxPro代码提取为文本格式，然后可以将其放入源存储库（例如Subversion，Mercurial甚至git）中，做得很好。（您可能会发现http://vfpx.codeplex.com上的SubFox项目很有用。

这些工具提供了历史记录，并允许程序员继续维护代码。学习使用这些工具肯定需要花费一些时间，但是由于它们都是免费的，因此不花时间在其中就没有任何意义。（即使您无法使Job项目那样发展）。

我将非常同意funkymushroom的回答。如果您是团队环境，请确保其他人知道您正在重构或重组代码（如果您计划将来获得任何好的任务）。

从个人的经验，我知道了，而不是你的编码，如果您要维护的代码，另外也修改和维护，风格停留在原有代码的风格。添加评论和说明很好，但是应该保留基本布局和约定。该项目中的老领导/枪支们希望代码与他们多年来看到的代码相似。

当客户大声疾呼错误时，您的管理人员将竭尽全力尽快解决问题。如果这些老式的枪支在压力下发现您“清理了代码”，因此他们现在必须花时间找出您移动或重命名了他们知道需要调整的一个变量的位置，那么您在公司中的名称将更改为“泥”。

危机结束后，首先，老枪将慢慢责怪您进行重要更新。接下来，您会发现，只要在公司工作，就可以保持清理过的代码。最后，当新的有趣项目可用时，您的经理将询问专家，由谁来负责该项目，如果您一次将它们搞砸了，就永远不会将其加入新项目，直到最后将草料投入赶上最后期限。

如果您在大学里学习了“正确”的编码方式，而现在您已经加入了劳动力市场，那么请忘记这种“正确”的方式。这些不是大学的任务，这些项目不仅持续一个学期，而且可以持续数年，并且必须由一群对最新CS趋势具有不同水平的专业知识和不同水平的兴趣的人来维护。您必须是团队合作者。

您可能是学校最大的热门编程，但是在工作场所，您的第一份工作是，您的街头信誉为零。从事多年编程工作的人不会对您的学校或成绩有任何要求，这是您与他人的交往状况以及对他们的生活造成的破坏。

在我的20年中，我似乎被解雇了许多ace程序员，主要是因为他们要求以“正确”的方式做事。除非您为工作带来非常非常非常独特的东西，否则您将是可替换的。您可能曾经是班上的佼佼者，但明年，其他人将成为他们班上的佼佼者，并正在寻找工作。

我将其视为您的主要工作，就是保留您的工作，直到您决定更换工作为止。要保持工作，就意味着您必须在别人建造并付钱的操场上玩得开心。

我知道我听起来很消极，但总有希望。随着经验的积累，取得成功，您将获得影响力，并且能够将事情转变为更好的方式。在编写新代码或在新项目上时，请寻求所需的更改。如果是新代码，旧枪支们就不会期望它成为他们离开代码的方式，而当他们看到优势时，他们可能会学习并采用新方法。

旧系统可以更改，但是需要时间。进行更改会带来风险，并带来业务仇恨风险，您必须花一些时间和精力使公司对更改感到满意。