On Sun, 1 Aug 2010 09:50:36 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr>
said:
>
>
> On Sun, 1 Aug 2010, Carsten Haitzler (The Rasterman) wrote:
>
> > On Sun, 1 Aug 2010 08:29:40 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr>
> > said:
> >
> > no one does agree - thats the point. the point is to force a single style in
> > svn - if people like it or not. it's bypassing the human problem of agreeing
> > on a style and sticking to it - and making it a technical problem - ie
> > re-format the code to forcibly follow a style. well at least we can do some
> > of it in an automated way.
>
> that's nice. My opinion does not count, then ? you're saying that my
> coding style is not worth being used because nobody agreed on it, and
> later you just force *your* coding style whatever people can think of
> it... very nice...
don't get so touchy. i started and wrote most of efl. and my coding style is
rarely honored fully. everyone wants me to change editors just so i can
conform to their indenting style because their editor is incapable of the
same indentation. don't get your panties in a mess. i sure as hell am not going
to write up a new formatting config per library, per app, etc. etc. - and if
each one is formatted differently, it causes problems in being able to work on
them. if you get offended by there being a universal formatting style for efl,
then you're doing an awesome job of not helping improve or fix things.
if you notice the formatting doesn't even match what i have used in the past
too - it's whatever i can get out of an auto-formatter (uncrustify - it seems
to do a better job than indent and have by far many more options at any rate).
but you didn't seem to pay attention to this. you may have also noticed that i
CHANGED my jedrc a few days ago to match the atuo-indenting. maybe you didn't?
if we can get an automated reformatting script/setup going, we solve a lot of
the space vs tab problems, and other spacing and style issues in one block.
this removes a lot of painful footwork from fixing patches and existing code.
it doesn't solve everything (liked too much dependence on precedence of
operation, other style things like macros with capitals on param names, other
technically incorrect and at times problematic code like #defines with {}
around their content with no do { and } while (0) as it technically should be
etc. etc. - so not all fixed, but there is less to fix, and things that are
much harder to automate.
> >
> >>
> >> funny that you say it now, as you told me before that no one would agree
> >> on a coding style... It seems that what i said before on this subjct has
> >> been totally ignored by you.
> >>
> >> Vincent
> >>
> >> On Wed, 28 Jul 2010, Carsten Haitzler (The Rasterman) wrote:
> >>
> >>> ok as one of the final few things before an efl 1.0.0... we need to cease
> >>> the formatting wars/hell. the first step is in stopping the newlines,
> >>> space vs tab and other indentation etc. wars. from now on all efl and e
> >>> code will conform to a SINGLE standard. that standard is now
> >>> programmatically enforced by the config
> >>> + script + tool in the FORMATTING dir. its a tool called uncrustify. it
> >>> butchers code much less than indent does and does a good job. to set the
> >>> tool just run formatefl.sh from the FORMATTING dir. you can read the
> >>> script to see. but from now on ALL commits will be required to be
> >>> formatted before you commit (or update for that matter). this stops
> >>> format arguments. there is only 1 format. feel free to teach your editor
> >>> to try and do the same format. as such in jed it's easy. add these to
> >>> your ~/.jedrc:
> >>>
> >>> USE_TABS = 0;
> >>> C_INDENT = 3;
> >>> C_BRACE = 2;
> >>> C_BRA_NEWLINE = 0;
> >>> C_Colon_Offset = 0;
> >>> C_CONTINUED_OFFSET = 3;
> >>>
> >>> for vim, emacs etc. users - feel free to share whatever it is you do to
> >>> get as close to the formatting style as possible. this doesn't cover other
> >>> elements in standards like using brackets instead of relying on order of
> >>> operation. i.e. : if (a == b && c == d)
> >>> is wrong in EFL. it should be
> >>> if ((a == b) && (c == d))
> >>>
> >>> the same with math ops:
> >>> a = b + c / d % e;
> >>> should be:
> >>> a = (b + c) / (d % e);
> >>> for example.
> >>>
> >>> brackets cost nothing runtime and they explain the actual intended order
> >>> of logic. even if you get things right with knowing the order of every
> >>> operator - you may forget some of them and your intended logic is never
> >>> written in the code. we can go on about other things too, but this
> >>> uncrustification is a first step in prettying up the code and making sure
> >>> we dont have lots of "fix formatting" stuff in the long run, and we have a
> >>> defined standard for people to format their code to when providing
> >>> patches.
> >>>
> >>> right now i started with eet - that's the first guy to get the treatment.
> >>> this will work its way through e + efl over the next week or so. so be
> >>> warned. once something has been re-formatted to these rules - stick to
> >>> them. there is the script:
> >>> formatefl.sh ./src
> >>>
> >>> for example, will recursively find all src files and reformat them. this
> >>> is, of course, for c/c++ code only at this stage.
> >>>
> >>> --
> >>> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> >>> The Rasterman (Carsten Haitzler) ras...@rasterman.com
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> The Palm PDK Hot Apps Program offers developers who use the
> >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> >>> of $1 Million in cash or HP Products. Visit us here for more details:
> >>> http://ad.doubleclick.net/clk;226879339;13503038;l?
> >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> >>> _______________________________________________
> >>> enlightenment-devel mailing list
> >>> enlightenment-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>>
> >>>
> >>
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> >
> >
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
