Well, smalltalk might be nicer but we code in Java. I prefer to always use 
parens unless all the operators are the same. I’m old so I can never remember 
the precedence order.

Ralph

> On Feb 10, 2017, at 11:32 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Fri, Feb 10, 2017 at 8:07 AM, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> 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?
> 
> It's one of the many things Smalltalk got right. Left to right, simple as 
> that. Different, yes, but simple.
> 
> Gary
>  
> 
> On 10 February 2017 at 09:36, Remko Popma <remko.po...@gmail.com 
> <mailto:remko.po...@gmail.com>> wrote:
> +1 on braces 
> 
> On Sat, Feb 11, 2017 at 12:35 AM, Apache <ralph.go...@dslextreme.com 
> <mailto: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 
>> <mailto: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>>
> 
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
> ggreg...@apache.org  <mailto:ggreg...@apache.org>
> Java Persistence with Hibernate, Second Edition 
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition 
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action 
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> 
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>

Reply via email to