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



El 14/09/10 09:46, Tomeu Vizoso escribió:
> On Tue, Sep 14, 2010 at 09:14, Jon Cruz <jon joncruz org> wrote:
>>
>> On Sep 13, 2010, at 10:49 PM, Kristian Rietveld wrote:
>>
>>>
>>> To add to this, it does not specify how to deal with braces in nested if-statements.  When I start to nest if-statements (also with a single-statement body) I typically start adding braces, because it is a bit clearer and avoids the dangling else problem.
>>
>> Aside from the functional reasons to use braces even for single-line statements, using them make review and reading much simpler.
>>
>> If one just can go "here is an if statement, oops, the brace is missing" reading and reviews fly by. On the other hand, if one has to go "hmm... here is an if, let me look for a brace. No, I don't see one. Let me read and consider if this is a situation calling for one or not", then code reviews, reading, maintenance, etc. go significantly slower. Over the years I've consistently found it to be at least an order of magnitude slower, and more error prone.
>>
>>
>> And on the functional side, yes I've fixed many many bugs in many projects that have been caused by or missed due to lack of braces on single-lines.
>>
>> Oh, and nested if statements do get things quite complicated if the rule is to only use braces sometimes, instead of the simpler "use braces 100% of the time".
> 
> One more reason is that if braces are them from the start, they won't
> need to be added later and git-blame will be more useful.

+1 for Paul, Kristian and Tomeu.

To Jon's point, I would say it will be good to have this compromise:
* Always put braces.
* If you find a place where there is no brace, you can:
a) Fix it, if and only if your commit is already changing that line.
b) If there are lots of places where style rules are violated in the
file, and the maintainer agrees, do a pre-commit fixing the style
(stating very clearly that it shouldn't be changing behaviour), and then
do your commit with the meaniningful changes.

Regards,

  Andres

-- 



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