On 16/05/13 16:58, Tom Hacohen wrote:
> On 16/05/13 16:31, Rafael Antognolli wrote:
>> On Thu, May 16, 2013 at 10:45 AM, Christopher Michael
>> <cp.mich...@samsung.com> wrote:
>>> On 16/05/13 14:43, Daniel Juyung Seo wrote:
>>>> On Thu, May 16, 2013 at 7:00 PM, Tom Hacohen <tom.haco...@samsung.com> 
>>>> wrote:
>>>>> On 16/05/13 14:24, Christopher Michael wrote:
>>>>>> On 16/05/13 14:19, Tom Hacohen wrote:
>>>>>>> On 16/05/13 14:17, Christopher Michael wrote:
>>>>>>>> On 16/05/13 14:14, Tom Hacohen wrote:
>>>>>>>>> On 16/05/13 14:06, Christopher Michael wrote:
>>>>>>>>>> On 16/05/13 14:06, Jérémy Zurcher wrote:
>>>>>>>>>>> sorry, but what are those formatting changes ??
>>>>>>>>>> Removing the parens that were there.
>>>>>>>>>>
>>>>>>>>>>> …
>>>>>>>>>>> I see your commits,
>>>>>>>>>>> clang yells loud about this, many people are moving from gcc to
>>>>>>>>>>> clang,
>>>>>>>>>>> your code will keep yelling so, not really an issue for me.
>>>>>>>>>>>
>>>>>>>>>> Really could care less what clang says to be honest :) They are ?? 
>>>>>>>>>> who
>>>>>>>>>> ?? Distros still ship with gcc as the default compiler
>>>>>>>>>> afaik....Well, it
>>>>>>>>>> does not yell here so not really an issue for me either ;)
>>>>>>>>> To be fair, that (()) clutter is ugly
>>>>>> Ugly ?? Have you ever looked inside Elementary code ?? Now THAT's ugly ;)
>>>>>>
>>>>>>      and should be removed even if
>>>>>>>>> clang doesn't complain. Why do you care so much for it anyway?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Tom.
>>>>>>>>>
>>>>>>>> It helps me keep my sanity when dealing with unruley if blocks and 
>>>>>>>> truth
>>>>>>>> tests. Well, one man's ugly is another man's beauty I suppose ;)
>>>>>>> How does it help you? I'm genuinely interested.
>>>>>>>
>>>>>>> --
>>>>>>> Tom.
>>>>>>>
>>>>>>
>>>>>> Order of precedence and readability mainly.
>>>>> Double parenthesis don't change the order of precedence. It's fine (and
>>>>> required by our conventions) if you had an AND or OR there, but since
>>>>> you don't have those, it just looks weird.
>>>>>
>>>> +1.
>>>> if ((ee->alpha == alpha)) return;
>>>> ((xxxx === aaa)) looks weird to me.
>>> Yea, that looks weird to me too '===' ?? ;)
>>>
>>>> It works but I am eager to clean this up.
>>>>
>>>> Anyhow, Jeremy could split the formatting fix commit and adding
>>>> missing NULL commit.
>>>> I think that was a point of devilhorns' mail.
>>>>
>>> Well, that was one point, sure....but my main point was...
>>> Don't change the formatting that was previously there please ;)
>> Actually, wouldn't it be better if we try to follow EFL formatting
>> inside the engine code?
>>
>> Of course I also do several mistakes regarding that formatting, but
>> IMHO when this kind of discussion appears, we should just stick to the
>> EFL formatting itself.
> We should stick to the formatting even before this kind of discussions
> appear.

Yup
>   Our coding guidelines don't really say anything regarding over
> resynthesizing,

Exactly. It don't say anything about it. However, it does say:

"Our golden rule of coding - *FOLLOW THE CODING STYLE ALREADY THERE*. 
That means that if you work on code that already exists, keep to the 
spacing, indenting, variable and function naming style, etc. that 
already exists."

"short if (cond) action are fine as single line;
use parenthesis for every clause or math;"

It also says:

"Use parenthesis to make clear what you want, even if the operator 
precedence is obvious to you. "

So yes, our standard does not say anything about the extra parens.

> but I'm quite certain, that if it had anything, it would
> have been a clear "DO NOT DO". Especially in this kind of case where it
> doesn't and will never make any sense.

Is that because you think it's "ugly" ?? Well, it makes sense to 
me...clearly defining the the condition.

I don't understand why you are making such a big deal out of an extra 
pair of parens (that do not hurt or do anything, except maybe making 
readability better) in code that you don't maintain (and I doubt will 
ever even read)....

dh

> --
> Tom.
>
>
>


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to