On 16/05/13 19:08, Jérémy Zurcher wrote:
> On Thursday 16 May 2013 17:37, Chris Michael wrote :
>> 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).
> that's what I was trying to reach,
> not for git blame lines, personal stats or preference (just saying),
> but for freeBSD.org, clang.debian.net, bitrig.org and the next to come…
>> Yes, remove them and a gcc compiler warning occurs ... so, stalemate ;)
> I obviously checked before committing,
> gcc (GCC) 4.8.0 20130502 (prerelease) does not,
Great to hear ... but older versions do...I've seen it myself.
dh
> I hear a voice from the future saying: remove this double parenthesis
>>> 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
