0

我从事安全关键应用程序开发工作。最近，作为一名代码审查员，我抱怨如下所示的编码风格，但无法提出强有力的反对意见。那么反对这种变量冗余/重复的好论据是什么，我正在寻找可能导致问题或可能失败的测试用例的案例，而不仅仅是编码风格。

//global data
    // global data
    int Block1Var;
    int Block2Var;
    ...

    //Block1
    {
    ...
          Block1Var = someCondition; // someCondition is an logical expression
    ...
    }

    //Block2
    {
    ...
          Block2Var = Block1Var; // Block2Var is an unconditional copy of Block1Var
    ...
    }
4

3 回答 3

1

我认为更多的上下文可能会有所帮助。

您可能会争辩说 Block1Var 的值不能保证在并发访问/修改中保持不变。这仅在 Block1Var 发生变化时才有效（即不仅被读取）。我不知道您是否关心多线程应用程序。

可读性也是一个重要问题。未来的代码维护者不想跟踪一堆琐碎的任务。

于 2013-06-19T22:17:38.343 回答
0

取决于稍后对这些变量做了什么，但一个论点是它不是面向未来的。如果将来您更改代码以更改 Block1Var 的值，但稍后使用 Block2Var（没有额外更改），那么这将导致错误行为。

于 2013-06-19T23:31:39.543 回答
0

如果显示的函数上下文达到一定长度（我假设已经丢弃了很多细节以创建此问题的最小可重现示例），那么下一步可能是创建一个新的（子）函数2. 这个子函数应该开始分配Block1Var（-> 实参）给Block2Var（-> 形参）。如果与函数的其余部分没有其他耦合，则可以剪切块 2 的其余部分并将其作为函数定义丢弃，并且只需要通过子函数调用替换分配。

我的回答是相当投机的，但我见过很多案例，这种策略帮助我标记有用的点，以便在开发后期拆分复杂的功能。当然，这种解释仅适用于开发的中间阶段，不适用于声明为“准备发布”的代码。

于 2020-04-27T19:34:56.393 回答