

Ask HN: Variable Declaration Location - PlanetFunk

I'm currently working on a project with a contract tech lead.<p>The tech lead is the same tech lead who developed the companies previous application and is well regarded.<p>The following code snippet is a bogus function the illustrates his variable declarations (all at the top of the function).<p><pre><code>  public virtual Token LogOn(Credentials credentials) {
    Token token;
    User user;
    token = null;
    if (ModelState.IsValid) {
      if (validateCredentials(out user)) {
        token = user.CreateToken();
      }
    }
    return token;
  }
</code></pre>
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.<p><pre><code>  public virtual Token LogOn(Credentials credentials) {
    Token token = null;
    if (ModelState.IsValid) {
      User user;
      if (validateCredentials(out user)) {
        token = user.CreateToken();
      }
    }
    return token;
  }
</code></pre>
The tech leads var dec  bugs me no end :P<p>Hell why bother declaring it in the function at all, GLOBAL VARS FOR EVERYONE!<p>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?
======
sparky
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...](http://google-
styleguide.googlecode.com/svn/trunk/cppguide.xml#Local_Variables) ) 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?

~~~
PlanetFunk
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.

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

~~~
scorpioxy
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.

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

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

