The "unnecessary parenthesis" rule is somewhat annoying. While it has good intentions, it'll also flag something like this:
foo || (bar && baz) Sure, && has higher precedence than || (had to look it up just now), but who can remember those kinds of rules anyways? On 10 February 2017 at 09:36, Remko Popma <remko.po...@gmail.com> wrote: > +1 on braces > > On Sat, Feb 11, 2017 at 12:35 AM, Apache <ralph.go...@dslextreme.com> > wrote: > >> You don’t really have to use final everywhere. If you don’t, Gary will >> fix it ;-) >> >> Actually, I really do prefer most of our check style rules, but not >> enough to yell and scream about it. The one that bothers me the most is >> that I want braces wherever they are optional. >> >> Ralph >> >> On Feb 10, 2017, at 8:09 AM, Matt Sicker <boa...@gmail.com> wrote: >> >> At work, I've switched from final everywhere to final everywhere but >> local variables while maintaining effective finality instead. I just wish >> Java had final be the default. >> >> On 10 February 2017 at 05:34, Remko Popma <remko.po...@gmail.com> wrote: >> >>> Generally agree except that we agreed that the final qualifier was >>> optional. This may not be easy (or possible?) to verify automatically >>> anyway. >>> >>> Otherwise all looks reasonable. >>> >>> Sent from my iPhone >>> >>> On Feb 10, 2017, at 17:55, Mikael Ståldal <mikael.stal...@magine.com> >>> wrote: >>> >>> Seems reasonable. >>> >>> On Fri, Feb 10, 2017 at 5:56 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> I agree with all that! :-) >>>> >>>> Gary >>>> >>>> >>>> On Feb 9, 2017 7:05 PM, "Matt Sicker" <boa...@gmail.com> wrote: >>>> >>>> I was browsing through the site and took a look at the component >>>> reports. Checkstyle alone seems close to pointless as there are over 200 >>>> errors in log4j-api alone. log4j-core has over 2000 errors. Even new files >>>> that were formatted with our formatter settings such as the >>>> CassandraAppender plugin have import ordering errors. I also disagree with >>>> some of the rules configured, but that doesn't really matter when we don't >>>> enforce it in the first place. >>>> >>>> Anyways, what's the point of configuring this and adding checkstyle >>>> comments yet not even using it? The only project I've come across in the >>>> wild so far that has checkstyle configured properly was Spring Boot, and >>>> your pull request has to pass the checkstyle check to even be mergeable. >>>> >>>> Perhaps if we wish to actually use it, we could loosen the rules down >>>> to a much smaller set that actually matches the formatter settings in >>>> src/ide/. If the rules matched our code base, then we could also have >>>> Jenkins run checkstyle checks which would keep us informed when we mess up, >>>> and it would also be useful for pull requests (I've had to reformat many >>>> patches in the past). >>>> >>>> Related, there's the style guide <https://logging.apache.org/lo >>>> g4j/2.x/javastyle.html> which I'm pretty sure I've never even looked >>>> at before. This could also be normalized with our formatter files. I've >>>> generally thought of our code style summarized as: >>>> >>>> * 4 space indent >>>> * use final >>>> * no star imports outside tests (and those should generally be static >>>> imports) >>>> * imports should be in some sort of alphabetical order (this is really >>>> difficult to match between IntelliJ and Eclipse for some reason; I've had >>>> rather obnoxious fights about this in the past thanks to >>>> import-order-induced merge conflicts) >>>> * try to stick to unix line endings, but we're rather mixed still >>>> * every file needs a license header unless it's impossible to include >>>> comments >>>> * use CamelCaseClassNames, even for acronyms >>>> * no hungarian notation or other distracting naming conventions >>>> * otherwise stick to typical Sun style that everyone basically >>>> recognizes (that the JDK doesn't even use itself) >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>>> >>> >>> >>> -- >>> [image: MagineTV] >>> >>> *Mikael Ståldal* >>> Senior software developer >>> >>> *Magine TV* >>> mikael.stal...@magine.com >>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>> <http://www.magine.com/> >>> >>> Privileged and/or Confidential Information may be contained in this >>> message. If you are not the addressee indicated in this message >>> (or responsible for delivery of the message to such a person), you may >>> not copy or deliver this message to anyone. In such case, >>> you should destroy this message and kindly notify the sender by reply >>> email. >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> >> > -- Matt Sicker <boa...@gmail.com>
