如果您接管某人的项目进行简单更新,您是否遵循他们的命名惯例?我刚收到一个项目,以前的程序员到处都使用匈牙利表示法.我们的核心产品有一个命名标准,但我们已经有很多人多年来做自定义报告,并做任何他们想做的事情.
我没有时间更改代码中已有的所有变量名称.
为了继续他们的命名惯例,我倾向于可读性.
是的,我愿意.这使得在您之后继承它的人更容易遵循.如果真的很难理解,我会尝试稍微清理一下代码以使其更具可读性.
如果您没有将所有现有代码更改为您的标准,那么只要您更改这些文件,我就会坚持使用原始约定.在同一个文件中混合两种样式的代码会破坏一致代码风格带来的任何好处,而下一个人则不得不经常问自己"谁写了这个函数,它将被称为什么--FooBar()或fooBar( )?"
当您导入第三方库时,这种事情变得更加棘手 - 您不想重写它们,但它们的代码风格可能与您的代码风格不匹配.所以最后,你最终会得到几种不同的命名约定,最好在"我们的代码"和"他们的代码"之间划清界限.
我同意建议,只要代码内部一致,将代码保留为作者写的就可以了.如果代码由于不一致而难以遵循,那么您对未来的维护者(可能是您)有责任使其更清晰.
如果您花费40个小时来确定函数的功能,因为它使用命名不佳的变量等,您应该重构/重命名以获得清晰度/添加注释/做适合该情况的任何事情.
也就是说,如果唯一的问题是作者使用的大多数一致的风格与公司标准或你习惯的不同,我认为你浪费时间重命名一切.此外,如果原作者仍然可以提问,您可能会失去专业知识来源,因为他不再能够识别代码.