更新代码库以满足标准

在需要进行一些“真正的”更改之前,是否应将文件单独保存,然后进行更新?

这就是我要做的。

即使它主要是文本布局的改变,通过大规模的手工处理也有可能破坏正在工作的代码。

把它当作一个重构器,并在任何时候由于其他原因必须触摸代码时在本地进行。如果缺少测试,则添加它们以提高不破坏代码的几率。

如果测试已经很好地覆盖了您的代码,那么您可能会得到一些全局性的东西,但我仍然不支持它。

我也认为这是相当多的语言不可知论。

这还取决于你打算做什么样的改变来达到目的 你的 编码标准。每个人的定义 编码标准 是不同的。

更具体地说:

• 你所提议的项目变更是否能100%保证整个项目的工作与以前相同?例如,只影响注释、换行符和空白的更改应该是可以的。
• 如果你没有100%的担保,那么就有一个风险是不应该承担的,除非它能与利益相平衡。例如,是否需要更深入地了解当前的代码库才能继续其开发,或者修复其错误?编码约定的混乱是否妨碍了这些计划?如果是这样的话,评估成本和收益,并决定一次改造是否合理。
• 如果您需要了解当前的代码库,这里有一种技术:跟踪。
  • 复制代码库。请注意,跟踪涉及到添加代码,因此不应在生产副本上执行。
  • 在新副本中,插入多个 fprintf (trace)语句到任何被认为是关键的函数中。这可能是自动化的。
  • 使用各种输入运行项目,并收集跟踪结果。这将帮助每个人理解当前项目的设计。
• 理解当前代码库的另一种技术是记录项目中的依赖项。
  • 一些依赖关系(接口依赖性,C++包括依赖性,C++ TyWIFF/标识符依赖性)可以由自动化工具提取。
  • 只能通过跟踪或分析工具提取运行时依赖项。

我在想这是一项任务,你可以给一个有工作经验的孩子,或者把它交给租赁公司。

这主要取决于代码库的大小。

我见过三个受训者接受了一项任务,通过一个2Mloc代码库(几千个源文件),以便 在标准免责声明中插入一行 在所有源文件的顶部(行的内容取决于文件的名称和路径)。他们花了好几天时间。三个脚本中的一个大部分时间都用来写一个脚本来完成这项工作,后来只修复了脚本未能正确插入行的文件,另外两个只是浏览文件。(写剧本的人后来在那家公司找到了一份工作。)

手工调整代码库中所有这些文件以适应某些编码标准的工作可能需要用人年来衡量。
奥思,如果只有几十个文件,那肯定是可行的。

你的代码库很可能介于两者之间,所以你最好的选择是设置一个“工作经验的孩子”,看看是否有一个工具可以让你满意,如果有,让它工作。

在需要进行一些“真正的”更改之前,是否应将文件单独保存,然后进行更新?

我强烈建议不要这样做。 如果你这样做,你将有“真正的”变化与任何发生的重新格式化混合在一起,使它几乎不可能看到差异中的“真正的”变化。

您可以相当容易地处理编码样式的格式化方面。有很多 tools 它可以自动格式化代码。我建议将其中一个链接到版本控制工具的“签入”功能。这样,人们可以在编辑代码时使用他们想要的任何格式,但是当它被签入时,它将被重新格式化为正式的样式。

总的来说,我认为最好你能一次做大的改变。过去,我们做了以下工作: 1。在大多数人不工作的时候(例如晚上或周末),有一段时间专门进行重新格式化。 2。让一个人在那时签出尽可能多的文件,重新格式化它们,然后再次签入它们

对于仅重新格式化的修订版,您不必了解除了格式化之外还有哪些更改。