On 16/05/13 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 >>>>> <[email protected]> wrote: >>>>>> On 16/05/13 14:43, Daniel Juyung Seo wrote: >>>>>>> On Thu, May 16, 2013 at 7:00 PM, Tom Hacohen >>>>>>> <[email protected]> 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 ;)
What, why? > >> 2. I don't want this ugly epidemic to spread. :) > Ugly by Your definition... You were asking why I care... >> >> 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... You removed the important part from what I said, *it doesn't hold for re-factoring*. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
