On 17/05/13 10:19, Tom Hacohen wrote: > 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. >
You know something ... Do Whatever the Fuck You Want !! I personally do not care anymore 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
