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,
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
--
Jérémy Zurcher
av General Guisan 49
1400 Yverdon-les-bains
+41 (0) 79 599 84 27
------------------------------------------------------------------------------
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
