Re: LyX Coding Rules and Recommendations
Am 27.10.2010 um 07:04 schrieb Vincent van Ravesteijn: Hi All, I converted the two files about Rules and Recommendation into a LyX document. You might want to have a look at it, and put your two cents in there about coding principle, style and so forth. It is still a bit a mess, but I hope it will get better. Everyone is invited to edit. Please turn on change tracking. I will take the responsibility to edit the file and accept the changes from time to time. Maybe we can create another document on the design principles and major structure in the LyX code. There are already some pieces, but we have to get them up to date and to put them in one place. Comments ? Good idea. Thank you for the efforts. Stephan
Re: LyX Coding Rules and Recommendations
Stephan Witt wrote: Maybe we can create another document on the design principles and major structure in the LyX code. There are already some pieces, but we have to get them up to date and to put them in one place. Comments ? perhaps kill the old ascii file (or move it to attic) so there is unambiguous location. also you nice log about casts could be saved somewhere. as for structures i tried to collect some things fro maillist in http://wiki.lyx.org/Devel/Diagrams long time ago, but mostly outdated now i think. pavel
Re: LyX Coding Rules and Recommendations
perhaps kill the old ascii file (or move it to attic) so there is unambiguous location. Yes, I will. I wanted to wait until this new document is somewhat decent (I'm not sure why though). also you nice log about casts could be saved somewhere. It's already in there, but I hide it in the appendix for now among the other stuff that need to find their way. as for structures i tried to collect some things fro maillist in http://wiki.lyx.org/Devel/Diagrams long time ago, but mostly outdated now i think. I'm not yet sure whether we should make one document of both the Rules/Language Advice/Style and the implementation/design issues. pavel Vincent
Re: LyX Coding Rules and Recommendations
Vincent van Ravesteijn wrote: I'm not yet sure whether we should make one document of both the Rules/Language Advice/Style and the implementation/design issues. i would prefer one doc. pavel
Re: LyX Coding Rules and Recommendations
Am 27.10.2010 um 07:04 schrieb Vincent van Ravesteijn: > Hi All, > > I converted the two files about Rules and Recommendation into a LyX > document. You might want to have a look at it, and put your two cents > in there about coding principle, style and so forth. It is still a bit > a mess, but I hope it will get better. > > Everyone is invited to edit. Please turn on change tracking. I will > take the responsibility to edit the file and accept the changes from > time to time. > > Maybe we can create another document on the design principles and > major structure in the LyX code. There are already some pieces, but we > have to get them up to date and to put them in one place. > > Comments ? Good idea. Thank you for the efforts. Stephan
Re: LyX Coding Rules and Recommendations
Stephan Witt wrote: > > Maybe we can create another document on the design principles and > > major structure in the LyX code. There are already some pieces, but we > > have to get them up to date and to put them in one place. > > > > Comments ? perhaps kill the old ascii file (or move it to attic) so there is unambiguous location. also you nice log about casts could be saved somewhere. as for structures i tried to collect some things fro maillist in http://wiki.lyx.org/Devel/Diagrams long time ago, but mostly outdated now i think. pavel
Re: LyX Coding Rules and Recommendations
> perhaps kill the old ascii file (or move it to attic) so there is unambiguous > location. Yes, I will. I wanted to wait until this new document is somewhat decent (I'm not sure why though). >also you nice log about casts could be saved somewhere. It's already in there, but I hide it in the appendix for now among the other stuff that need to find their way. > as for structures i tried to collect some things fro maillist in > http://wiki.lyx.org/Devel/Diagrams > long time ago, but mostly outdated now i think. I'm not yet sure whether we should make one document of both the Rules/Language Advice/Style and the implementation/design issues. > > pavel > Vincent
Re: LyX Coding Rules and Recommendations
Vincent van Ravesteijn wrote: > I'm not yet sure whether we should make one document of both the > Rules/Language Advice/Style and the implementation/design issues. i would prefer one doc. pavel
LyX Coding Rules and Recommendations
Hi All, I converted the two files about Rules and Recommendation into a LyX document. You might want to have a look at it, and put your two cents in there about coding principle, style and so forth. It is still a bit a mess, but I hope it will get better. Everyone is invited to edit. Please turn on change tracking. I will take the responsibility to edit the file and accept the changes from time to time. Maybe we can create another document on the design principles and major structure in the LyX code. There are already some pieces, but we have to get them up to date and to put them in one place. Comments ? Vincent
LyX Coding Rules and Recommendations
Hi All, I converted the two files about Rules and Recommendation into a LyX document. You might want to have a look at it, and put your two cents in there about coding principle, style and so forth. It is still a bit a mess, but I hope it will get better. Everyone is invited to edit. Please turn on change tracking. I will take the responsibility to edit the file and accept the changes from time to time. Maybe we can create another document on the design principles and major structure in the LyX code. There are already some pieces, but we have to get them up to date and to put them in one place. Comments ? Vincent
Changes to coding rules
Should be uncontroversial, but I'll wait for a nod. I have a few more controversial ones up my sleeve... Andre' Index: Rules === --- Rules (revision 20603) +++ Rules (working copy) @@ -12,6 +12,7 @@ but still, we don't want it to happen again. So we have put together some guidelines and rules for the developers. + General --- @@ -61,17 +62,10 @@ send patches that implements or fixes several different things; several patches is a much better option. -We also require you to provide a ChangeLog entry with every patch, this -describes shortly what the patch is doing. The ChangeLog entry follows -this syntax: +We also require you to provide a commit message entry with every patch, +this describes shortly what the patch is doing. -1999-12-13 Lars Gullik Bj�nnes [EMAIL PROTECTED] - * src/support/lyxstring.C (find): assert bug fixed. - -Note that there are specific ChangeLogs for most directories; use those -rather than the top-level one. - Code Constructs --- @@ -85,7 +79,7 @@ user defined types, and these can very often be expensive to initialize. This rule connects to the next rule too. -- declare the variable as const if you don't need to change it. This +- Declare the variable as const if you don't need to change it. This applies to POD types like int as well as classes. - Make the scope of a variable as small as possible. @@ -140,6 +134,7 @@ default: ...; break; // not needed and would shadow a wrong use of Foo } + Exceptions -- @@ -321,7 +316,7 @@ like this : /** - * \file NewFile.C + * \file NewFile.cpp * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * @@ -335,7 +330,7 @@ - The documentation is generated from the header files. - You document for the other developers, not for yourself. - You should document what the function does, not the implementation. - - in the .C files you document the implementation. + - in the .cpp files you document the implementation. - Single line description (///), multiple lines description (/** ... */) - see the doxygen webpage referenced above
Re: Changes to coding rules
Andre Poenitz [EMAIL PROTECTED] writes: -We also require you to provide a ChangeLog entry with every patch, this -describes shortly what the patch is doing. The ChangeLog entry follows -this syntax: +We also require you to provide a commit message entry with every patch, +this describes shortly what the patch is doing. -1999-12-13 Lars Gullik Bj�nnes [EMAIL PROTECTED] - * src/support/lyxstring.C (find): assert bug fixed. - -Note that there are specific ChangeLogs for most directories; use those -rather than the top-level one. - I'd rather keep verbose entries in svn logs. JMarc
Re: Changes to coding rules
On Sun, Sep 30, 2007 at 05:42:51PM +0200, Jean-Marc Lasgouttes wrote: Andre Poenitz [EMAIL PROTECTED] writes: -We also require you to provide a ChangeLog entry with every patch, this -describes shortly what the patch is doing. The ChangeLog entry follows -this syntax: +We also require you to provide a commit message entry with every patch, +this describes shortly what the patch is doing. -1999-12-13 Lars Gullik Bj?nnes [EMAIL PROTECTED] - * src/support/lyxstring.C (find): assert bug fixed. - -Note that there are specific ChangeLogs for most directories; use those -rather than the top-level one. - I'd rather keep verbose entries in svn logs. So reformulate short? Andre'
Re: Changes to coding rules
Andre Poenitz [EMAIL PROTECTED] writes: So reformulate short? Thanks. JMarc
Changes to coding rules
Should be uncontroversial, but I'll wait for a nod. I have a few more controversial ones up my sleeve... Andre' Index: Rules === --- Rules (revision 20603) +++ Rules (working copy) @@ -12,6 +12,7 @@ but still, we don't want it to happen again. So we have put together some guidelines and rules for the developers. + General --- @@ -61,17 +62,10 @@ send patches that implements or fixes several different things; several patches is a much better option. -We also require you to provide a ChangeLog entry with every patch, this -describes shortly what the patch is doing. The ChangeLog entry follows -this syntax: +We also require you to provide a commit message entry with every patch, +this describes shortly what the patch is doing. -1999-12-13 Lars Gullik Bj�nnes <[EMAIL PROTECTED]> - * src/support/lyxstring.C (find): assert bug fixed. - -Note that there are specific ChangeLogs for most directories; use those -rather than the top-level one. - Code Constructs --- @@ -85,7 +79,7 @@ user defined types, and these can very often be expensive to initialize. This rule connects to the next rule too. -- declare the variable as const if you don't need to change it. This +- Declare the variable as const if you don't need to change it. This applies to POD types like int as well as classes. - Make the scope of a variable as small as possible. @@ -140,6 +134,7 @@ default: ...; break; // not needed and would shadow a wrong use of Foo } + Exceptions -- @@ -321,7 +316,7 @@ like this : /** - * \file NewFile.C + * \file NewFile.cpp * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * @@ -335,7 +330,7 @@ - The documentation is generated from the header files. - You document for the other developers, not for yourself. - You should document what the function does, not the implementation. - - in the .C files you document the implementation. + - in the .cpp files you document the implementation. - Single line description (///), multiple lines description (/** ... */) - see the doxygen webpage referenced above
Re: Changes to coding rules
Andre Poenitz <[EMAIL PROTECTED]> writes: > -We also require you to provide a ChangeLog entry with every patch, this > -describes shortly what the patch is doing. The ChangeLog entry follows > -this syntax: > +We also require you to provide a commit message entry with every patch, > +this describes shortly what the patch is doing. > > -1999-12-13 Lars Gullik Bj�nnes <[EMAIL PROTECTED]> > > - * src/support/lyxstring.C (find): assert bug fixed. > - > -Note that there are specific ChangeLogs for most directories; use those > -rather than the top-level one. > - I'd rather keep verbose entries in svn logs. JMarc
Re: Changes to coding rules
On Sun, Sep 30, 2007 at 05:42:51PM +0200, Jean-Marc Lasgouttes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > > -We also require you to provide a ChangeLog entry with every patch, this > > -describes shortly what the patch is doing. The ChangeLog entry follows > > -this syntax: > > +We also require you to provide a commit message entry with every patch, > > +this describes shortly what the patch is doing. > > > > -1999-12-13 Lars Gullik Bj?nnes <[EMAIL PROTECTED]> > > > > - * src/support/lyxstring.C (find): assert bug fixed. > > - > > -Note that there are specific ChangeLogs for most directories; use those > > -rather than the top-level one. > > - > > I'd rather keep verbose entries in svn logs. So reformulate "short"? Andre'
Re: Changes to coding rules
Andre Poenitz <[EMAIL PROTECTED]> writes: > So reformulate "short"? Thanks. JMarc
coding rules
I'd like to use development/Code_rules in some modified version for internal (more or less educational) purposes. I would of course include a small header concerning the origin of the document. Does anybody feel that this is not a good thing do? Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
RE: coding rules
On 07-Mar-2000 Andre Poenitz wrote: I'd like to use development/Code_rules in some modified version for internal (more or less educational) purposes. I would of course include a small header concerning the origin of the document. Does anybody feel that this is not a good thing do? I would say feel free to use it :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug All progress is based upon a universal innate desire of every organism to live beyond its income. -- Samuel Butler, "Notebooks" -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: coding rules
Andre Poenitz [EMAIL PROTECTED] writes: | I'd like to use development/Code_rules in some modified version for | internal (more or less educational) purposes. I would of course include a | small header concerning the origin of the document. | | Does anybody feel that this is not a good thing do? Just use it. Lgb
coding rules
I'd like to use development/Code_rules in some modified version for internal (more or less educational) purposes. I would of course include a small header concerning the origin of the document. Does anybody feel that this is not a good thing do? Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
RE: coding rules
On 07-Mar-2000 Andre Poenitz wrote: > > I'd like to use development/Code_rules in some modified version for > internal (more or less educational) purposes. I would of course include a > small header concerning the origin of the document. > > Does anybody feel that this is not a good thing do? > I would say feel free to use it :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug All progress is based upon a universal innate desire of every organism to live beyond its income. -- Samuel Butler, "Notebooks" -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: coding rules
Andre Poenitz <[EMAIL PROTECTED]> writes: | I'd like to use development/Code_rules in some modified version for | internal (more or less educational) purposes. I would of course include a | small header concerning the origin of the document. | | Does anybody feel that this is not a good thing do? Just use it. Lgb
