From: Vincent T. <vt...@un...> - 2009-08-30 05:41:01
Attachments:
CODING_STYLE
|
Hey, I think that we all agree that the current mix of whitespace and tabulation in most of the source code is not that very nice. Also, the libraries are often using the coding style of the original author, hence we have several different coding style in different libraries (eina being even worse, as it uses both raster and Jorge coding style...) As we plan to release the EFL, maybe it would be good to choose a common coding style and to modify the source code accordingly (preferably before the release, but that can be done after as it would be a lot of work). I have attached a proposal. The structure is based on the cairo coding style file (I have copy/pasted most of the sentences as I'm not an english speaker/writer, but I modified the examples of course...). Feel free to give your ideas, remarks, modifications, additions, etc... We are not in a hurry, so discussion is welcome, of course. Once we all agree on a coding style, i think that such file should be included in all EFL svn repo and future tarballs. regards Vincent |
From: Nathan I. <nin...@gm...> - 2009-08-30 19:07:41
|
Hi Vincent, The Google C++ style guide has a requirement that I would suggest considering. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Function_Calls The specific suggestion is that we provide guidance on how to wrap function definitions and calls that don't fit well on a single line. For example: void library_prefix_plus_object_type_plus_some_long_operation_name(Object_Type object, type1 value, type2 value) { <function body> } The wrapping is pretty annoying on this function definition and any calls starting from some nested indentation level are going to be really hard to wrap properly at 80 characters. The style guide referenced suggests wrapping at the opening paren and double indentation for the parameters to make them distinct from the body contents. void library_prefix_plus_object_type_plus_some_long_operation_name( Object_Type object, type1 value1, type2 value2) { <function body> } The call wrapping is similar: <leading body> library_prefix_plus_object_type_plus_some_long_operation_name( object, value1, value2); <remaining body> Whether we use this style or not, providing guidance for these more difficult situations would be very useful. Nathan On Sun, Aug 30, 2009 at 5:40 AM, Vincent Torri<vt...@un...> wrote: > > Hey, > > I think that we all agree that the current mix of whitespace and tabulation > in most of the source code is not that very nice. Also, the libraries are > often using the coding style of the original author, hence we have several > different coding style in different libraries (eina being even worse, as it > uses both raster and Jorge coding style...) > > As we plan to release the EFL, maybe it would be good to choose a common > coding style and to modify the source code accordingly (preferably before > the release, but that can be done after as it would be a lot of work). > > I have attached a proposal. The structure is based on the cairo coding style > file (I have copy/pasted most of the sentences as I'm not an english > speaker/writer, but I modified the examples of course...). > > Feel free to give your ideas, remarks, modifications, additions, etc... We > are not in a hurry, so discussion is welcome, of course. > > Once we all agree on a coding style, i think that such file should be > included in all EFL svn repo and future tarballs. > > regards > > Vincent > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > |
From: Vincent T. <vt...@un...> - 2009-08-31 13:02:07
|
ok, forget about that, core devs don't care at all about coding style thread closed Vincent On Sun, 30 Aug 2009, Nathan Ingersoll wrote: > Hi Vincent, > > The Google C++ style guide has a requirement that I would suggest considering. > > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Function_Calls > > The specific suggestion is that we provide guidance on how to wrap > function definitions and calls that don't fit well on a single line. > For example: > > void > library_prefix_plus_object_type_plus_some_long_operation_name(Object_Type > object, > > type1 value, > > type2 value) > { > <function body> > } > > The wrapping is pretty annoying on this function definition and any > calls starting from some nested indentation level are going to be > really hard to wrap properly at 80 characters. The style guide > referenced suggests wrapping at the opening paren and double > indentation for the parameters to make them distinct from the body > contents. > > void > library_prefix_plus_object_type_plus_some_long_operation_name( > Object_Type object, type1 value1, type2 value2) > { > <function body> > } > > The call wrapping is similar: > > <leading body> > library_prefix_plus_object_type_plus_some_long_operation_name( > object, value1, value2); > <remaining body> > > Whether we use this style or not, providing guidance for these more > difficult situations would be very useful. > > Nathan > > > On Sun, Aug 30, 2009 at 5:40 AM, Vincent Torri<vt...@un...> wrote: >> >> Hey, >> >> I think that we all agree that the current mix of whitespace and tabulation >> in most of the source code is not that very nice. Also, the libraries are >> often using the coding style of the original author, hence we have several >> different coding style in different libraries (eina being even worse, as it >> uses both raster and Jorge coding style...) >> >> As we plan to release the EFL, maybe it would be good to choose a common >> coding style and to modify the source code accordingly (preferably before >> the release, but that can be done after as it would be a lot of work). >> >> I have attached a proposal. The structure is based on the cairo coding style >> file (I have copy/pasted most of the sentences as I'm not an english >> speaker/writer, but I modified the examples of course...). >> >> Feel free to give your ideas, remarks, modifications, additions, etc... We >> are not in a hurry, so discussion is welcome, of course. >> >> Once we all agree on a coding style, i think that such file should be >> included in all EFL svn repo and future tarballs. >> >> regards >> >> Vincent >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> enlightenment-devel mailing list >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> > > -- > Ce message a été vérifié par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a été trouvé. > Message délivré par le serveur de messagerie de l'Université d'Evry. > > > |
From: Noorul I. <gn...@gm...> - 2009-09-01 14:33:25
|
On Mon, Aug 31, 2009 at 6:31 PM, Vincent Torri<vt...@un...> wrote: > > ok, forget about that, core devs don't care at all about coding style > > thread closed > I think core developers are busy. I hope they will reply soon. Thanks Noorul |
From: Nick H. <me...@me...> - 2009-09-02 02:36:56
|
On Tue, 1 Sep 2009 20:03:18 +0530 Noorul Islam <gn...@gm...> wrote: > On Mon, Aug 31, 2009 at 6:31 PM, Vincent Torri<vt...@un...> > wrote: > > > > ok, forget about that, core devs don't care at all about coding > > style > > > > thread closed > > > > I think core developers are busy. I hope they will reply soon. > I would love this to finally be done, but I know most of the devs just don't care. But when we have a crazy style like we do I think it requires a bit of explanation unless we want to constantly format patches from people. I also think that moving to a format with only spaces and no tabs would further help. Most editors do not do tabs+spaces like JED (essentially how E's code got it's style). I realize it's easy to just keep this format, but I find myself formatting my code more then writing it in the editor I use. And no I'm not going to spend days trying to tweak my editor to just code E style since I have plenty of other things to code in my own style. > Thanks > Noorul > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment > - and focus on what you do best, core application coding. Discover > what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: Christopher M. <cpm...@co...> - 2009-09-02 03:19:57
|
Nick Hughart wrote: > On Tue, 1 Sep 2009 20:03:18 +0530 > Noorul Islam <gn...@gm...> wrote: > >> On Mon, Aug 31, 2009 at 6:31 PM, Vincent Torri<vt...@un...> >> wrote: >>> ok, forget about that, core devs don't care at all about coding >>> style >>> >>> thread closed >>> >> I think core developers are busy. I hope they will reply soon. >> > > I would love this to finally be done, but I know most of the devs just > don't care. But when we have a crazy style like we do I think it > requires a bit of explanation unless we want to constantly format > patches from people. > > I also think that moving to a format with only spaces and no tabs would > further help. Most editors do not do tabs+spaces like JED (essentially > how E's code got it's style). I realize it's easy to just keep this > format, but I find myself formatting my code more then writing it in > the editor I use. And no I'm not going to spend days trying to tweak > my editor to just code E style since I have plenty of other things to > code in my own style. > Not to start any flames or anything, but changing the code style for E would require others to tweak their editors....is their time any less important to them ? dh >> Thanks >> Noorul >> |
From: Nick H. <me...@me...> - 2009-09-02 04:38:45
|
On Tue, 01 Sep 2009 23:19:37 -0400 Christopher Michael <cpm...@co...> wrote: > Nick Hughart wrote: > > On Tue, 1 Sep 2009 20:03:18 +0530 > > Noorul Islam <gn...@gm...> wrote: > > > >> On Mon, Aug 31, 2009 at 6:31 PM, Vincent Torri<vt...@un...> > >> wrote: > >>> ok, forget about that, core devs don't care at all about coding > >>> style > >>> > >>> thread closed > >>> > >> I think core developers are busy. I hope they will reply soon. > >> > > > > I would love this to finally be done, but I know most of the devs > > just don't care. But when we have a crazy style like we do I think > > it requires a bit of explanation unless we want to constantly format > > patches from people. > > > > I also think that moving to a format with only spaces and no tabs > > would further help. Most editors do not do tabs+spaces like JED > > (essentially how E's code got it's style). I realize it's easy to > > just keep this format, but I find myself formatting my code more > > then writing it in the editor I use. And no I'm not going to spend > > days trying to tweak my editor to just code E style since I have > > plenty of other things to code in my own style. > > > Not to start any flames or anything, but changing the code style for > E would require others to tweak their editors....is their time any > less important to them ? How many people use JED? I realize there are vim lines in a large portion of the files, but are these perfect to the format in use? Also, this leaves out anyone who doesn't use VIM or JED and this number is probably increasing quicker then those who use them I would imagine. If noone wants to discuss it because they don't want to modify their editor then I guess there's no use discussing it. All I was saying was the format could be a little simpler so one doesn't have to count spaces and figure out if they should add a tab or 7 spaces. If I don't have to worry about tabs my life is instantly easier as I only have to put in the proper amount of spaces. Any editor should be able to insert spaces in place of tabs, doing tabs and spaces together efficiently is more likely going to limit the editors that one use without having to spend excess time formatting. > > dh > > > >> Thanks > >> Noorul > >> > |
From: David S. <on...@gm...> - 2009-09-02 04:34:50
Attachments:
signature.asc
|
On Tue, 01 Sep 2009 23:19:37 -0400 Christopher Michael <cpm...@co...> wrote: > Nick Hughart wrote: > > On Tue, 1 Sep 2009 20:03:18 +0530 > > Noorul Islam <gn...@gm...> wrote: > > > >> On Mon, Aug 31, 2009 at 6:31 PM, Vincent Torri<vt...@un...> > >> wrote: > >>> ok, forget about that, core devs don't care at all about coding > >>> style > >>> > >>> thread closed > >>> > >> I think core developers are busy. I hope they will reply soon. > >> > > > > I would love this to finally be done, but I know most of the devs > > just don't care. But when we have a crazy style like we do I think > > it requires a bit of explanation unless we want to constantly format > > patches from people. > > > > I also think that moving to a format with only spaces and no tabs > > would further help. Most editors do not do tabs+spaces like JED > > (essentially how E's code got it's style). I realize it's easy to > > just keep this format, but I find myself formatting my code more > > then writing it in the editor I use. And no I'm not going to spend > > days trying to tweak my editor to just code E style since I have > > plenty of other things to code in my own style. > > > Not to start any flames or anything, but changing the code style for > E would require others to tweak their editors....is their time any > less important to them ? indent is a perfectly adequate tool for automating that sort of style stuff, so long as the official style fits within what indent can do. We have indent.pro files in SVN for exactly that reason. A typical busy open source developer probably is dealing with dozens of projects with source code in even more styles. Us busy open source developers should be fairly agnostic in what styles we accept from projects we don't control, and very used to just automatically following any style we find. Or at least running the projects official indent.pro files over our changes before committing. Those that are realiy style anal can run indent to massage code to their own personal style, then again before commits. lol Some of those styles found in the wild are deplorable, but that is always personal taste exactly what fits the description of "deplorable". Though styles that insist on 80 character lines AND long descriptive names are just asking for trouble. |
From: Nick H. <me...@me...> - 2009-09-02 04:47:16
|
On Wed, 2 Sep 2009 14:34:03 +1000 David Seikel <on...@gm...> wrote: > On Tue, 01 Sep 2009 23:19:37 -0400 Christopher Michael > <cpm...@co...> wrote: > > > Nick Hughart wrote: > > > On Tue, 1 Sep 2009 20:03:18 +0530 > > > Noorul Islam <gn...@gm...> wrote: > > > > > >> On Mon, Aug 31, 2009 at 6:31 PM, Vincent > > >> Torri<vt...@un...> wrote: > > >>> ok, forget about that, core devs don't care at all about coding > > >>> style > > >>> > > >>> thread closed > > >>> > > >> I think core developers are busy. I hope they will reply soon. > > >> > > > > > > I would love this to finally be done, but I know most of the devs > > > just don't care. But when we have a crazy style like we do I > > > think it requires a bit of explanation unless we want to > > > constantly format patches from people. > > > > > > I also think that moving to a format with only spaces and no tabs > > > would further help. Most editors do not do tabs+spaces like JED > > > (essentially how E's code got it's style). I realize it's easy to > > > just keep this format, but I find myself formatting my code more > > > then writing it in the editor I use. And no I'm not going to > > > spend days trying to tweak my editor to just code E style since I > > > have plenty of other things to code in my own style. > > > > > Not to start any flames or anything, but changing the code style for > > E would require others to tweak their editors....is their time any > > less important to them ? > > indent is a perfectly adequate tool for automating that sort of style > stuff, so long as the official style fits within what indent can do. > We have indent.pro files in SVN for exactly that reason. Unfortunately it's been said many times that the indent files in SVN do not actually produce the E format as it stands today and from what people have said, indent cannot produce the E format. Why that is I cannot say and that may no longer be true or may have been false in the first place, I'm just saying what I've heard before. > > A typical busy open source developer probably is dealing with dozens > of projects with source code in even more styles. Us busy open > source developers should be fairly agnostic in what styles we accept > from projects we don't control, and very used to just automatically > following any style we find. Or at least running the projects > official indent.pro files over our changes before committing. > > Those that are realiy style anal can run indent to massage code to > their own personal style, then again before commits. lol > > Some of those styles found in the wild are deplorable, but that is > always personal taste exactly what fits the description of > "deplorable". Though styles that insist on 80 character lines AND > long descriptive names are just asking for trouble. |
From: David S. <on...@gm...> - 2009-09-02 05:02:38
Attachments:
signature.asc
|
On Tue, 1 Sep 2009 18:47:45 -0500 Nick Hughart <me...@me...> wrote: > On Wed, 2 Sep 2009 14:34:03 +1000 > David Seikel <on...@gm...> wrote: > > > On Tue, 01 Sep 2009 23:19:37 -0400 Christopher Michael > > <cpm...@co...> wrote: > > > > > Nick Hughart wrote: > > > > On Tue, 1 Sep 2009 20:03:18 +0530 > > > > Noorul Islam <gn...@gm...> wrote: > > > > > > > >> On Mon, Aug 31, 2009 at 6:31 PM, Vincent > > > >> Torri<vt...@un...> wrote: > > > >>> ok, forget about that, core devs don't care at all about > > > >>> coding style > > > >>> > > > >>> thread closed > > > >>> > > > >> I think core developers are busy. I hope they will reply soon. > > > >> > > > > > > > > I would love this to finally be done, but I know most of the > > > > devs just don't care. But when we have a crazy style like we > > > > do I think it requires a bit of explanation unless we want to > > > > constantly format patches from people. > > > > > > > > I also think that moving to a format with only spaces and no > > > > tabs would further help. Most editors do not do tabs+spaces > > > > like JED (essentially how E's code got it's style). I realize > > > > it's easy to just keep this format, but I find myself > > > > formatting my code more then writing it in the editor I use. > > > > And no I'm not going to spend days trying to tweak my editor to > > > > just code E style since I have plenty of other things to code > > > > in my own style. > > > > > > > Not to start any flames or anything, but changing the code style > > > for E would require others to tweak their editors....is their > > > time any less important to them ? > > > > indent is a perfectly adequate tool for automating that sort of > > style stuff, so long as the official style fits within what indent > > can do. We have indent.pro files in SVN for exactly that reason. > > Unfortunately it's been said many times that the indent files in SVN > do not actually produce the E format as it stands today and from what > people have said, indent cannot produce the E format. Why that is I > cannot say and that may no longer be true or may have been false in > the first place, I'm just saying what I've heard before. That's why I added "so long as the official style fits within what indent can do". Might be time to tweak the style to fit the tool, or maybe someone wants to tweak the tool to fit the style? |
From: Carsten H. (T. R. <ra...@ra...> - 2009-09-03 12:39:02
|
On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri <vt...@un...> said: hmm i disagree with some of the doc. specifically blah { xx; } i have always had/used: blah { xx; } ie {}'s are indented a bit. but... we can argue over little things all day long. imho the ONLY way this will work is if we have an indent line/rule that works. and the only way this will work is if we require code is "indented" before a commit. in fact i'd even consider this should be done as part of the commit p;rocess automatically. all *.c *.h files should be 1. patched with commmit 2. run through indent 3. actual patch/commit generated and put into svn. can svn do this - ie add a stage in the commit pipeline? that's the q. otherwise its a policy and people need to remember to run indent on their edited files (or new added files). > Hey, > > I think that we all agree that the current mix of whitespace and > tabulation in most of the source code is not that very nice. > Also, the libraries are often using the coding style of the original author, > hence we have several different coding style in different libraries (eina > being even worse, as it uses both raster and Jorge coding style...) > > As we plan to release the EFL, maybe it would be good to choose a common > coding style and to modify the source code accordingly (preferably > before the release, but that can be done after as it would be a lot of > work). > > I have attached a proposal. The structure is based on the cairo coding > style file (I have copy/pasted most of the sentences as I'm not an > english speaker/writer, but I modified the examples of course...). > > Feel free to give your ideas, remarks, modifications, additions, etc... We > are not in a hurry, so discussion is welcome, of course. > > Once we all agree on a coding style, i think that such file should be > included in all EFL svn repo and future tarballs. > > regards > > Vincent -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Iván B. (S. <sac...@gm...> - 2009-09-03 13:08:06
|
On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra...> wrote: > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri <vt...@un...> > said: > > hmm i disagree with some of the doc. specifically > > blah > { > xx; > } > > i have always had/used: > blah > { > xx; > } > > ie {}'s are indented a bit. > > but... we can argue over little things all day long. imho the ONLY way this > will work is if we have an indent line/rule that works. and the only way this > will work is if we require code is "indented" before a commit. in fact i'd even > consider this should be done as part of the commit p;rocess automatically. all > *.c *.h files should be > > 1. patched with commmit > 2. run through indent > 3. actual patch/commit generated and put into svn. > > can svn do this - ie add a stage in the commit pipeline? that's the q. > otherwise its a policy and people need to remember to run indent on their > edited files (or new added files). > Should be doable with a pre-commit hook. >> Hey, >> >> I think that we all agree that the current mix of whitespace and >> tabulation in most of the source code is not that very nice. >> Also, the libraries are often using the coding style of the original author, >> hence we have several different coding style in different libraries (eina >> being even worse, as it uses both raster and Jorge coding style...) >> >> As we plan to release the EFL, maybe it would be good to choose a common >> coding style and to modify the source code accordingly (preferably >> before the release, but that can be done after as it would be a lot of >> work). >> >> I have attached a proposal. The structure is based on the cairo coding >> style file (I have copy/pasted most of the sentences as I'm not an >> english speaker/writer, but I modified the examples of course...). >> >> Feel free to give your ideas, remarks, modifications, additions, etc... We >> are not in a hurry, so discussion is welcome, of course. >> >> Once we all agree on a coding style, i think that such file should be >> included in all EFL svn repo and future tarballs. >> >> regards >> >> Vincent > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Carsten H. (T. R. <ra...@ra...> - 2009-09-03 21:47:34
|
On Thu, 3 Sep 2009 10:07:54 -0300 Iván Briano (Sachiel) <sac...@gm...> said: > On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra...> wrote: > > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri > > <vt...@un...> said: > > > > hmm i disagree with some of the doc. specifically > > > > blah > > { > > xx; > > } > > > > i have always had/used: > > blah > > { > > xx; > > } > > > > ie {}'s are indented a bit. > > > > but... we can argue over little things all day long. imho the ONLY way this > > will work is if we have an indent line/rule that works. and the only way > > this will work is if we require code is "indented" before a commit. in fact > > i'd even consider this should be done as part of the commit p;rocess > > automatically. all *.c *.h files should be > > > > 1. patched with commmit > > 2. run through indent > > 3. actual patch/commit generated and put into svn. > > > > can svn do this - ie add a stage in the commit pipeline? that's the q. > > otherwise its a policy and people need to remember to run indent on their > > edited files (or new added files). > > > > Should be doable with a pre-commit hook. pre-commit is allowed to modify the content of the incoming code of that commit before merge to the code in the tree? if so - good. then that should be used. once we agree on the indent arguments. > >> Hey, > >> > >> I think that we all agree that the current mix of whitespace and > >> tabulation in most of the source code is not that very nice. > >> Also, the libraries are often using the coding style of the original > >> author, hence we have several different coding style in different > >> libraries (eina being even worse, as it uses both raster and Jorge coding > >> style...) > >> > >> As we plan to release the EFL, maybe it would be good to choose a common > >> coding style and to modify the source code accordingly (preferably > >> before the release, but that can be done after as it would be a lot of > >> work). > >> > >> I have attached a proposal. The structure is based on the cairo coding > >> style file (I have copy/pasted most of the sentences as I'm not an > >> english speaker/writer, but I modified the examples of course...). > >> > >> Feel free to give your ideas, remarks, modifications, additions, etc... We > >> are not in a hurry, so discussion is welcome, of course. > >> > >> Once we all agree on a coding style, i think that such file should be > >> included in all EFL svn repo and future tarballs. > >> > >> regards > >> > >> Vincent > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > > on what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Iván B. (S. <sac...@gm...> - 2009-09-03 21:54:57
|
On Thu, Sep 3, 2009 at 6:25 PM, Carsten Haitzler<ra...@ra...> wrote: > On Thu, 3 Sep 2009 10:07:54 -0300 Iván Briano (Sachiel) <sac...@gm...> > said: > >> On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra...> wrote: >> > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri >> > <vt...@un...> said: >> > >> > hmm i disagree with some of the doc. specifically >> > >> > blah >> > { >> > xx; >> > } >> > >> > i have always had/used: >> > blah >> > { >> > xx; >> > } >> > >> > ie {}'s are indented a bit. >> > >> > but... we can argue over little things all day long. imho the ONLY way this >> > will work is if we have an indent line/rule that works. and the only way >> > this will work is if we require code is "indented" before a commit. in fact >> > i'd even consider this should be done as part of the commit p;rocess >> > automatically. all *.c *.h files should be >> > >> > 1. patched with commmit >> > 2. run through indent >> > 3. actual patch/commit generated and put into svn. >> > >> > can svn do this - ie add a stage in the commit pipeline? that's the q. >> > otherwise its a policy and people need to remember to run indent on their >> > edited files (or new added files). >> > >> >> Should be doable with a pre-commit hook. > > pre-commit is allowed to modify the content of the incoming code of that > commit before merge to the code in the tree? if so - good. then that should be > used. once we agree on the indent arguments. > Apparently, it can but it's not a good idea. It can cause problems with local cache kept by svn, so the usual advice is to reject commits and not modify them. >> >> Hey, >> >> >> >> I think that we all agree that the current mix of whitespace and >> >> tabulation in most of the source code is not that very nice. >> >> Also, the libraries are often using the coding style of the original >> >> author, hence we have several different coding style in different >> >> libraries (eina being even worse, as it uses both raster and Jorge coding >> >> style...) >> >> >> >> As we plan to release the EFL, maybe it would be good to choose a common >> >> coding style and to modify the source code accordingly (preferably >> >> before the release, but that can be done after as it would be a lot of >> >> work). >> >> >> >> I have attached a proposal. The structure is based on the cairo coding >> >> style file (I have copy/pasted most of the sentences as I'm not an >> >> english speaker/writer, but I modified the examples of course...). >> >> >> >> Feel free to give your ideas, remarks, modifications, additions, etc... We >> >> are not in a hurry, so discussion is welcome, of course. >> >> >> >> Once we all agree on a coding style, i think that such file should be >> >> included in all EFL svn repo and future tarballs. >> >> >> >> regards >> >> >> >> Vincent >> > >> > >> > -- >> > ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> > The Rasterman (Carsten Haitzler) ra...@ra... >> > >> > >> > ------------------------------------------------------------------------------ >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> > trial. Simplify your report design, integration and deployment - and focus >> > on what you do best, core application coding. Discover what's new with >> > Crystal Reports now. http://p.sf.net/sfu/bobj-july >> > _______________________________________________ >> > enlightenment-devel mailing list >> > enl...@li... >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> enlightenment-devel mailing list >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > |
From: Carsten H. (T. R. <ra...@ra...> - 2009-09-04 16:04:28
|
On Thu, 3 Sep 2009 18:54:40 -0300 Iván Briano (Sachiel) <sac...@gm...> said: > On Thu, Sep 3, 2009 at 6:25 PM, Carsten Haitzler<ra...@ra...> wrote: > > On Thu, 3 Sep 2009 10:07:54 -0300 Iván Briano (Sachiel) <sac...@gm...> > > said: > > > >> On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra...> > >> wrote: > >> > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri > >> > <vt...@un...> said: > >> > > >> > hmm i disagree with some of the doc. specifically > >> > > >> > blah > >> > { > >> > xx; > >> > } > >> > > >> > i have always had/used: > >> > blah > >> > { > >> > xx; > >> > } > >> > > >> > ie {}'s are indented a bit. > >> > > >> > but... we can argue over little things all day long. imho the ONLY way > >> > this will work is if we have an indent line/rule that works. and the > >> > only way this will work is if we require code is "indented" before a > >> > commit. in fact i'd even consider this should be done as part of the > >> > commit p;rocess automatically. all *.c *.h files should be > >> > > >> > 1. patched with commmit > >> > 2. run through indent > >> > 3. actual patch/commit generated and put into svn. > >> > > >> > can svn do this - ie add a stage in the commit pipeline? that's the q. > >> > otherwise its a policy and people need to remember to run indent on their > >> > edited files (or new added files). > >> > > >> > >> Should be doable with a pre-commit hook. > > > > pre-commit is allowed to modify the content of the incoming code of that > > commit before merge to the code in the tree? if so - good. then that should > > be used. once we agree on the indent arguments. > > > > Apparently, it can but it's not a good idea. It can cause problems with local > cache kept by svn, so the usual advice is to reject commits and not modify > them. what kind of problems? as such all svn needs to do is 1. get "current file" from svn 2. get "new file" from client (not a diff) 3. run indent on "new file" from client 4. generate diff from these 2 files now 5. record and apply diff to "current file" the svn data shouldnt care as svn's copies of it (and thus caches) are using a modified commit to modify the svn files in the normal way (normally logically step 3 doesnt exist. we added it). > >> >> Hey, > >> >> > >> >> I think that we all agree that the current mix of whitespace and > >> >> tabulation in most of the source code is not that very nice. > >> >> Also, the libraries are often using the coding style of the original > >> >> author, hence we have several different coding style in different > >> >> libraries (eina being even worse, as it uses both raster and Jorge > >> >> coding style...) > >> >> > >> >> As we plan to release the EFL, maybe it would be good to choose a common > >> >> coding style and to modify the source code accordingly (preferably > >> >> before the release, but that can be done after as it would be a lot of > >> >> work). > >> >> > >> >> I have attached a proposal. The structure is based on the cairo coding > >> >> style file (I have copy/pasted most of the sentences as I'm not an > >> >> english speaker/writer, but I modified the examples of course...). > >> >> > >> >> Feel free to give your ideas, remarks, modifications, additions, etc... > >> >> We are not in a hurry, so discussion is welcome, of course. > >> >> > >> >> Once we all agree on a coding style, i think that such file should be > >> >> included in all EFL svn repo and future tarballs. > >> >> > >> >> regards > >> >> > >> >> Vincent > >> > > >> > > >> > -- > >> > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >> > The Rasterman (Carsten Haitzler) ra...@ra... > >> > > >> > > >> > ------------------------------------------------------------------------------ > >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > >> > 30-Day trial. Simplify your report design, integration and deployment - > >> > and focus on what you do best, core application coding. Discover what's > >> > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> > _______________________________________________ > >> > enlightenment-devel mailing list > >> > enl...@li... > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > >> > >> ------------------------------------------------------------------------------ > >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > >> trial. Simplify your report design, integration and deployment - and focus > >> on what you do best, core application coding. Discover what's new with > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enl...@li... > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: André D. <and...@gm...> - 2010-03-23 23:52:42
|
Ressurecting this discussion... any new thoughts? On Thu, Sep 3, 2009 at 9:20 PM, Carsten Haitzler <ra...@ra...>wrote: > On Thu, 3 Sep 2009 18:54:40 -0300 Iván Briano (Sachiel) < > sac...@gm...> > said: > > > On Thu, Sep 3, 2009 at 6:25 PM, Carsten Haitzler<ra...@ra...> > wrote: > > > On Thu, 3 Sep 2009 10:07:54 -0300 Iván Briano (Sachiel) < > sac...@gm...> > > > said: > > > > > >> On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra... > > > > >> wrote: > > >> > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri > > >> > <vt...@un...> said: > > >> > > > >> > hmm i disagree with some of the doc. specifically > > >> > > > >> > blah > > >> > { > > >> > xx; > > >> > } > > >> > > > >> > i have always had/used: > > >> > blah > > >> > { > > >> > xx; > > >> > } > > >> > > > >> > ie {}'s are indented a bit. > > >> > > > >> > but... we can argue over little things all day long. imho the ONLY > way > > >> > this will work is if we have an indent line/rule that works. and the > > >> > only way this will work is if we require code is "indented" before a > > >> > commit. in fact i'd even consider this should be done as part of > the > > >> > commit p;rocess automatically. all *.c *.h files should be > > >> > > > >> > 1. patched with commmit > > >> > 2. run through indent > > >> > 3. actual patch/commit generated and put into svn. > > >> > > > >> > can svn do this - ie add a stage in the commit pipeline? that's the > q. > > >> > otherwise its a policy and people need to remember to run indent on > their > > >> > edited files (or new added files). > > >> > > > >> > > >> Should be doable with a pre-commit hook. > > > > > > pre-commit is allowed to modify the content of the incoming code of > that > > > commit before merge to the code in the tree? if so - good. then that > should > > > be used. once we agree on the indent arguments. > > > > > > > Apparently, it can but it's not a good idea. It can cause problems with > local > > cache kept by svn, so the usual advice is to reject commits and not > modify > > them. > > what kind of problems? as such all svn needs to do is > > 1. get "current file" from svn > 2. get "new file" from client (not a diff) > 3. run indent on "new file" from client > 4. generate diff from these 2 files now > 5. record and apply diff to "current file" > > the svn data shouldnt care as svn's copies of it (and thus caches) are > using a > modified commit to modify the svn files in the normal way (normally > logically > step 3 doesnt exist. we added it). > > > >> >> Hey, > > >> >> > > >> >> I think that we all agree that the current mix of whitespace and > > >> >> tabulation in most of the source code is not that very nice. > > >> >> Also, the libraries are often using the coding style of the > original > > >> >> author, hence we have several different coding style in different > > >> >> libraries (eina being even worse, as it uses both raster and Jorge > > >> >> coding style...) > > >> >> > > >> >> As we plan to release the EFL, maybe it would be good to choose a > common > > >> >> coding style and to modify the source code accordingly (preferably > > >> >> before the release, but that can be done after as it would be a lot > of > > >> >> work). > > >> >> > > >> >> I have attached a proposal. The structure is based on the cairo > coding > > >> >> style file (I have copy/pasted most of the sentences as I'm not an > > >> >> english speaker/writer, but I modified the examples of course...). > > >> >> > > >> >> Feel free to give your ideas, remarks, modifications, additions, > etc... > > >> >> We are not in a hurry, so discussion is welcome, of course. > > >> >> > > >> >> Once we all agree on a coding style, i think that such file should > be > > >> >> included in all EFL svn repo and future tarballs. > > >> >> > > >> >> regards > > >> >> > > >> >> Vincent > > >> > > > >> > > > >> > -- > > >> > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > >> > The Rasterman (Carsten Haitzler) ra...@ra... > > >> > > > >> > > > >> > > ------------------------------------------------------------------------------ > > >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > >> > 30-Day trial. Simplify your report design, integration and > deployment - > > >> > and focus on what you do best, core application coding. Discover > what's > > >> > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > >> > _______________________________________________ > > >> > enlightenment-devel mailing list > > >> > enl...@li... > > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >> > > > >> > > >> > ------------------------------------------------------------------------------ > > >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > >> trial. Simplify your report design, integration and deployment - and > focus > > >> on what you do best, core application coding. Discover what's new with > > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > > >> _______________________________________________ > > >> enlightenment-devel mailing list > > >> enl...@li... > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- André Dieb Martins Embedded Systems and Pervasive Computing Lab (Embedded) Electrical Engineering Department (DEE) Center of Electrical Engineering and Informatics (CEEI) Federal University of Campina Grande (UFCG) Blog: http://genuinepulse.blogspot.com/ |
From: Carsten H. (T. R. <ra...@ra...> - 2010-03-24 00:11:57
|
On Tue, 23 Mar 2010 20:23:05 -0300 André Dieb <and...@gm...> said: none - other than this actually being done. :) > Ressurecting this discussion... any new thoughts? > > On Thu, Sep 3, 2009 at 9:20 PM, Carsten Haitzler <ra...@ra...>wrote: > > > On Thu, 3 Sep 2009 18:54:40 -0300 Iván Briano (Sachiel) < > > sac...@gm...> > > said: > > > > > On Thu, Sep 3, 2009 at 6:25 PM, Carsten Haitzler<ra...@ra...> > > wrote: > > > > On Thu, 3 Sep 2009 10:07:54 -0300 Iván Briano (Sachiel) < > > sac...@gm...> > > > > said: > > > > > > > >> On Wed, Sep 2, 2009 at 9:43 PM, Carsten Haitzler<ra...@ra... > > > > > > >> wrote: > > > >> > On Sun, 30 Aug 2009 07:40:47 +0200 (CEST) Vincent Torri > > > >> > <vt...@un...> said: > > > >> > > > > >> > hmm i disagree with some of the doc. specifically > > > >> > > > > >> > blah > > > >> > { > > > >> > xx; > > > >> > } > > > >> > > > > >> > i have always had/used: > > > >> > blah > > > >> > { > > > >> > xx; > > > >> > } > > > >> > > > > >> > ie {}'s are indented a bit. > > > >> > > > > >> > but... we can argue over little things all day long. imho the ONLY > > way > > > >> > this will work is if we have an indent line/rule that works. and the > > > >> > only way this will work is if we require code is "indented" before a > > > >> > commit. in fact i'd even consider this should be done as part of > > the > > > >> > commit p;rocess automatically. all *.c *.h files should be > > > >> > > > > >> > 1. patched with commmit > > > >> > 2. run through indent > > > >> > 3. actual patch/commit generated and put into svn. > > > >> > > > > >> > can svn do this - ie add a stage in the commit pipeline? that's the > > q. > > > >> > otherwise its a policy and people need to remember to run indent on > > their > > > >> > edited files (or new added files). > > > >> > > > > >> > > > >> Should be doable with a pre-commit hook. > > > > > > > > pre-commit is allowed to modify the content of the incoming code of > > that > > > > commit before merge to the code in the tree? if so - good. then that > > should > > > > be used. once we agree on the indent arguments. > > > > > > > > > > Apparently, it can but it's not a good idea. It can cause problems with > > local > > > cache kept by svn, so the usual advice is to reject commits and not > > modify > > > them. > > > > what kind of problems? as such all svn needs to do is > > > > 1. get "current file" from svn > > 2. get "new file" from client (not a diff) > > 3. run indent on "new file" from client > > 4. generate diff from these 2 files now > > 5. record and apply diff to "current file" > > > > the svn data shouldnt care as svn's copies of it (and thus caches) are > > using a > > modified commit to modify the svn files in the normal way (normally > > logically > > step 3 doesnt exist. we added it). > > > > > >> >> Hey, > > > >> >> > > > >> >> I think that we all agree that the current mix of whitespace and > > > >> >> tabulation in most of the source code is not that very nice. > > > >> >> Also, the libraries are often using the coding style of the > > original > > > >> >> author, hence we have several different coding style in different > > > >> >> libraries (eina being even worse, as it uses both raster and Jorge > > > >> >> coding style...) > > > >> >> > > > >> >> As we plan to release the EFL, maybe it would be good to choose a > > common > > > >> >> coding style and to modify the source code accordingly (preferably > > > >> >> before the release, but that can be done after as it would be a lot > > of > > > >> >> work). > > > >> >> > > > >> >> I have attached a proposal. The structure is based on the cairo > > coding > > > >> >> style file (I have copy/pasted most of the sentences as I'm not an > > > >> >> english speaker/writer, but I modified the examples of course...). > > > >> >> > > > >> >> Feel free to give your ideas, remarks, modifications, additions, > > etc... > > > >> >> We are not in a hurry, so discussion is welcome, of course. > > > >> >> > > > >> >> Once we all agree on a coding style, i think that such file should > > be > > > >> >> included in all EFL svn repo and future tarballs. > > > >> >> > > > >> >> regards > > > >> >> > > > >> >> Vincent > > > >> > > > > >> > > > > >> > -- > > > >> > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > >> > The Rasterman (Carsten Haitzler) ra...@ra... > > > >> > > > > >> > > > > >> > > > ------------------------------------------------------------------------------ > > > >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > > >> > 30-Day trial. Simplify your report design, integration and > > deployment - > > > >> > and focus on what you do best, core application coding. Discover > > what's > > > >> > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > >> > _______________________________________________ > > > >> > enlightenment-devel mailing list > > > >> > enl...@li... > > > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > >> > > > > >> > > > >> > > ------------------------------------------------------------------------------ > > > >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day > > > >> trial. Simplify your report design, integration and deployment - and > > focus > > > >> on what you do best, core application coding. Discover what's new with > > > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > >> _______________________________________________ > > > >> enlightenment-devel mailing list > > > >> enl...@li... > > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > > > > > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > > on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > André Dieb Martins > > Embedded Systems and Pervasive Computing Lab (Embedded) > Electrical Engineering Department (DEE) > Center of Electrical Engineering and Informatics (CEEI) > Federal University of Campina Grande (UFCG) > > Blog: http://genuinepulse.blogspot.com/ > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Tom H. <to...@st...> - 2010-03-24 11:01:29
|
On Wed, Mar 24, 2010 at 1:23 AM, André Dieb <and...@gm...> wrote: > Ressurecting this discussion... any new thoughts? > > Having a sane and consistent coding style is very important, it annoyed me quite often when I worked with e's code. There are two important things needed to be done: 1. Having a simple and comprehensive text explaining the coding style. 2. Having a working 'indent' command that changes the code to the wanted style. (Not trivial at all, gnu-indent has it's share of issues). I found this line in your email: "I have attached a proposal. The structure is based on the cairo" Thoguh I have failed to find it. It's probably because my eyes lost track because of all the mess. If you can do section 1 for your suggestion, that would be great, this way people will be able to respond in a sane manner. Just my thoughts, -- Tom. P.S Concerning: > i have always had/used: > blah > { > xx; > } > > ie {}'s are indented a bit. I hate it, always have. I actually really like the kernel's coding conventions: http://www.kernel.org/doc/Documentation/CodingStyle |
From: Gustavo S. B. <bar...@pr...> - 2010-03-24 11:19:50
|
On Wed, Mar 24, 2010 at 8:01 AM, Tom Hacohen <to...@st...> wrote: > On Wed, Mar 24, 2010 at 1:23 AM, André Dieb <and...@gm...> wrote: > >> Ressurecting this discussion... any new thoughts? >> >> Having a sane and consistent coding style is very important, it annoyed me > quite often when I worked with e's code. > There are two important things needed to be done: > 1. Having a simple and comprehensive text explaining the coding style. > 2. Having a working 'indent' command that changes the code to the wanted > style. (Not trivial at all, gnu-indent has it's share of issues). agreed. > I found this line in your email: "I have attached a proposal. The structure > is based on the cairo" Thoguh I have failed to find it. > It's probably because my eyes lost track because of all the mess. If you can > do section 1 for your suggestion, that would be great, > this way people will be able to respond in a sane manner. This was from vincent I guess. > Just my thoughts, > -- > Tom. > > P.S > Concerning: >> i have always had/used: >> blah >> { >> xx; >> } >> >> ie {}'s are indented a bit. > > I hate it, always have. I actually really like the kernel's coding > conventions: http://www.kernel.org/doc/Documentation/CodingStyle Well, there is always a coding style one will hate, and another will love. As this is meritocracy and raster did most of the code, it's better to have others to follow him than force him to use some random style because people don't like it. The funny thing about this is that the majority of the people that complain do the minority of the code :-/ And no, saying one does not write code because of the style is not a valid option. :-D BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Tom H. <to...@st...> - 2010-03-24 13:22:45
|
> > I hate it, always have. I actually really like the kernel's coding > > conventions: http://www.kernel.org/doc/Documentation/CodingStyle > > Well, there is always a coding style one will hate, and another will > love. As this is meritocracy and raster did most of the code, it's > better to have others to follow him than force him to use some random > style because people don't like it. > I agree. > > The funny thing about this is that the majority of the people that > complain do the minority of the code Of course, the guys that actually write code, are too busy coding to complain. > :-/ And no, saying one does not write code because of the style is not a > valid option. :-D > -- Tom. |
From: Tom H. <tom...@gm...> - 2010-03-24 11:45:40
|
http://trac.enlightenment.org/e/wiki/ECoding How about updating this page to show the correct code styling? And have it as a policy that all new contributors must read before gaining access? (And of course, strongly encouraging current contributors to read it) Heres what the Gnomers have http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html which is a fairly comprehensive guide and probably a little long winded for us. Toma. On 24 March 2010 19:19, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > On Wed, Mar 24, 2010 at 8:01 AM, Tom Hacohen <to...@st...> wrote: > > On Wed, Mar 24, 2010 at 1:23 AM, André Dieb <and...@gm...> wrote: > > > >> Ressurecting this discussion... any new thoughts? > >> > >> Having a sane and consistent coding style is very important, it annoyed me > > quite often when I worked with e's code. > > There are two important things needed to be done: > > 1. Having a simple and comprehensive text explaining the coding style. > > 2. Having a working 'indent' command that changes the code to the wanted > > style. (Not trivial at all, gnu-indent has it's share of issues). > > agreed. > > > > I found this line in your email: "I have attached a proposal. The structure > > is based on the cairo" Thoguh I have failed to find it. > > It's probably because my eyes lost track because of all the mess. If you can > > do section 1 for your suggestion, that would be great, > > this way people will be able to respond in a sane manner. > > This was from vincent I guess. > > > > Just my thoughts, > > -- > > Tom. > > > > P.S > > Concerning: > >> i have always had/used: > >> blah > >> { > >> xx; > >> } > >> > >> ie {}'s are indented a bit. > > > > I hate it, always have. I actually really like the kernel's coding > > conventions: http://www.kernel.org/doc/Documentation/CodingStyle > > Well, there is always a coding style one will hate, and another will > love. As this is meritocracy and raster did most of the code, it's > better to have others to follow him than force him to use some random > style because people don't like it. > > The funny thing about this is that the majority of the people that > complain do the minority of the code :-/ And no, saying one does not > write code because of the style is not a valid option. :-D > > BR, > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: Vincent T. <vt...@un...> - 2010-03-24 13:08:48
|
On Wed, 24 Mar 2010, Tom Haste wrote: > http://trac.enlightenment.org/e/wiki/ECoding > > How about updating this page to show the correct code styling? And > have it as a policy that all new contributors must read before gaining > access? (And of course, strongly encouraging current contributors to > read it) > > Heres what the Gnomers have > http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html > which is a fairly comprehensive guide and probably a little long winded for us. here is what i've written: http://sourceforge.net/mailarchive/forum.php?thread_name=b057382e0908301207n65753602lf49124f0649bb3d6%40mail.gmail.com&forum_name=enlightenment-devel there is the attach doc in my first post. I tried to write something that is logical and easy to read. Note that it is not my own coding style. Also everyone has its own coding style, and will not agree with it. So if everyone stand on its position, don't want it because of just one thing, and don't want make an effort, (even if they can use 'indent'), that thread is useless. Vincent |
From: Lucas De M. <luc...@pr...> - 2010-03-25 02:12:01
|
On Wed, Mar 24, 2010 at 8:19 AM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Wed, Mar 24, 2010 at 8:01 AM, Tom Hacohen <to...@st...> wrote: >> On Wed, Mar 24, 2010 at 1:23 AM, André Dieb <and...@gm...> wrote: >> >>> Ressurecting this discussion... any new thoughts? >>> >>> Having a sane and consistent coding style is very important, it annoyed me >> quite often when I worked with e's code. >> There are two important things needed to be done: >> 1. Having a simple and comprehensive text explaining the coding style. >> 2. Having a working 'indent' command that changes the code to the wanted >> style. (Not trivial at all, gnu-indent has it's share of issues). > > agreed. > k-s, what about sharing you checkpatch so one might improve and make it work? Lucas De Marchi |
From: Gustavo S. B. <bar...@pr...> - 2010-03-25 02:16:52
|
On Wed, Mar 24, 2010 at 11:11 PM, Lucas De Marchi <luc...@pr...> wrote: > On Wed, Mar 24, 2010 at 8:19 AM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: >> On Wed, Mar 24, 2010 at 8:01 AM, Tom Hacohen <to...@st...> wrote: >>> On Wed, Mar 24, 2010 at 1:23 AM, André Dieb <and...@gm...> wrote: >>> >>>> Ressurecting this discussion... any new thoughts? >>>> >>>> Having a sane and consistent coding style is very important, it annoyed me >>> quite often when I worked with e's code. >>> There are two important things needed to be done: >>> 1. Having a simple and comprehensive text explaining the coding style. >>> 2. Having a working 'indent' command that changes the code to the wanted >>> style. (Not trivial at all, gnu-indent has it's share of issues). >> >> agreed. >> > k-s, > > what about sharing you checkpatch so one might improve and make it work? it was in SVN under SCRIPTS or scripts, don't recall the name :-P It was very, very simple, just a list of regexp + messages -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |