Re: Minutes of the GTK+ Team Meeting - 2010-09-21

[Emmanuele Bassi <ebassi gmail com>]

On Thu, 2010-09-23 at 19:35 +0200, ecyrbe wrote:
> 
> 
> 2010/9/22 Emmanuele Bassi <ebassi gmail com>
>         Minutes of the GTK+ Team Meeting - 2010-09-21
>         
>         • coding style conventions
>         - proposal: adopt the Clutter document, as it codifies the gtk
>         + as well
>         - investigate an indent script to distribute with gtk+
>         
> 
> I know that these coding styles are already in action in a lot of gtk
> code.
> But, i have to say that i don't see the point of :
> 
> "Curly braces should not be used for single statement blocks" :
> - it's in my point of view a mistake to do this. It's error prone and
> hard to debug and know what was the intention of the developper here.
>  And also, making 3 exceptions to this in the documentation is making
> it not easy to learn. 
> - In the opposite, making curly braces mandatory, removes all mistakes
> and bad interpretation of the code.

there is only one canonical way of interpreting a single statement in C.
and in case of nested if's and for's, the rule is to enclose the outer
if or for with braces to remove ambiguity.

the other objection, "debug statements require toggling braces" is
easily dispatched with: if you're adding debugging notes then use the
conditional debugging facilities that gtk+ provides - GDK_NOTE and
GTK_NOTE - and don't remove them. if you feel the need to sprinkle code
with temporary printf()'s then you should really learn gdb.

> "In case of multiple statements, curly braces should be put on another
> indentation level"  and
> "While curly braces for function definitions should rest on a new
> line, they should not add an indentation level ":
> - this is a matter of taste of course. But i find it to be problematic
> for consistancy. Either do it for everything or not is a better idea.
> I think that curly braces should not be added in an indention level,
> only the embraced code.

this is never going to happen. gtk+ consists of hundreds of thousands of
lines of code - all more or less adhering to the same coding style,
which is in the process of being *ratified* to eliminate the gray areas.

is it so hard to stop arguing about coding styles and just *follow the
one that's already there*?

I understand (and advocate) picking a well documented coding style for a
new project, but if a project already has a well established one then
following it should *never* be a matter of preference.

let's stop right now this pointless discussion.

+++

in other, less controversial, news: I just pushed an uncrustify[0]
configuration file[1] that implements the Clutter coding style
document[2] to the Clutter repository. it's not perfect - no automated
tool will ever be - but at least gives a base for new contributions that
doesn't look obscenely out of place. I'll keep tinkering with it in the
next few days.

I guess that if gtk+ adopts the Clutter document it would be good to
also add the uncrustify configuration file. obviously, everyone is
welcome to provide an indent equivalent - though, AFAICS, uncrustify
provides more tweakables.

at some point we might even add a pre-commit hook that calls uncrustify
and fires up the mergetool[3].

ciao,
 Emmanuele.

[0] http://uncrustify.sourceforge.net/
[1] http://git.clutter-project.org/clutter/tree/build/clutter-uncrustify.cfg
[2] http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE
[3] http://github.com/thewtex/ITK/commit/c3f8aeda8d8ff8b7a3db25b3750ce538af3b9aee


-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi