anne/lyx_mirror
1
0
Fork 0
mirror of https://git.lyx.org/repos/lyx.git synced 2024-12-22 13:18:28 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

update rules

Browse Source 
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@2420 a592a061-630c-0410-9148-cb99ea01b6c8
This commit is contained in:
Lars Gullik Bjønnes 2001-08-05 22:10:27 +00:00
parent d4d9fa230d
commit f6eefacf4b
2 changed files with 25 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
development/ChangeLog
View File

@ -1,3 +1,7 @@
2001-08-05 Lars Gullik Bjønnes <larsbj@birdstep.com>
* Code_rules/Rules: add some braces statements, fix some typos.
2001-05-16 Ruurd Reitsma <r.a.reitsma@wbmt.tudelft.nl> 2001-05-16 Ruurd Reitsma <r.a.reitsma@wbmt.tudelft.nl>
* Win32/lyxwin32.C added. * Win32/lyxwin32.C added.

27
development/Code_rules/Rules
View File

@ -28,9 +28,9 @@ that you:
This eases maintenance a lot. This eases maintenance a lot.
- write good C++ code: Readable, well commented and taking advantage of the - write good C++ code: Readable, well commented and taking advantage of the
OO model. Follow the formatting guidelines. See Formatting. OO model. Follow the formatting guidelines. See Formatting.
- adapt the code to the structures already existing in LyX, or in the case that - adapt the code to the structures already existing in LyX, or in the case
you have better ideas, discuss them on the developer's list before writing that you have better ideas, discuss them on the developer's list before
the code. writing the code.
- take advantage of the C++ standard library. especially don't use - take advantage of the C++ standard library. especially don't use
custom containers when a standard container is usable; learn to use custom containers when a standard container is usable; learn to use
the algorithms and functors in the standard library. the algorithms and functors in the standard library.
@ -61,7 +61,7 @@ lot easier to read than the other diff formats. Also please do not
send patches that implements or fixes several different things; several send patches that implements or fixes several different things; several
patches is a much better option. patches is a much better option.
We also expect you to provide a ChangeLog entry with every patch, this We also require you to provide a ChangeLog entry with every patch, this
describes shortly what the patch is doing. The ChangeLog entry follows describes shortly what the patch is doing. The ChangeLog entry follows
this syntax: this syntax:
@ -95,7 +95,7 @@ in C++.
- Prefer preincrement to postincrement whenever possible. - Prefer preincrement to postincrement whenever possible.
Preincrement has potential of being faster than postincrement. Just Preincrement has potential of being faster than postincrement. Just
thing about the obvious implementations of pre/post-increment. This think about the obvious implementations of pre/post-increment. This
rule applies to decrement too. rule applies to decrement too.
++T; ++T;
@ -247,6 +247,20 @@ Formatting
-NOT- -NOT-
void mangle () // wrong void mangle () // wrong
* Use of braces
We use braces a lot, even if this lowers the density of the code in
some cases. In particular we use braces for one-liners in relation
to if, while, etc.
if (true) {
do_that();
}
-NOT-
if (true)
do_that();
* Enumerators * Enumerators
enum { enum {
one = 1, one = 1,
@ -314,7 +328,8 @@ Formatting
* File headers * File headers
- If you create a new file, the top of the file should look something like this : - If you create a new file, the top of the file should look something
like this :
/** /**
* \file NewFile.C * \file NewFile.C