Что такое сильный аргумент против переменной избыточности в коде c

Question

Я работаю в области разработки критически важных приложений. Недавно, как рецензент кода, я жаловался на стиль кодирования, показанный ниже, но не смог убедительно обосновать его. Так что, что было бы хорошим аргументом против такой переменной избыточности / дублирования, я ищу случаи, когда это может привести к проблемам или контрольным случаям, которые могут потерпеть неудачу, а не просто стиль кодирования.

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

Answer 1

Я думаю, что немного больше контекста было бы полезно, возможно.

Вы можете утверждать, что значение Block1Var не гарантируется тем, что оно остается неизменным при одновременном доступе / модификации. Это действительно только в том случае, если Block1Var когда-либо изменяется (т.е. не только для чтения). Я не знаю, интересуетесь ли вы многопоточными приложениями или нет.

Читаемость также является важной проблемой. Будущие сопровождающие кода не хотят прослеживать кучу тривиальных назначений.

Answer 2

Если показанный контекст функции достигает определенной длины (я предполагаю, что многие детали были отброшены, чтобы создать минимально воспроизводимый пример для этого вопроса), хорошим следующим шагом могло бы стать создание новой (под) функции из блока 2. Затем этой подфункции следует приступить к назначению Block1Var (-> фактический параметр) на Block2Var(-> формальный параметр). Если бы не было другого соединения с остальной частью функции, можно было бы вырезать остальную часть блока 2 и отбросить его как определение функции, и нужно было бы только заменить присвоение вызовом подфункции.

Мой ответ является довольно умозрительным, но я видел много случаев, когда эта стратегия помогла мне отметить полезные моменты для разделения сложной функции на более позднем этапе разработки. Конечно, такая интерпретация применима только к промежуточной стадии разработки, а не к коду, который заявлен как "готовый к выпуску".

Answer 3

Зависит от того, что будет сделано с этими переменными позже, но один аргумент в том, что это не будущее. Если в будущем вы измените код так, что он изменит значение Block1Var, но позднее будет использоваться Block2Var (без дополнительного изменения), то это приведет к ошибочному поведению.