[haiku-commits] Re: another coding style discussion (was: r36596 - haiku/trunk/src/apps/packageinstaller)

  • From: PulkoMandy <pulkomandy@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 4 May 2010 16:19:12 +0200

What about setting up a bot to detect these using the checkstyle
script ? Somewhat I feel it less aggressive to get notices from a bot
than from a dev ...

2010/5/4, Stephan Assmus <superstippi@xxxxxx>:
> On 2010-05-04 at 15:37:21 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> wrote:
>> Stephan Assmus <superstippi@xxxxxx> wrote:
>> > > To me this is clearly a single line statement "continue;", the
>> > > condition readability is another thing.
>> > This isn't directed at you in particular, Jérôme, but I have to say
>> > that I
>> > find these coding style discussions often frustrating and ridiculous.
>> > I absolutely agree that everyone should follow the style, and I am
>> > happy to
>> > point out style issues in patches from newcomers and even oldtimers.
>> > I
>> > dislike when code gets checked in that doesn't follow the style, but
>> > it's not
>> > the order of headers and similar things like how many blank lines
>> > after the
>> > copyright and whatnot that I find annoying. After a certain point it
>> > just
>> > gets ridiculous and counter-productive.
>> There is no problem as long everyone stick to it. It only gets
>> problematic if people don't adhere to it. Since having a coding style
>> is definitely worthwhile IMO, I don't see much room for alternatives
>> here.
>> The only thing really counter-productive is talking about it on this
>> level IMO.
>> >  As you point out yourself, you
>> > reserve judgement on readability of the multi-line if clause. That I
>> > always
>> > interpreted the rule the way I did is a clear indication that the
>> > coding
>> > guidelines are not clear "enough".
>> Such is language, but as I said earlier, in this case the coding style
>> guide is pretty specific IMO.
> Ok, sorry this gets me so frustrated, but it's probably just the drop that
> spills the barrel. Here is the excerpt from the style guide:
> The two examples which indicate braces are needed for multi-line conditions:
> if (someVeryVeryLongConditionThatBarelyFitsOnALine
>       && someOtherCondition) {
>       // && operator on the beginning of the next line,
>       // indented by a tab
>       ...
> }
> if (someVeryVeryLongConditionThatBarelyFitsOnALine
>       && (someVeryLongNestedConditionPart1
>               || someVeryLongNestedConditionPart2)
>       && lastPartOfSomeVeryVeryLongCondition
>               != 0) {
>       // indent one tab per expression level
>       ...
> }
> The examples for omiting braces:
> // omit braces for single line statements, place statement on a new line
> // (but always use braces around multi-line statements)
> if (condition)
>       DoOneThingOnly(index);
> for (int32 index = 0; index < count; index++)
>       DoOneThingOnly(index);
> Can you please just admit that this can easily be interpreted the way I
> did, *especially* since you used the term "statement" for the condition
> yourself?
>> In other cases, feel free to improve it. If unsure, feel free to ask on
>> the list, and we'll sort it out together. If you like to change
>> specific things, start a vote. The coding style is a formalism you can
>> easily get used to and follow.
> What I care about is to avoid being so pedantic as to scare away newcomers
> and this "I know the correct interpretation and you don't" attitude. Maybe
> Jérôme's original question was meant completely innocent or maybe he just
> wanted to point out I introduced a style violation. If it was the latter,
> then my interest is not about correcting an unclarity in the style-guide, I
> can care less about this particular unclarity. But my point is that it's
> unnecessary to point out this particular "violation" and similar
> non-important stuff. Yes we both agree having a style guide is important,
> but there are clearly more important violations and less important
> violations. Obscure variable naming is annoying, as well as violating the
> 80 char/line rule, spacing and capitalization. Those violations are hard to
> fix, because you have to edit the whole file and it's undeserved pain and
> precious time lost. However if there are one or two blank lines after the
> copyright is completely unimportant, as is the question if someone got the
> header sorting wrong with regards to what is considered more public or less
> public. You admitted yourself that you usually don't care that Ingo and I
> use braces for multi-line if-statements where only the condition is
> multi-line. So it's clearly something that is not important. Hence it
> doesn't need pointing out.
> As you can see from one reply in the short time already, being so pedantic
> *does* some damage to the project. If the majority thinks being too
> pedantic is not helpful, I hope you can live with this as well, just as I
> will shut up when the majority of developers agrees every little violation
> needs to be pointed out, and the style-guide needs clarification whenever
> it becomes apparent that there is even a small chance for
> misinterpretation. What do you think, will we need a vote?
> Best regards,
> -Stephan

Adrien Destugues / PulkoMandy

Other related posts: