On Fri, Feb 10, 2017 at 11:01 AM, Apache <ralph.go...@dslextreme.com> wrote:
> 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. > I'm all for parens. It makes maintenance so much easier. You write the code once, and it is read forever more. Might as well make your *intentions* be crystal clear. Gary > > 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> 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> 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> >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > <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 > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- E-Mail: garydgreg...@gmail.com | 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 Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
