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 > <mailto: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 > <mailto:mikael.stal...@magine.com>> wrote: > >> Seems reasonable. >> >> On Fri, Feb 10, 2017 at 5:56 AM, Gary Gregory <garydgreg...@gmail.com >> <mailto:garydgreg...@gmail.com>> wrote: >> I agree with all that! :-) >> >> Gary >> >> >> On Feb 9, 2017 7:05 PM, "Matt Sicker" <boa...@gmail.com >> <mailto: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/log4j/2.x/javastyle.html >> <https://logging.apache.org/log4j/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 <mailto:boa...@gmail.com>> >> >> >> >> >> -- >> >> >> Mikael Ståldal >> Senior software developer >> >> Magine TV >> mikael.stal...@magine.com <mailto: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 <mailto:boa...@gmail.com>>
