I believe there is consensus that the parens should be added back in.
On 5/13/13, Nick Williams <nicho...@nicholaswilliams.net> 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.
>
> 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
>>>>
>>>
>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
