CODEWITHSUNDEEP
ccode-standardssafety-critical
ACoder
ACoder

Reputation: 1

Whats a Strong Argument against Variable Redundancy in c code

I work in safety critical application development. Recently as a code reviewer I complained against coding style shown below, but couldn't make a strong case against it. So what would be a good argument against such Variable redundancy/duplication, I am looking for cases where this might lead to problems or test cases which might fail, rather than just coding style.

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

Upvotes: 0

Views: 220

Answers (3)

HelpingHand
HelpingHand

Reputation: 1468

If the shown function context reaches a certain length (I'm assuming a lot of detail has been discarded to create the minimal reproducible example for this question), a good next step could be to create a new (sub-)function out of Block 2. This subfunction then should be started assigning Block1Var (-> actual parameter) to Block2Var (-> formal parameter). If there were no other coupling to the rest of the function, one could cut the rest of Block 2 and drop it as a function definition, and would only have to replace the assignment by the subfunction call.

My answer is fairly speculative, but I have seen many cases where this strategy helped me to mark useful points to split a complex function later during the development. Of course, this interpretation only applies to an intermediate stage of development and not to code that is stated to be "ready for release".

Upvotes: 0

stdolan
stdolan

Reputation: 1

Depends on what's done with those variables later, but one argument is that it's not future-proof. If, in the future, you change the code such that it changes the value of Block1Var, but Block2Var is used instead (without the additional change) later on, then this will result in erroneous behavior.

Upvotes: 0

reign_man
reign_man

Reputation: 569

I think a little more context would be helpful perhaps.

You could argue that the value of Block1Var is not guaranteed to stay the same across concurrent access/modification. This is only valid if Block1Var ever changes (ie is not only read). I don't know if you are concerned with multi-threaded applications or not.

Readability is an important issue as well. Future code maintainers don't want to have to trace around a bunch of trivial assignments.

Upvotes: 1

Related Questions