0

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
    ...
    }
ACoder
  • 1
  • This is for a single threaded application, and has no concurrency access etc. – ACoder Jun 19 '13 at 22:25
  • Is this in an embedded environment? – Idles Jun 19 '13 at 22:28
  • 1
    Yes, for a single threaded highly critical embedded product. And the code needs to conform to DO178b Level A standards – ACoder Jun 19 '13 at 22:32
  • 1
    The argument is that having excessive variable scope pollutes the namespace, and can potentially lead to bugs. – Oliver Charlesworth Jun 19 '13 at 23:30
  • If you are working on a resource-constrained embedded system and you are assigning many variables or structures of large size, then keeping them in scope way past their 'expiration date', you might have memory issues. You'd definitely have readability issues, and it'd be very very easy to introduce bugs. – reign_man Jun 20 '13 at 22:04
  • Say you wanted to have Block2Var and Block3Var both take on Block1Var's initial value, but somewhere between the assignment of Block2Var and Block3Var, Block1Var changes. Then Block2Var != Block3Var, when in reality, the two are intended to be equal. If Block1Var is *really* supposed to be a constant, it should be defined const or if it's a static formula, a #define, or maybe even a macro. – reign_man Jun 20 '13 at 22:08
  • Need more context. Are the blocks conditional? Is Block2Var simply an attempt at renaming Block1Var? Generally, the more variables you have, the more permutations you have to test. Proving that one variable is the same as another is proving that the assignment is superfluous -- so we'd have to hear the argument _against_ removing it. – sh1 Jun 27 '13 at 12:11
  • If the toolchain supports C99 and coding style guides don't prohibit this, I would suggest to define Block2Var in Block 2 only. Then, it is easy to read that Block2Var is only valid in Block 2, and Block1Var is only relevant as a link from Block 1 to Block 2. – HelpingHand Apr 27 '20 at 19:36

3 Answers3

1

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.

reign_man
  • 569
  • 2
  • 8
  • 21
0

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.

stdolan
  • 1
  • 1
  • 1
0

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".

HelpingHand
  • 1,294
  • 11
  • 27