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

[Linus Torvalds]

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.

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.

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?

                Linus