On 16/05/13 17:29, Tom Hacohen wrote:
> On 16/05/13 17:17, Chris Michael wrote:
>> 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)....
>>
>
> Because:
> 1. Compiling without warnings helps assuring our users that the
> software we produce is of high quality (yes, clang warnings count).
Yes, remove them and a gcc compiler warning occurs ... so, stalemate ;)
> 2. I don't want this ugly epidemic to spread. :)
Ugly by Your definition...
>
> 3. I don't see you do the same in other pieces of code you write.
>
Could be that I did not notice, was sleepy/lazy that day, etc, etc. Pick
one.
> And last, but not least: the guidelines about following the
> surrounding code are about adding code, not re-factoring.
>
Umm, wrong:
"That means that if you work on code that already exists"
Hmmm, I "think" this code already existed at the time of this change...
> --
> Tom.
>
Anyway, I think we have better things to do (like actually write code
and have productive technical discussions) than to sit here and argue
about this....but, in case you don't, I will make some popcorn for the
movie ("Format Wars: Episode 9000").
dh
------------------------------------------------------------------------------
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
