如果你接手了一个项目来进行简单的更新,你会遵循他们的命名规范吗?我刚刚接到一个项目,之前的程序员在所有地方都使用了匈牙利命名法。我们的核心产品有一个命名标准,但是多年来我们已经有很多人进行了自定义报告并按照他们自己的意愿进行操作。
虽然我没有时间改变代码中已经存在的所有变量名称,但我倾向于为可读性继续使用他们的命名约定。
虽然我没有时间改变代码中已经存在的所有变量名称,但我倾向于为可读性继续使用他们的命名约定。
是的,我这么做是为了让接手我的人更容易理解代码。如果难以理解,我会尽量清理代码,使其更易读。
我肯定会继续使用相同的命名约定,因为它将使代码保持一致(即使它看起来很丑),并且比混合变量命名约定更易读。人类大脑似乎非常擅长模式识别,您真的不想通过毫无意义地打破该模式来使大脑受到影响。
话虽如此,我并不是匈牙利命名法的拥护者,但如果这是您要使用的命名约定...
如果文件或项目已经使用一致的风格编写,则应尽量遵循该风格,即使它与您现有的风格冲突/矛盾。代码风格的主要目标之一是一致性,因此,如果您在已经一致(内部)的代码中引入不同的风格,则会失去这种一致性。
如果代码编写较差,需要进行某些清理才能理解,则清理风格成为更相关的选项,但只有在绝对必要时才应这样做(特别是如果没有单元测试),因为您可能会引入意外的破坏性更改。
是的。我实际上在我的现任公司创建了一个标准文档,其中包括以下内容:
现有的代码优先于所有其他标准和惯例(无论它们是行业标准还是此文档中找到的标准)。在大多数情况下,您应该将您的代码变成与同一文件中的现有代码匹配,原因如下: