Ask HN: Variable Declaration Location | Hacker News Reader

Ask HN: Variable Declaration Location

8 pointsPlanetFunk7 comments

I'm currently working on a project with a contract tech lead.

The tech lead is the same tech lead who developed the companies previous application and is well regarded.

The following code snippet is a bogus function the illustrates his variable declarations (all at the top of the function).

  public virtual Token LogOn(Credentials credentials) {
    Token token;
    User user;
    token = null;
    if (ModelState.IsValid) {
      if (validateCredentials(out user)) {
        token = user.CreateToken();
      }
    }
    return token;
  }

I've always declared my variables within the smallest scope possible. If later it needs to be accessed higher up, then it gets moved during the code change/refactor.

  public virtual Token LogOn(Credentials credentials) {
    Token token = null;
    if (ModelState.IsValid) {
      User user;
      if (validateCredentials(out user)) {
        token = user.CreateToken();
      }
    }
    return token;
  }

The tech leads var dec bugs me no end :P

Hell why bother declaring it in the function at all, GLOBAL VARS FOR EVERYONE!

Am I just being anal retentive? Am I wrong? Is it something I should address, conform with (at least in this project) or do I need to build a bridge and get over it?

It is a bit anal retentive, but there is sound reasoning behind declaring your variables in the narrowest scope possible. Google's C++ style guide ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... ) captures some of them. Another is cache locality of your stack, if you are in a language or project where that matters; by creating space on the stack as late in the game as possible, your stack access pattern tends more to the end of the stack than if you declare everything up top in no particular order. This is a really small micro-optimization though; the main point is that you want to know what type something is and what might have been passed to its constructor, on the screen at the same time as the code that uses it.

Another thought; if there is a mammoth difference between top-of-function and narrowest-scope-possible, that suggests that you may have very large functions, and might consider refactoring so that the difference between your method and his is small?

Thanks for the comment. Although I think there's good reason for declaring variables in the narrowest possible scope, I'm not sure it's enough of a reason to bring it up - especially if it's more about coding style, rather than best practice.

The size of the functions isn't really an issue, but I see your point.

If they're as small as the examples above, it doesn't make much difference.

For primitive types, a modern compiler's dependency analyzer can get better stack locality than anything you can do. Therefore I like to put all primitives at the top so they are easy to find.

Mutable composite types that use the heap should be scoped broadly, to reuse their heap buffer without touching the memory allocator. Example: C++ std::string.

Immutable heap composites could be scoped narrowly to reuse heap as soon as possible. On the other hand that reduces locality of reference for the deallocator code, and probably spams the branch predictor. If the immutable is small and deeply nested, it should probably be broadly scoped because branch prediction is made of solid gold (unless the language is garbage collected, making deallocation branchless).

Hmm... That got complicated. Stick them all at the top unless you are optimizing a nested loop.

Maybe its just an old C (C90 I think?) habit where declarations and code could not be mixed.

Yeah, I tend to do that too. And I did get it from when I was coding some form of C about 8 years ago. I think at the time I was using gcc 2.95 or something and it only allowed var declarations to be at the top. I sort of got used to it. Now I actually prefer it because when I am reading a new function, you get to see all the used variables and their comments right at the top.

Also, declaring variables at the top helps with languages that don't have block scopes.

Narrowest scope seems to be pretty standard practice, as long as that jibes with the language (ex. javascript's function scope).

But...there are probably more important battles to choose to fight during your project.

pet peeve alert!

I also prefer declaring all variables at the start of a function. My rationale is that, if all functions are written that way, it's less cognitive load when reading them. All variables used are known at the beginning, and once I've digested that, I can think about the code that will be working with them. These days, if I'm reading a function and a new variable is declared partway in, I feel like I've been ambushed with a new thing that makes it harder to understand.

That said, I tend to write such short functions that it's never an issue. If a particular variable isn't needed until halfway into the function, that's a good sign to me that it needs to be broken into two or more smaller functions.

Reply on news.ycombinator.com