svn commit: r190098 - in head/sys/sparc64: fhc sparc64

[M. Warner Losh]

In message: <49C63E34.4030303 at gmx.de>
            Christoph Mallon <christoph.mallon at gmx.de> writes:
: M. Warner Losh schrieb:
: > In message: <49C5F88C.3070600 at freebsd.org>
: >             Andriy Gapon <avg at freebsd.org> writes:
: > : on 22/03/2009 01:57 M. Warner Losh said the following:
: > : > I'll point out that style(9) doesn't say use as few local variables as
: > : > possible...  That part is completely unspecified.
: > : 
: > : But it does say:
: > : Do not put declarations inside blocks unless the routine is unusually
: > : complicated.
: > 
: > Yea, so?  Just put them at the top of the function where they belong
: > and don't worry about it.  Christoph has a long reason why this isn't bad.
: 
: Maybe I misunderstand your sentence here, but I'm *against putting all 
: declarations at the top* of the function and I'm *for declaring and 
: initialising* variables right where you need them.

: > : "unusually complicated" is, of course, a very subjective measure.
: > : But still this guideline contradicts typical guidelines for C and its
: > : offspring which name we do not say to declare variables as close to
: > : their first usage as possible.
: > 
: > thousands of lines is unusually complicated.
: 
: So every function of FreeBSD's kernel is trivial? Or is "ordinary 
: complicated" not a reason enough for better readability?

Maybe I'm exaggerating a little.  Anything more than "one screen"
which is to say about 100 lines starts to get complicated.  In those
simple cases, having the variables in multiple places is just
distracting....  But clearly we differ on this point..

: > : E.g. you can have a simple 3 line block where you need a local variable
: > : but that block is located 50 lines from start of an enclosing function.
: > : Very convenient when you need to quickly glance the variable's type (not).
: > 
: > No you don't.  There's absolutely nothing wrong with putting them at
: > the top.  In fact, it is simpler, really, than having to go hunting
: > for dozens of different declarations.  As someone who has spent a lot
: > of time looking at code, the time wasted looking for these damn-fool
: > things really adds up.
: 
: I fully disagree. I prefer seeing the declaration right where the 
: assignment/initialisation is instead of hunting for it two pages up. 
: Also for the rare case that you cannot directly spot the declartaion a 
: few lines up, every editor/IDE I know, which is more advanced than ed, 
: has a "jump to declaration" key combination and I prefer when it just 
: moves a few lines up instead of two pages and puts me totally somewhere 
: else. E.g. for vim the key combination is "gd". Others (e.g. Eclipse) 
: highlight the declaration when you move the cursor over a use of the 
: variable and if it is two pages up you do not see the highlight.

The problem is when things get really complicated and you have an
expression that's made up of, say, 10 different things.  Some scope
local, some next scope out local, some local to the function, some
parameters to the function and some global variables.  Where do you
find them all?  Even with the navigation aides, this can be
non-trivial.  Especially with global variables.  vim certainly doesn't
cope with that if they are declared outside of the file.

I've also had problems where nested scopes shadowed greater scopes'
variables.  This isn't so much a problem since compilers started
whining about this, but I've been burned by junior people cut and
pasting code from one place and slamming it into another without
thinking.  I guess spending half a week tracking this sort of problem
down a couple of times makes it a hot-button for me :).  Of course,
times do change, so maybe I should reevaluate my stance.

: > The original point is valid: the code changes obfuscated perfectly
: > readable code for no gain in the object code.
: 
: I agree here, but probably for mostly different reasons.

Most likely.

Warner