Okay. I've reverted the change and added the parentheses back.
Scott's suggestion to disable the PMD error is non-trivial. The PMD plugin uses
a concept of rulesets to detect issues. By default, a stock set of rulesets are
specified. AFAICT, you can't specify a single ruleset to override one stock
ruleset and also keep all existing stock rulesets. You have to re-enable all
rulesets you want in your own ruleset file. If the stock rulesets change to
reflect something new that the PMD folks discovered, you won't get it unless
you also update rulesets.
This is unfortunately different from FindBugs. The FindBugs folks seemed to
have gotten it right: you can define EXCLUSIONS of certain rules in certain
methods or classes. The only "exclusions" you can define with PMD are to
exclude an entire file from any scanning at all...not a good solution.
Nick
On May 13, 2013, at 4:08 PM, Ralph Goers wrote:
>
> On May 13, 2013, at 1:47 PM, Nick Williams wrote:
>
>> I'm confused. Does this mean the consensus is that I should add the
>> parentheses back in? Ralph says:
>>
>>> Anybody who thinks they understand something but doesn't is just going to
>>> be plain dangerous.
>>
>>
>> I say that's exactly why the parentheses should be left out. Putting them
>> back in perpetuates that danger by making that dangerous person think he's
>> right.
>
> Using parens says - maybe I don't know what the precedence order is or maybe
> I don't care but with the parens specified I know what I am going to get
> regardless. With the parens in it doesn't matter who is "right" since the
> parens aren't going to go away. Hence, there is no danger.
>
> Ralph
>
>
>>
>> Nick
>>
>> On May 13, 2013, at 1:22 PM, Ralph Goers wrote:
>>
>>> I'll be honest and admit that I overuse parens a lot because I don't ever
>>> want to have to remember precedence rules. So I will always do (a * b) /
>>> c or (a / b) * c regardless of the whether they are needed or not. The
>>> same is true of logical operators - unless they are all the same. I don't
>>> really follow the logic of the guy who misunderstands precedence rules and
>>> removes the parens as there is something wrong with that picture. Anybody
>>> who thinks they understand something but doesn't is just going to be plain
>>> dangerous.
>>>
>>> Ralph
>>>
>>>
>>> On May 13, 2013, at 9:50 AM, Remko Popma wrote:
>>>
>>>> +1 on extra parens
>>>> Teachable moments always seem to happen on Friday night when you really
>>>> want to go home but it. just. doesn't. work...
>>>> Not a fan. :-)
>>>>
>>>> From: Scott Deboy <scott.de...@gmail.com>
>>>> To: Log4J Developers List <log4j-dev@logging.apache.org>
>>>> Sent: Tuesday, May 14, 2013 1:27 AM
>>>> Subject: Re: "Useless parentheses?"
>>>>
>>>> I'd prefer if we leave the extra parens. IMO clarity trumps teachable
>>>> moments. Just disable the warning?
>>>> On May 13, 2013 8:26 AM, "Nick Williams" <nicho...@nicholaswilliams.net>
>>>> wrote:
>>>> It's not 100% harmless, but it is harmless as far as operation of the code.
>>>>
>>>> To understand how it could cause "harm", consider the situation where
>>>> another developer who understands precedence incorrectly happens across
>>>> the code and sees these parentheses. Seeing these parentheses will
>>>> solidify his incorrect understanding of precedence. If, however, he sees
>>>> it without parentheses, it will not make sense to him, and he will have to
>>>> look up Java operator precedence to understand why it works.
>>>>
>>>> An unlikely scenario, to be sure, but that's enough to make me remove the
>>>> parentheses.
>>>>
>>>> Nick
>>>>
>>>> On May 13, 2013, at 10:21 AM, Jess Holle wrote:
>>>>
>>>>> I'm guilty of that weird (and useless) style -- for me it's an old habit
>>>>> from C days where I frequently defined a return(X) macro when doing
>>>>> certain types of troubleshooting.
>>>>>
>>>>> While this case is useless, it's also harmless.
>>>>>
>>>>> On 5/13/2013 10:14 AM, Gary Gregory wrote:
>>>>>> The parentheses are useless to the compiler because && takes precedence
>>>>>> over ||. The parentheses are useful to humans who have not memorized
>>>>>> Java operator precedence ;)
>>>>>>
>>>>>> This warning is useful to catch weird style choices like "return (foo +
>>>>>> bar);" I've seen other odd choices in parentheses styling.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>> On Mon, May 13, 2013 at 11:09 AM, Nick Williams
>>>>>> <nicho...@nicholaswilliams.net> wrote:
>>>>>> The PMD inspector says the following if statement contains "Useless
>>>>>> parentheses."
>>>>>>
>>>>>> if ((isEventTimestamp && isLiteralValue) || (isEventTimestamp &&
>>>>>> isPattern) || (isLiteralValue && isPattern)) {
>>>>>> LOGGER.error("The pattern, literal, and isEventTimestamp
>>>>>> attributes are mutually exclusive.");
>>>>>> return null;
>>>>>> }
>>>>>>
>>>>>> I'm all for removing useless parentheses; unfortunately, I don't see how
>>>>>> these are useless. The way I see it, if isLiteralValue is false, with
>>>>>> parentheses it will (correctly) continue to evaluate after the first
>>>>>> grouped condition but without parentheses it would (incorrectly) short
>>>>>> circuit after the first use of isLiteralValue.
>>>>>>
>>>>>> Am I missing something here? Or is this a PMD bug?
>>>>>>
>>>>>> Nick
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> JUnit in Action, Second Edition
>>>>>> Spring Batch in Action
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
