+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> > > >
