对大型代码库进行代码标准重构

时间:2008-10-15 22:43:53

标签: c++ refactoring

我的工作室拥有超过10年的大型代码库。我们开始使用的编码标准是在内部开发人员很少的情况下开发的,早在我们不得不担心与C ++相关的任何标准之前。

最近,我们在内部启动了一个小型R& D项目,我们更新了我们的编码惯例,使其更适合我们的环境。 R& D工作将集成到现有项目代码中。我们面临的一个主要问题是,我们现在对这两个工作领域有两个标准,现在代码库将会交叉。我不想在工作室有两个标准,我真的很乐意用一个标准来推进。 (我们如何进入这种情况的'如何'并不重要 - 只是我们是,而且我曾希望我们不会这样。)

问题在于重构现有代码。我不太热衷于有两个代码库(一个相对较小,一个非常大)看起来不同。我有兴趣对现有的一个代码库进行一些重构,使其符合其他标准。问题是,较小的代码库(IMO)是更令人向往的标准。

我开始寻找可以为我做大规模重构的工具。我对重新排列和收紧代码不感兴趣。我有兴趣改变像

这样的东西
class my_class {}
....
class my_class A;

class MyClass {}
....
class MyClass A;

基本上做功能/变量级重命名。我不想使用像Visual Assist这样的东西,因为这需要很长时间。我有超过10000个源/头文件,包含数十万行代码。一次使用VA一个班级将是一个时间杀手,不值得努力。

我确实在另一篇关于SO的帖子中遇到了Vera。这似乎可以完成这项工作并做得很好。我想知道是否有人具有使用Vera的特定经验,以了解我所处的情况,或者对可能完成工作的工具有任何其他建议。我认为这个工具实际上理解代码结构很重要,这样我们就不会以搜索/替换的方式重命名变量,因为如果不仔细的话,这会导致细微的错误。

编辑:虽然我的例子显示我将从名称之间使用_转换为camelcase类型表示法,但我们移动另一种方式可能更有利。我真的在寻找一种有助于大规模重命名的通用解决方案。

感谢。

6 个答案:

答案 0 :(得分:9)

我的过程是每次有人触摸给定模块时重命名。最终,所有模块都将被重构,但增量方法将导致更少的代码破坏(假设您有一套完整的测试。;)

答案 1 :(得分:2)

我使用自定义脚本进行了这样的更改。如果可以,我使用sed。否则,我将使用脚本语言,对正则表达式有很好的支持。这是一个粗暴的黑客,肯定会引入错误,但除非你找到更好的解决方案,否则这是一条前进的道路。

答案 2 :(得分:2)

除非你有(1)一套相当完整的可靠和自动化测试,以及(2)一个理解C ++语义的重构工具(我没有听说过这样的工具),否则我建议不要进行自动重命名。在我工作的每个地方,练习总是只重构你正在处理的模块。这是一个漫长而相对无痛的过程。

答案 3 :(得分:0)

我认为重命名变量会很棘手 - 幸运的是你会从_约定变为大写,所以它不会那么难(虽然_更容易阅读和更好)

我会使用代码美化器(例如Artistic StyleUncrustify)并修改它们以进行转换。您只需要一些自定义规则进行此转换,因此不会太难。

答案 4 :(得分:0)

恕我直言,变量重命名根本不值得努力。重要的是代码是健壮的,可读的和高效的。只需采用之前使用过的任何风格,并将时间花在重要的事情上。

答案 5 :(得分:0)

您可能需要考虑查看由Mozilla人员使用,创建和维护的“pork”,以进行大量自动化C ++源代码分析,包括refactorings等源代码转换。它可以使用JavaScript编写脚本,并支持相当复杂的语义分析和转换。所以重命名符号是猪肉更容易做的事情之一。

现在GCC plugins are on the way,将来这种事情可能会变得更加容易。