[PATCH 4/4] Move the variable initialisations closer to use and add blanks

[Dirk Hohndel]

On Mon, 2013-12-16 at 10:08 -0800, Linus Torvalds wrote:
> On Mon, Dec 16, 2013 at 9:54 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> > Linus - if you have good reasons why we shouldn't do this, please speak
> > up.
> 
> I'm a big fan of the "loop variable in loop" declaration style, one of
> the few actual good C++ syntax changes. And I think moving
> declarations to the scope they are used in is generally a good idea
> (so in the case of prepare_dives_for_divelogs(), moving the "int i"
> and "struct dive" down is good regardless.

OK

> I'm no a fan of the "declare variables where they are used" model,
> because it tends to just encourage people to add crap to functions,
> and I think it makes it hard to see what the variables in a function
> are. For the kernel, we have that "if you need more than 5-10 local
> variables in a function, you're likely doing something wrong" model.
> Hiding variable declarations tends to just hide problems like that.

The questions becomes one of "how can we be consistent"? I'm a big
believer in consistency to make the code look the way you expect it to
look. That includes things like variable naming schemes, coding style,
indentation, but also "where are things declared"...

So you think loop variables are fine to be declared right in the loop,
but other variables should be at the top?

> But hey, it's personal. I much prefer to have local specialized inline
> functions and putting helper variables in those, for example. I would
> do that "Save the XML document into a zip file" as a helper function,
> for example, and *avoid* having that temporary buffer for the filename
> ("char filename[PATH_MAX];") in the middle of a larger function. And I
> would feel that *that* would add true readability, and that moving the
> variables to be mixed in with the code is actually a bad move.
> 
> So I feel - pretty strongly - that the whole C++ "mix code and
> declarations" model is crap, and largely brought on by bad coding
> styles that think that long functions that do several different things
> with lots of variables are somehow acceptable.
> 
> Of course, having seen how painful it can be to just add a small
> random helper function (because you need to declare it in another file
> etc), I can see _why_ C++ people seem to do it. I still think it's a
> sign of a disease, but I've grumbled enough about it. In the end, I
> don't tend to touch UI code in C++, so why should you care what I
> think?

Because I think you are a very smart and experienced developer. That's
why I explicitly asked you, Linus.

And this reminder about keeping functions short and sweet and have them
do ONE THING is a good one.

We should strive for this more. Yes, C++ and the way Qt does
translations makes this a bit more painful. But I still think we should
strive for smaller functions overall - functions where I can see quickly
a) what they do and hopefully b) that they are doing it right.

/D