10

At the place where I work, there are explicit guidelines for placement of declarations of variables. According to that, it is required to put them at the global level and / or at the beginning of functions, and not in inner blocks (such as a for loop). Since they've been specified by persons more experienced than I am, I'm sure that there must be a good reason for it, but I cannot figure out what that might be. It would be nice to know if there are any compile time / run time advantages at having them declared at a bigger scope.

TCSGrad
  • 1,362
  • 3
  • 11
  • 22
  • The main practical benefit is not where declarations are located, but that there is an agreement among all teammates about that.This is true for coding rules in general. – mouviciel Jan 13 '21 at 10:29

9 Answers9

8

I see two main advantages:

  • Reusing variable names with a different type is prevented.
  • It becomes clear at an earlier time that a routine needs to be refactored. The variables at the top become a major mess fairly quickly, and this mess is easy to recognize.

Any compiler worth its salt will optimize away the scope of the variables anyway, so it's purely a formatting concern.

For my two cents, I'd still prefer the innermost declaration of the variable to transport the intent of scope to the compiler. If you intended to have a variable only accessed within a loop, you can catch any later reference at compile time when you declare the variable in the loop.

thiton
  • 5,348
  • 1
  • 27
  • 26
  • Most compilers will happily warn about shadowing. See for example [gcc](//gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wno-shadow). – Deduplicator Jan 13 '21 at 01:16
3

The only advantage I have found so far is code simplicity. Youalways know where to look for variable declarations and everybody in the team adopts the same coding style. These things make code maintenance easier but I am not sure that they make writing better code any easier. I do not mean that you write worse code only that sometimes it is harder to write code as good. Nevertheless if the development team is big or its members change frequently using code standards is helpfull.

Gus
  • 368
  • 1
  • 4
3

This sounds like a decision to preserve consistency. It also prevents the use of same names for different variables in neighboring scopes and increase readability. As Gus points out, you'll also know where to look for variables. I think narrowest scope principle is better though because it prevents the variable clutter at the top. Outermost declaration is much like declaring private members of a class first IMO.

perreal
  • 341
  • 2
  • 8
3

Every language might differ in the preference of style and practice. Following is from JSF-AV-rules, which Stroustrup points to as the coding standards he prefers.

AV Rule 136
Declarations should be at the smallest feasible scope

The rationale for this is described as

This rule attempts to minimize the number of live variables that must be simultaneously considered. Furthermore, variable declarations should be postponed until enough information is available for full initialization

If you are in C++, declaring variable when you need them is preferred.

Deduplicator
  • 8,591
  • 5
  • 31
  • 50
Clark Gable
  • 129
  • 4
3

Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem: https://softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.

Community
  • 1
Johan
  • 131
  • 2
2

If the declaration is within an if clause that only rarely (if ever) gets exercised, but needs a lot of memory, your memory footprint is smaller (most of the time) than if you allocate everything at the beginning of the function.

If it is within a loop then you have to reallocate the memory repeatedly, this can be costly in performance terms.

There are reasons for doing things both ways.

NWS
  • 1,319
  • 8
  • 17
1

The old C-standard of 1989 only allows variable declarations at the start of a block.

Only since C99 declarations are allowed anywhere. Maybe your place hasn't made the switch to C99 yet.

Patrick
  • 1,873
  • 11
  • 14
  • We use C99 - but more importantly, I was looking for what are the implications of declaring it in the innermost block, rather than at beginning of function. Perhaps, I wasn't clear enough... – TCSGrad Nov 11 '11 at 15:09
1

Seems like those who made this decision are use to a time when putting declarations at the top was the norm and have chosen not to switch to a preference to declare closer to where it is being used.

I'm not sure how helful this level of consistency is. Some IDE's probably make finding things easier than others. For global variables this makes sense, but if your function is so long it makes finding variable declarations difficult, you have bigger problems.

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

I’d find that rule very unhelpful, and it leads to worse code and more bugs. In newer languages it is very bad. In Swift for example, and probably in other languages, it is a very good idea to have variables that only are assigned a value once - and that means they must be declared in a nested scope in practice.

gnasher729
  • 42,090
  • 4
  • 59
  • 119