Re: GTK+ policy (was RE:rendering-cleanup-next)

[Paul Davis <paul linuxaudiosystems com>]

On Mon, Sep 13, 2010 at 6:27 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> 2010/9/13 Thomas Wood <thos gnome org>:
>>
>> Clutter's (very detailed) coding style document may be useful here,
>> since it has a very similar coding style to GTK+:
>>
>> http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE
>>
>
> Yes, I think we could basically adopt this word-by-word.

i know that coding styles are, as it says in the clutter guide,
"arbitrary", but i would just like to mention one little detail that i
find problematic when working on shared projects (and much less so on
non-shared projects). this rule:

----------------------------------
Curly braces should not be used for single statement blocks:

  if (condition)
    single_statement ();
  else
    another_single_statement (arg1);
-----------------------------------

what's wrong with this? well, completely ignoring the risk of someone
redefining single_statement() into a multiline statement (macros are
noted as "to be avoided", not illegal), its something much more down
to earth: if you are attempting to debug somebody else's code (which
happens quite a bit when hacking the internals of GTK), this means
that if you want to add a debug trace for either (or both) branch of
the conditional, you have to *add* curly braces. when you're done, you
need to remember to remove them. so this style makes more work for
anyone trying to understand/debug the code, and also increases the
chances of patches/commits that violate the style guide. this happens
to me every time i'm working on GTK internals - i have to tediously
add braces and remove them. if they were already there, i would simply
be adding debug trace lines, and then deleting them.

anyway, i wasn't trying to start a style war - just a reflection that
distributed collaborative development has some different dynamics than
more personal or local projects. coding habits that make it easier for
other people to debug your code (even if that means adding debug
output statements) has always seemed like a good thing. i have no
actual position on whether the braces-always-present or not is
actually better programming in the abstract sense, only that they help
out when different people may need to make independent passes through
a chunk of code to debug/understand its logic/operation.

--p