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

[Paul Davis <paul linuxaudiosystems com>]

On Thu, Sep 23, 2010 at 6:58 PM, Emmanuele Bassi <ebassi gmail com> wrote:

> 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.

this isn't how debugging works, and i believe that you know this.

today i added about 20 debugging statements using g_print() to GTK.
later, i will submit a patch or commit a change based on what i found.
if i left in the statements that i put there, i would hear entirely
justified complaints about what i had done. using GDK_NOTE or GTK_NOTE
would not have changed those complaints in the slightest, and there
would be no justification for leaving them there.

of the 20 statements, 12 of them required me to add braces to avoid
breaking the code. gdb would not have been an appropriate tool to
debug the issue i was facing, and would be especially problematic in
some scenarios that i face quite often. i feel that i know gdb quite
well thanks, having been using it for 20 years.

> 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.

certainly true. but adding a new definition/documentation of a coding
style that explicitly prohibits

     if (this)
       {
          that();
       }

means that its not even possible to slowly move the codebase toward a
style in which this issue has less impact.

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

because the actual "argument" with the style doesn't occur in mailing
lists or on IRC - it occurs in actual practice, every time someone is
trying to understand a code path within GTK or GDK.

> I understand (and advocate) picking a well documented coding style for a

AFAIK, it hasn't been explicitly documented to date, hence this discussion.

i hate coding style discussions, just for the record. but i also think
that explicitly prohibiting a style of programming that makes certain
common tasks easier is even worse.