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

On Sun, 2010-09-12 at 18:50 +0200, Javier Jardón wrote:
> 2010/9/12 Matthias Clasen <matthias clasen gmail com>:
> > We don't have a written-down policy, beyond 'fit in locally'. But I
> > have become increasingly annoyed by trailing whitespace and mixed-in
> > tabs, since they do show up in my editor nowadays. So maybe we should
> > agree on a policy and put it in writing for 3.0.
> As a start point, we have an informal policy here: [1]
> [1]

I'm generally happy with all around GTK+ coding style (and I'd
like to avoid becoming part of the holy war that generally
ensues discussion of coding style).

If we're going to boil down a written statement, there's one
practical thing that generally irks me when integrating some 
patches (and admittedly it irks me when I'm in a hurry and forget 
to do this myself).

Generally I don't like working with functions that start this
way (and I admit I'm guilty of this too):

foo_do_something (GtkWidget    *widget,
                  GtkTreeIter  *or_something_thats_worth_checking)
    GtkFoo     *foo = GTK_FOO (widget);
    GtkFooPriv *priv = foo->priv;

    /* ... code starts ... */

The reason is that, often times I need to add some kind
of check to one of the arguments, making it utterly painful 
to go through the whole file and transform the whole thing to do: 

foo_do_something (GtkWidget    *widget,
                  GtkTreeIter  *or_something_thats_worth_checking)
    GtkFoo *foo;
    GtkFooPriv *priv;

    g_return_if_fail (VALID_ITER (or_something_thats_worth_checking));

    foo = GTK_FOO (widget);
    priv = foo->priv;

    /* ... code starts ... */

I think we could make our lives a little easier by just making 
it a policy that functions generally should not make those 
opening assignment statements.

Just a thought...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]