Changes to coding rules

2007-09-30 Thread Andre Poenitz

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

2007-09-30 Thread Jean-Marc Lasgouttes
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

2007-09-30 Thread Andre Poenitz
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

2007-09-30 Thread Jean-Marc Lasgouttes
Andre Poenitz [EMAIL PROTECTED] writes:

 So reformulate short?

Thanks.

JMarc


Changes to coding rules

2007-09-30 Thread Andre Poenitz

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

2007-09-30 Thread Jean-Marc Lasgouttes
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

2007-09-30 Thread Andre Poenitz
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

2007-09-30 Thread Jean-Marc Lasgouttes
Andre Poenitz <[EMAIL PROTECTED]> writes:

> So reformulate "short"?

Thanks.

JMarc