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 http://pulkomandy.ath.cx