[sheepdog] [PATCH RFC] employ gnu99 style of GCC

[Hitoshi Mitake]

At Mon, 29 Apr 2013 17:41:27 +0800,
Liu Yuan wrote:
> 
> On 04/29/2013 05:15 PM, Hitoshi Mitake wrote:
> > This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
> > GCC. The main benefit of gnu99 is allowing interleaved statements and
> > declarations. 
> 
> The idea doesn't look appealing to me. This will increase the complier
> dependency and the payback is not that appealing.

sheepdog heavily depends on gcc already. e.g. struct
journal_descriptor employes  unnamed struct/union of GCC and we can
see many __attribute__ in sheepdog source tree. So I think we don't
have to care about compiler dependencies.

> 
> > sheepdog source tree has many functions with lots of
> > local variable declarations on their head part. They are harmful from
> > the perspective of readability. Basically, variable declarations
> > should be delayed until they are actually required. 
> 
> The readability is a much bigger topic than variable declarations.
> Something matters more is how well we structure the internal algorithm,
> abstractions and objects inside a subsystem, module or even a function.
> The variable declarations matters to you, in my opinion because you
> might assume a relatively big function such as more than 200 lines and
> more than 5 parameters and dozens of local variables, which I am
> personally highly against.

Of course I don't say variable declarations is the most important
problem for source code readability. Its role is very little. But I
strongly believe that variables with narrow scope can contribute to
the readability. e.g. If we write a variable used as an index in an
initializatoin part of for statement like this: for (int i = 0; ...),
we can forget about the variable when we are focusing on the outside
of the loop.

> 
> Most of time it is always easier to add statements into an existing
> functions to add more features or fix bugs, or just lazy to add helpers
> to abstract away the details because at the time one might think it is
> obvious to put it in a big function. Many reasons contribute to the
> bloated and hard-to-understand functions, but not the variable
> declaration. If we always have functions smaller than, say 30 lines
> (this is quite theoretical and just take it as a optional target), I
> don't think we'll have problems that your patch aims to solve.
> 
> So instead of playing with variables, we are better off if we fix the
> problems from the ground that if some functions doesn't looks
> self-explanatory and complex with too many lines, parameters, variables,
> it is the time to put it in a bigger picture and re-structure them.

Keeping each functions short and clean is one of the most important
thing for readability. Of course I don't disagree with this
opinion. But functions with less than 30 lines is not a realistic
target. e.g. sheep/cluster/corosync.c has some big switch statements
and they would be optimal forms.

Thanks,
Hitoshi