Re: [E-devel] e code formatting - uncrustify
We could use post-commit hook. Massimiliano Il giorno 05/ago/2010 08.37, Vincent Torri vto...@univ-evry.fr ha scritto: On Thu, 5 Aug 2010, Tom Hacohen wrote: On Wed, Aug 4, 2010 at 5:26 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: People ignores the style that's there because no one is enforcing it, but look at other projects and how they just reject any patch that doesn't follow the style to the letter. It ends up working or driving people that can't play by the rules off. Exactly, what I said, patches that don't comply to the rules should just be rejected. Is it possible to have some kind of post-processing with svn, that is, a program that is called after a patch is committed ? Vincent -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 5 Aug 2010, Massimiliano wrote: We could use post-commit hook. In that case, will the mail commit be sent after the hook ? Vincent Il giorno 05/ago/2010 08.37, Vincent Torri vto...@univ-evry.fr ha scritto: On Thu, 5 Aug 2010, Tom Hacohen wrote: On Wed, Aug 4, 2010 at 5:26 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: People ignores the style that's there because no one is enforcing it, but look at other projects and how they just reject any patch that doesn't follow the style to the letter. It ends up working or driving people that can't play by the rules off. Exactly, what I said, patches that don't comply to the rules should just be rejected. Is it possible to have some kind of post-processing with svn, that is, a program that is called after a patch is committed ? Vincent -- 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
Re: [E-devel] e code formatting - uncrustify
we have to investigate. btw, there's pre-commit hook. Massimiliano Il giorno 05/ago/2010 09.03, Vincent Torri vto...@univ-evry.fr ha scritto: On Thu, 5 Aug 2010, Massimiliano wrote: We could use post-commit hook. In that case, will the mail commit be sent after the hook ? Vincent Il giorno 05/ago/2010 08.37, Vincent Torri vto...@univ-evry.fr ha scritto: On ... -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 5 Aug 2010 09:03:15 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Thu, 5 Aug 2010, Massimiliano wrote: We could use post-commit hook. In that case, will the mail commit be sent after the hook ? Post and pre commit hooks are what make things like commit mails possible, it's not a built in part of SVN. So we can do whatever we like in whatever order we like. Same thing goes for most other systems. I suspect that having this done as part of the commit process is what was in mind all along. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] e code formatting - uncrustify
Well, changing the content of the commit using a hook in SVN is a very very bad idea. As you can read in the SVN Book: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html Warning While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors, shortcomings, or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. You can run uncrustify and check if it changed anything, and reject the commit if it did, but you should not run it on the hook to change the committed content, otherwise very bad conflicts can happen (I learned this the hard way.) Cheers, Eduardo. On Thu, Aug 5, 2010 at 5:13 AM, David Seikel onef...@gmail.com wrote: On Thu, 5 Aug 2010 09:03:15 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Thu, 5 Aug 2010, Massimiliano wrote: We could use post-commit hook. In that case, will the mail commit be sent after the hook ? Post and pre commit hooks are what make things like commit mails possible, it's not a built in part of SVN. So we can do whatever we like in whatever order we like. Same thing goes for most other systems. I suspect that having this done as part of the commit process is what was in mind all along. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- 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 -- 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
Re: [E-devel] e code formatting - uncrustify
On Mon, 2 Aug 2010, Carsten Haitzler (The Rasterman) wrote: 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. I mentioned twice in that ML before that i wanted the same coding style for all the EFL (mainly because of Eina, actually, which has (had, now) 2 different coding styles and because what you use is really ugly. Note that i never told you to change your editor) and that was the purpose of those 2 mails... You answered me that it was useless because there would be no universal agreement... Now, you say the contrary: we must have one unique coding style. So i don't understand... Either you don't care about what i say or else my english is too ugly. if you notice the formatting doesn't even match what i have used in the past too Yes. I also mentioned in my mails that my proposed coding style is not mine 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. well, you missed my point, that's all (see above). I didn't pay attention at what your script does because it was useless, as it was not the purpose at all of my answer... you may have also noticed that i CHANGED my jedrc a few days ago to match the atuo-indenting. maybe you didn't? I don't care about what you do in your jedrc, it's your problem, like it's the other devs problem to do what is needed to respect the coding style. See win32 code or xcb that i wrote, where i tried to respect your coding style. Even more, in Epdf, Eps and Edvi, i used my ugly coding style, Etk style for their etk widget, Ewl style for their ewl widget, your style for their (old) epsilon plugin. If there is a group of people who try to respect the coding style, i'm definitely in. Vincent -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 4 Aug 2010 14:20:58 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. I mentioned twice in that ML before that i wanted the same coding style for all the EFL (mainly because of Eina, actually, which has (had, now) 2 different coding styles and because what you use is really ugly. Note you say ugly - i like it. i find other coding styles ugly. it's pointless trying to tall a coding style ugly. that i never told you to change your editor) and that was the purpose of those 2 mails... You answered me that it was useless because there would be no universal agreement... Now, you say the contrary: we must have one useless to get people to follow a coding style - yes. see above. you find mine ugly. people just dont want to. useless in forcing it on them, but automatic re-formatting has been talked about for a long time. the problem has been lack of time and tools to do the job. unique coding style. So i don't understand... Either you don't care about what i say or else my english is too ugly. having people FORCED into having to indent in 1 way will never work. they use different editors. one guy has tabs set to 4, another to 8. they even may use different os's to edit (\n vs \r\n) etc. in the end you have a myriad of styles. evern with all the coding guidelines people ignore them. even with the just follow the style that is there guideline people ignore it. it doesnt work relying on people to do the formatting. if it is to be done, it needs to be as automated as possible. we can't automate everything - but we can do a fair chunk. if you notice the formatting doesn't even match what i have used in the past too Yes. I also mentioned in my mails that my proposed coding style is not mine 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. well, you missed my point, that's all (see above). I didn't pay attention at what your script does because it was useless, as it was not the purpose at all of my answer... you may have also noticed that i CHANGED my jedrc a few days ago to match the atuo-indenting. maybe you didn't? I don't care about what you do in your jedrc, it's your problem, like it's the other devs problem to do what is needed to respect the coding style. See win32 code or xcb that i wrote, where i tried to respect your coding style. Even more, in Epdf, Eps and Edvi, i used my ugly coding style, Etk style for their etk widget, Ewl style for their ewl widget, your style for their (old) epsilon plugin. If there is a group of people who try to respect the coding style, i'm definitely in. Vincent -- - 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 4 Aug 2010 11:26:50 -0300 Iván Briano (Sachiel) sachi...@gmail.com said: On Wed, Aug 4, 2010 at 10:34 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 4 Aug 2010 14:20:58 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. I mentioned twice in that ML before that i wanted the same coding style for all the EFL (mainly because of Eina, actually, which has (had, now) 2 different coding styles and because what you use is really ugly. Note you say ugly - i like it. i find other coding styles ugly. it's pointless trying to tall a coding style ugly. that i never told you to change your editor) and that was the purpose of those 2 mails... You answered me that it was useless because there would be no universal agreement... Now, you say the contrary: we must have one useless to get people to follow a coding style - yes. see above. you find mine ugly. people just dont want to. useless in forcing it on them, but automatic re-formatting has been talked about for a long time. the problem has been lack of time and tools to do the job. unique coding style. So i don't understand... Either you don't care about what i say or else my english is too ugly. having people FORCED into having to indent in 1 way will never work. they use different editors. one guy has tabs set to 4, another to 8. they even may use different os's to edit (\n vs \r\n) etc. in the end you have a myriad of styles. evern with all the coding guidelines people ignore them. even with the just follow the style that is there guideline people ignore it. it doesnt work relying on people to do the formatting. if it is to be done, it needs to be as automated as possible. we can't automate everything - but we can do a fair chunk. People ignores the style that's there because no one is enforcing it, but look at other projects and how they just reject any patch that doesn't follow the style to the letter. It ends up working or driving people that can't play by the rules off. I remember back then, when this whole EFL thing started, that one of the reasons for the rewrite from scratch was how ugly E16 had turned by letting any patch in, and how now things would get more strict to keep the code clean, stable and high quality. In the end, it gets to the point where stuff gets if it works, and someone later will go around fixing style if they don't like it. people dont even follow it who have direct svn access. if you notice the formatting doesn't even match what i have used in the past too Yes. I also mentioned in my mails that my proposed coding style is not mine 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. well, you missed my point, that's all (see above). I didn't pay attention at what your script does because it was useless, as it was not the purpose at all of my answer... you may have also noticed that i CHANGED my jedrc a few days ago to match the atuo-indenting. maybe you didn't? I don't care about what you do in your jedrc, it's your problem, like it's the other devs problem to do what is needed to respect the coding style. See win32 code or xcb that i wrote, where i tried to respect your coding style. Even more, in Epdf, Eps and Edvi, i used my ugly coding style, Etk style for their etk widget, Ewl style for their ewl widget, your style for their (old) epsilon plugin. If there is a group of people who try to respect the coding style, i'm definitely in. Vincent -- - 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
Re: [E-devel] e code formatting - uncrustify
Note with uncrustify: running uncrustify alone is NOT sufficient unless you are running it the same way as formatefl.sh does. There are two passes it does, one for C and one for CPP, which seems to make a huge difference (probably a bug in uncrustify but whatever). -- 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
Re: [E-devel] e code formatting - uncrustify
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 -- 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
Re: [E-devel] e code formatting - uncrustify
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. 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 -- 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
Re: [E-devel] e code formatting - uncrustify
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... Vincent 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 -- 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
Re: [E-devel] e code formatting - uncrustify
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
Re: [E-devel] e code formatting - uncrustify
One example of what I was talking: evas_render_updates_internal() in evas/sr/lib/canvas/evas_render.c: 1) You have a function of *~400 lines length*. This is not even warned by uncrustify. 2) Some points inside this function have an indentation of *8 levels*. What uncrustify really does when you tell it has to fix the 80-col issue is to just break lines and turn things uglier yet. Worse, it will shut up the warning oww... this is more than 80 cols, think better about this code because most likely it's difficult to read which is the real problem here. Lucas De Marchi -- 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
Re: [E-devel] e code formatting - uncrustify
I think another interesting question is whether uncrustify needs to change wrapping at all? Couldn't we just add some code which checks line length and warns the user if the code has to long lines and print where the offenders are? Automatic wrapping never results in readable code. Sebastian Carsten Haitzler (The Rasterman) wrote: On Thu, 29 Jul 2010 20:55:12 -0700 Michael Jennings m...@kainx.org said: read the mail you replied to originally. i make the statement that you can keep growing the wrap width to fix up the formatting. and you just grow until you cease to wrap. thats avoiding the bug. not fixing it. it's what i said. i didn't change canoes. if its 80 - 85, or 80 - 135 - same principle. as for terminal resizes - all terminals anyone really uses (except for actual vt100's etc.) can be resized - linux console included. you can change screen resolution, text mode and font sizes. no different to a terminal in x - just harder to do the resizing. your argument is well chose 135 because there is a terminal mode. i'll believe that argument the day xterm, rxvt, gnome-terminal, eterm, konsole, the linux fb console etc. etc. all come in 135 wide by default when you run them. your argument justifies making wrap width wider because of standardisation. i argue that that is a slippery slope of simply moving the goalposts as opposed to fixing the formatting itself. that's what i said long before you piped up. please don't tell me i changed canoes mid-stream. On Friday, 30 July 2010, at 10:43:48 (+0900), Carsten Haitzler wrote: you don't get the point - the point is that the formatter doesnt handle wrapping intelligently. Not once in anything that you wrote to me did you state that. So no, that wasn't your point. Changing canoes in midstream because you made an error in logic does not mean I don't get the point. :) you will find code that doesnt fit in 132 die and needs wrapping - and the same problem will exist. That's certainly true. However, there will be *significantly fewer* occurances of the problem, and the result will still be more readable for those problem cases because the right-hand column is further out, allowing more space to work with. It's possible using 132 will eliminate enough problems to make fixing the tool unnecessary, allowing everyone to get back to writing EFL. Isn't it worth a try? the only solution other than fixing the formatter is the slippery slope. fix the problem. don't follow the slippery slope of workarounds. That's not what the logical fallacy referred to as slippery slope means. The URL I provided explains it. you argue that 132 columns is just fine because there is a terminal mode for it. that argument can be extended to any width with just resize your terminal. Not true. Not all terminals can be resized. That's the whole point. If all terminals could be resized to any desired width, it wouldn't matter one wit what column count we chose. Fixed terminals such as the Linux console cannot be resized. That's precisely why the default of 80 tends to be used. the fact is that when you start any terminal... you get an 80 wide one in almost all cases. not 132. you need to change things to be otherwise. thus 80 as a baseline makes sense. 132 doesn't. 132 makes sense for all the reasons I already mentioned. It's not as ideal as 80, no, but it has specific, clear advantages over all other values aside from 80. That may not be enough to make you want to use it, but it's still valid. if your fix to wrapping problems is well just make your terminal wider you're ignoring the actual problem that the formatter can't wrap correctly. Just make your terminal wider is a misrepresentation of my viewpoint, and you know that. Yes, the formatter has issues, but is fixing someone else's formatter something you really want to invest time in this close to release? One could also say that the actual problem is that this whole mess was inflicted on the community without sufficient testing or advance discussion and way too close to the release date to be reasonable. Heaven forbid someone offer a suggestion that might save everyone a lot of time and headaches and have logical reasoning to back it up Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I want to stand with you on a mountain. I want to bathe with you in the sea. I want to lay like this forever, until the sky falls down on me.-- Savage Garden, Truly, Madly, Deeply -- 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
Re: [E-devel] e code formatting - uncrustify
Without wrapping I think almost (if not all) of the readability
issues and strange cases would go away, so this may be the best idea. A
simple $( grep -En ^(.){81} ) will print all lines+linenumbers with
length of 81 or more so that they can be wrapped manually if
necessary...
--
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
Re: [E-devel] e code formatting - uncrustify
On Fri, Jul 30, 2010 at 4:15 PM, Sebastian Dransfeld s...@tango.flipp.net wrote: I think another interesting question is whether uncrustify needs to change wrapping at all? Couldn't we just add some code which checks line length and warns the user if the code has to long lines and print where the offenders are? Automatic wrapping never results in readable code. This is what I was talking since the beginning of this discussion. Lucas De Marchi -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, Jul 29, 2010 at 12:36 AM, Carsten Haitzler ras...@rasterman.comwrote: looks like EINA_ARG_NONNULL(), EINA_MALLOC etc. and friends really mess up the formatter - they can't make sense of it as its a func del with yet another fucn behind it and stuff before a ; which isn't actually normal to see in c. And that's only the start... -- Tom. -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, Jul 28, 2010 at 6:36 PM, Carsten Haitzler ras...@rasterman.com wrote: looks like EINA_ARG_NONNULL(), EINA_MALLOC etc. and friends really mess up the formatter - they can't make sense of it as its a func del with yet another fucn behind it and stuff before a ; which isn't actually normal to see in c. I think that if we don't be so strict about line width, we can work-around this. Also, sometimes it's really bad to break lines when you can have a much more readable source code with, let's say 85 chars. Not desirable, right, but it's not the worst thing. Maybe we can just emit warnings about line width, as check-patch from kernel guys does. Lucas De Marchi -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 15:53:15 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Wed, Jul 28, 2010 at 6:36 PM, Carsten Haitzler ras...@rasterman.com wrote: looks like EINA_ARG_NONNULL(), EINA_MALLOC etc. and friends really mess up the formatter - they can't make sense of it as its a func del with yet another fucn behind it and stuff before a ; which isn't actually normal to see in c. I think that if we don't be so strict about line width, we can work-around this. Also, sometimes it's really bad to break lines when you can have a much more readable source code with, let's say 85 chars. Not desirable, right, but it's not the worst thing. Maybe we can just emit warnings about line width, as check-patch from kernel guys does. then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. it's the standard term width. it's not a magic number invented for efl coding. uncrustify needs to be able to handle the above case properly. the only question is... how to do it? -- - 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
Re: [E-devel] e code formatting - uncrustify
On Thu, Jul 29, 2010 at 8:22 PM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 29 Jul 2010 15:53:15 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Wed, Jul 28, 2010 at 6:36 PM, Carsten Haitzler ras...@rasterman.com wrote: looks like EINA_ARG_NONNULL(), EINA_MALLOC etc. and friends really mess up the formatter - they can't make sense of it as its a func del with yet another fucn behind it and stuff before a ; which isn't actually normal to see in c. I think that if we don't be so strict about line width, we can work-around this. Also, sometimes it's really bad to break lines when you can have a much more readable source code with, let's say 85 chars. Not desirable, right, but it's not the worst thing. Maybe we can just emit warnings about line width, as check-patch from kernel guys does. then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. it's the standard term width. it's not a magic number invented for efl coding. uncrustify needs to be able to handle the above case properly. the only question is... how to do it? evs_obj_smrt_cb_add() -- - 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 -- 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
Re: [E-devel] e code formatting - uncrustify
On Friday, 30 July 2010, at 08:22:25 (+0900), Carsten Haitzler wrote: then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. it's the standard term width. it's not a magic number invented for efl coding. uncrustify needs to be able to handle the above case properly. the only question is... how to do it? I've mentioned this before, but I'll do so again. Most terminals have the ability to toggle between 80-column and 132-column mode via a menu option or escape sequence. I set all my emacs windows to be 132 columns wide for this reason, and wrap my source at 132 columns instead of 80. The result is significantly more readable. xterm and Eterm both support it. You can do it manually using: echo -e \e[?40;3h or (in Eterm) bind it to a menu item. To toggle back, change the 'h' to an 'l' (that's a lowercase L). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- A woman broke up with me and sent me pictures of her and her new boyfriend in bed together. Solution? I sent them to her dad. -- Christopher Case -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 16:45:54 -0700 Michael Jennings m...@kainx.org said: On Friday, 30 July 2010, at 08:22:25 (+0900), Carsten Haitzler wrote: then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. it's the standard term width. it's not a magic number invented for efl coding. uncrustify needs to be able to handle the above case properly. the only question is... how to do it? I've mentioned this before, but I'll do so again. Most terminals have the ability to toggle between 80-column and 132-column mode via a menu option or escape sequence. I set all my emacs windows to be 132 columns wide for this reason, and wrap my source at 132 columns instead of 80. The result is significantly more readable. xterm and Eterm both support it. You can do it manually using: echo -e \e[?40;3h or (in Eterm) bind it to a menu item. To toggle back, change the 'h' to an 'l' (that's a lowercase L). yes.. and if i maximize my terms i get 383x101... if i made my fonts smaller and got some 30 screens i'd get more. moot point. -- - 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
Re: [E-devel] e code formatting - uncrustify
On Friday, 30 July 2010, at 09:11:11 (+0900), Carsten Haitzler wrote: yes.. and if i maximize my terms i get 383x101... if i made my fonts smaller and got some 30 screens i'd get more. moot point. Not a moot point at all. The point is that, in this day and age, most users are no longer constrained by the 80 column limit, and for the few who are, there is an easy way for them to toggle to 132 columns. There's even a binding for it in screen (C-a W). So that particular value has significance in being easy to obtain, common to almost all terminals, and significantly more readable. It's not just some random width that only applies to a particular user. The number 80 was chosen for a reason. The number 132 could be chosen for almost as good a reason. This is not the case for *any* other width, including 85. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- God hears them cry. (Thou shalt not kill.) You hear the lie. (Do what you will.) And you simply look the other way. -- Holy Soldier, See No Evil (re abortion) -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 21:09:38 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Thu, Jul 29, 2010 at 8:22 PM, Carsten Haitzler ras...@rasterman.com wrote: then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. Your words: i think *trying* to stick to 80 wide is good. I think it's good too. And it's not scaling up. You have to fit in 80 columns, but there are exceptions. Automatic tools will not allow that exceptions. The most enlightenment email thread about this issue I've ever read is: http://kerneltrap.org/mailarchive/linux-kernel/2009/11/12/4507182 it's not a magic number invented for efl coding. I know, but imho people get the rule of 80-char too strict and forget its intent (see what Linus said on that thread). I'm all for warnings, so people will think better about that chunk, not just reformatting. the problem with exceptions is that we no longer can easily maintain formatting. it's hell as-is. we still have to police other formatting bits anyway. i'd want formatting fixed by automatic tools - if we have to write our own perl or whatever scripts to do it. -- - 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
Re: [E-devel] e code formatting - uncrustify
On Thu, Jul 29, 2010 at 8:22 PM, Carsten Haitzler ras...@rasterman.com wrote: then you wrap at 85.. then you say but if we made it a little wider it'd be nicer so it become 90, then if its a bit wider 95.. and so on. it doesn't end until you cease wrapping entirely. i think trying to stick to 80 wide is good. Your words: i think *trying* to stick to 80 wide is good. I think it's good too. And it's not scaling up. You have to fit in 80 columns, but there are exceptions. Automatic tools will not allow that exceptions. The most enlightenment email thread about this issue I've ever read is: http://kerneltrap.org/mailarchive/linux-kernel/2009/11/12/4507182 it's not a magic number invented for efl coding. I know, but imho people get the rule of 80-char too strict and forget its intent (see what Linus said on that thread). I'm all for warnings, so people will think better about that chunk, not just reformatting. Lucas De Marchi -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 17:17:04 -0700 Michael Jennings m...@kainx.org said: On Friday, 30 July 2010, at 09:11:11 (+0900), Carsten Haitzler wrote: yes.. and if i maximize my terms i get 383x101... if i made my fonts smaller and got some 30 screens i'd get more. moot point. Not a moot point at all. The point is that, in this day and age, most users are no longer constrained by the 80 column limit, and for the few who are, there is an easy way for them to toggle to 132 columns. There's even a binding for it in screen (C-a W). So that particular value has significance in being easy to obtain, common to almost all terminals, and significantly more readable. It's not just some random width that only applies to a particular user. The number 80 was chosen for a reason. The number 132 could be chosen for almost as good a reason. This is not the case for *any* other width, including 85. my point still stands. you can say it's sane - but then if you look at most commercial visual studio users they sit there with editors fullscreen and just fill the entire screen with lines of code. you can keep expanding your width until the cows come home. 80 wide allows multiple virtical columns of code to be on screen at once (ef .c file on left, header next to it in the middle, another .c file next to that and soon). as such humans are bad at reading long lines of text. there is a reason newspapers and magazines use thin columns. -- - 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
Re: [E-devel] e code formatting - uncrustify
On Friday, 30 July 2010, at 10:18:31 (+0900), Carsten Haitzler wrote: my point still stands. No, it doesn't, because you're arguing the slippery slope fallacy. (http://www.nizkor.org/features/fallacies/slippery-slope.html) Increasing the width to 132 does not in any way endorse, cause, or make inevitable future expansions or desires for expansion. It is a practical, reasonable response to the simple fact that the 80 column limit is causing significant readability problems in the existing code. you can say it's sane - but then if you look at most commercial visual studio users they sit there with editors fullscreen and just fill the entire screen with lines of code. you can keep expanding your width until the cows come home. See above. 80 wide allows multiple virtical columns of code to be on screen at once (ef .c file on left, header next to it in the middle, another .c file next to that and soon). Depending on the size of the font. And, also depending on the size of the font, you can do the same with 132 columns. You'd just have to use a smaller font to have the same number of documents side-by-side. And that can be said of any arbitrary number that's larger than any other arbitrary number. You can also stack vertically. The fact is, 80 is chosen for a reason, and it's not because people stack their documents side-by-side. It's because 80 is the default width for most terminal emulators because it was the default width of the terminals they emulate. Plain and simple. And I'm telling you there's *another* width, not default but just as built-in, that could be used instead. as such humans are bad at reading long lines of text. there is a reason newspapers and magazines use thin columns. This is a red herring. The audiences are different, and the requirements are different. Newspapers do not use long strings of words joined by underscores, nor do newspapers need to visually indicate scoping or order of operations in parenthesized expressions. Look, if you don't like the idea, just say so. That's not how I want to work, and it's my project, so STFU. But it would solve the bulk of the line-wrapping problems you're having (and as the person who imposed the problem on the project by insisting on uncrustify, it would seem reasonable that you help fix it). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I am everything you want; I am everything you need. I am everything inside of you that you wish you could be. I say all the right things at exactly the right time, but I mean nothing to you and I don't know why. -- Vertical Horizon, Everything -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 18:34:07 -0700 Michael Jennings m...@kainx.org said: you don't get the point - the point is that the formatter doesnt handle wrapping intelligently. you will find code that doesnt fit in 132 die and needs wrapping - and the same problem will exist. the only solution other than fixing the formatter is the slippery slope. fix the problem. don't follow the slippery slope of workarounds. you argue that 132 columns is just fine because there is a terminal mode for it. that argument can be extended to any width with just resize your terminal. the fact is that when you start any terminal... you get an 80 wide one in almost all cases. not 132. you need to change things to be otherwise. thus 80 as a baseline makes sense. 132 doesn't. if your fix to wrapping problems is well just make your terminal wider you're ignoring the actual problem that the formatter can't wrap correctly. On Friday, 30 July 2010, at 10:18:31 (+0900), Carsten Haitzler wrote: my point still stands. No, it doesn't, because you're arguing the slippery slope fallacy. (http://www.nizkor.org/features/fallacies/slippery-slope.html) Increasing the width to 132 does not in any way endorse, cause, or make inevitable future expansions or desires for expansion. It is a practical, reasonable response to the simple fact that the 80 column limit is causing significant readability problems in the existing code. you can say it's sane - but then if you look at most commercial visual studio users they sit there with editors fullscreen and just fill the entire screen with lines of code. you can keep expanding your width until the cows come home. See above. 80 wide allows multiple virtical columns of code to be on screen at once (ef .c file on left, header next to it in the middle, another .c file next to that and soon). Depending on the size of the font. And, also depending on the size of the font, you can do the same with 132 columns. You'd just have to use a smaller font to have the same number of documents side-by-side. And that can be said of any arbitrary number that's larger than any other arbitrary number. You can also stack vertically. The fact is, 80 is chosen for a reason, and it's not because people stack their documents side-by-side. It's because 80 is the default width for most terminal emulators because it was the default width of the terminals they emulate. Plain and simple. And I'm telling you there's *another* width, not default but just as built-in, that could be used instead. as such humans are bad at reading long lines of text. there is a reason newspapers and magazines use thin columns. This is a red herring. The audiences are different, and the requirements are different. Newspapers do not use long strings of words joined by underscores, nor do newspapers need to visually indicate scoping or order of operations in parenthesized expressions. Look, if you don't like the idea, just say so. That's not how I want to work, and it's my project, so STFU. But it would solve the bulk of the line-wrapping problems you're having (and as the person who imposed the problem on the project by insisting on uncrustify, it would seem reasonable that you help fix it). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I am everything you want; I am everything you need. I am everything inside of you that you wish you could be. I say all the right things at exactly the right time, but I mean nothing to you and I don't know why. -- Vertical Horizon, Everything -- 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 -- - 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
Re: [E-devel] e code formatting - uncrustify
Well if we're talking about wrapping functionality, it's an open source formatter so we could just mod it and add some special cases to avoid wrapping issues. -- 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
Re: [E-devel] e code formatting - uncrustify
On Thu, 29 Jul 2010 21:56:24 -0400 m...@zentific.com said: Well if we're talking about wrapping functionality, it's an open source formatter so we could just mod it and add some special cases to avoid wrapping issues. which is what i was saying to start with. :) fix the bug. dont work around it. -- - 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
Re: [E-devel] e code formatting - uncrustify
On Friday, 30 July 2010, at 10:43:48 (+0900), Carsten Haitzler wrote: you don't get the point - the point is that the formatter doesnt handle wrapping intelligently. Not once in anything that you wrote to me did you state that. So no, that wasn't your point. Changing canoes in midstream because you made an error in logic does not mean I don't get the point. :) you will find code that doesnt fit in 132 die and needs wrapping - and the same problem will exist. That's certainly true. However, there will be *significantly fewer* occurances of the problem, and the result will still be more readable for those problem cases because the right-hand column is further out, allowing more space to work with. It's possible using 132 will eliminate enough problems to make fixing the tool unnecessary, allowing everyone to get back to writing EFL. Isn't it worth a try? the only solution other than fixing the formatter is the slippery slope. fix the problem. don't follow the slippery slope of workarounds. That's not what the logical fallacy referred to as slippery slope means. The URL I provided explains it. you argue that 132 columns is just fine because there is a terminal mode for it. that argument can be extended to any width with just resize your terminal. Not true. Not all terminals can be resized. That's the whole point. If all terminals could be resized to any desired width, it wouldn't matter one wit what column count we chose. Fixed terminals such as the Linux console cannot be resized. That's precisely why the default of 80 tends to be used. the fact is that when you start any terminal... you get an 80 wide one in almost all cases. not 132. you need to change things to be otherwise. thus 80 as a baseline makes sense. 132 doesn't. 132 makes sense for all the reasons I already mentioned. It's not as ideal as 80, no, but it has specific, clear advantages over all other values aside from 80. That may not be enough to make you want to use it, but it's still valid. if your fix to wrapping problems is well just make your terminal wider you're ignoring the actual problem that the formatter can't wrap correctly. Just make your terminal wider is a misrepresentation of my viewpoint, and you know that. Yes, the formatter has issues, but is fixing someone else's formatter something you really want to invest time in this close to release? One could also say that the actual problem is that this whole mess was inflicted on the community without sufficient testing or advance discussion and way too close to the release date to be reasonable. Heaven forbid someone offer a suggestion that might save everyone a lot of time and headaches and have logical reasoning to back it up Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I want to stand with you on a mountain. I want to bathe with you in the sea. I want to lay like this forever, until the sky falls down on me.-- Savage Garden, Truly, Madly, Deeply -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 2010-07-28 at 11:10 +0900, Carsten Haitzler wrote: right now i started with eet - that's the first guy to get the treatment. Finally! :P Anyhow, please, if you can, give everyone an heads up a week before you attack a library, because format changes can cause a terrible merging hell. Thanks, Tom. -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 28 Jul 2010 09:40:52 +0300 Tom Hacohen tom.haco...@partner.samsung.com said: eet and eina are done. then hereby i give the week notice for: evas, evil, embryo, ecore, edje, efreet e_dbus, eeze, ethumb, elementary, expedite, emotion, exquisite, epdf, e get your patches in ASAP - or pending work. they will get re-formatted and thus you will live in patch-hell :) you have ... well let's be generous... until sunday (my time - thats over here in asia so for those of you in other bits of the world.. thats saturday afternoon/evening). if your stuff isn't in by then - no guarantee on how much longer things will live without the reformat stick. elm will be the last thing i do most likely. might take a few weeks until its done On Wed, 2010-07-28 at 11:10 +0900, Carsten Haitzler wrote: right now i started with eet - that's the first guy to get the treatment. Finally! :P Anyhow, please, if you can, give everyone an heads up a week before you attack a library, because format changes can cause a terrible merging hell. Thanks, Tom. -- 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 -- 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
Re: [E-devel] e code formatting - uncrustify
OH NO! Evas is in that list! :( Well, I'll do my best getting it there asap. -- Tom. On Wed, 2010-07-28 at 15:57 +0900, Carsten Haitzler wrote: On Wed, 28 Jul 2010 09:40:52 +0300 Tom Hacohen tom.haco...@partner.samsung.com said: eet and eina are done. then hereby i give the week notice for: evas, evil, embryo, ecore, edje, efreet e_dbus, eeze, ethumb, elementary, expedite, emotion, exquisite, epdf, e get your patches in ASAP - or pending work. they will get re-formatted and thus you will live in patch-hell :) you have ... well let's be generous... until sunday (my time - thats over here in asia so for those of you in other bits of the world.. thats saturday afternoon/evening). if your stuff isn't in by then - no guarantee on how much longer things will live without the reformat stick. elm will be the last thing i do most likely. might take a few weeks until its done On Wed, 2010-07-28 at 11:10 +0900, Carsten Haitzler wrote: right now i started with eet - that's the first guy to get the treatment. Finally! :P Anyhow, please, if you can, give everyone an heads up a week before you attack a library, because format changes can cause a terrible merging hell. Thanks, Tom. -- 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 -- 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
Re: [E-devel] e code formatting - uncrustify
On Tue, Jul 27, 2010 at 11:10 PM, Carsten Haitzler ras...@rasterman.com 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; While we're at it: - could you provide a clue on what changed? From what I understand from your jed options, just tabs got replaced with spaces? - could we settle on NO TRAILING WHITESPACES, for god sake :-) I will update my emacs mode based on these new specs. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, Jul 28, 2010 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 28 Jul 2010 09:40:52 +0300 Tom Hacohen tom.haco...@partner.samsung.com said: eet and eina are done. Please give a look at eina_hash.h and many other header, mostly involving macro. From my point of view, their is something wrong. -- Cedric BAIL -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 28 Jul 2010 08:34:37 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Tue, Jul 27, 2010 at 11:10 PM, Carsten Haitzler ras...@rasterman.com 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; While we're at it: - could you provide a clue on what changed? From what I understand from your jed options, just tabs got replaced with spaces? that changed years ago. after enough debates with people over how big a tab is and people simply not wanting to agree to leave tabs at 8. so spaces it is. - could we settle on NO TRAILING WHITESPACES, for god sake :-) thats what things like uncrustify should fix. I will update my emacs mode based on these new specs. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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 -- 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
Re: [E-devel] e code formatting - uncrustify
On Wed, 28 Jul 2010 14:42:49 +0200 Cedric BAIL cedric.b...@free.fr said: On Wed, Jul 28, 2010 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 28 Jul 2010 09:40:52 +0300 Tom Hacohen tom.haco...@partner.samsung.com said: eet and eina are done. Please give a look at eina_hash.h and many other header, mostly involving macro. From my point of view, their is something wrong. looks like EINA_ARG_NONNULL(), EINA_MALLOC etc. and friends really mess up the formatter - they can't make sense of it as its a func del with yet another fucn behind it and stuff before a ; which isn't actually normal to see in c. -- Cedric BAIL -- 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 -- 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
[E-devel] e code formatting - uncrustify
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
