什么是反对 c 代码中的变量冗余的有力论据答案

【问题标题】：Whats a Strong Argument against Variable Redundancy in c code什么是反对 c 代码中的变量冗余的有力论据
【发布时间】：2013-06-16 15:17:53
【问题描述】：

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

//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
    ...
    }

【问题讨论】：

这是针对单线程应用的，没有并发访问等。
这是在嵌入式环境中吗？
是的，对于单线程高度关键的嵌入式产品。并且代码需要符合DO178b A级标准
论点是过多的变量范围会污染命名空间，并可能导致错误。
如果你在一个资源受限的嵌入式系统上工作并且你分配了许多变量或大尺寸的结构，然后将它们保持在超过它们的“到期日期”的范围内，你可能会遇到内存问题。你肯定会遇到可读性问题，而且很容易引入错误。

标签： c code-standards safety-critical

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

【讨论】：