Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| > | By the way, this is written nowhere and I had the impression that
| > | "gui_instance_" style was the rule in the current code. Could you
| > | confirm that please because I used the "gui_instance_" style
| > | everywhere already :-(
| > Perhaps the wrong heading but... from development/Code_rules/Rules:
| > * Naming rules for classes
| > - Use descriptive but simple and short names. For
| > stuff specific to
| > LyX
| > use LyX as prefix. Some modules, like mathed or spellchecker,
| > could have
| > other prefixes.
| > [I am not so sure about the LyX prefix]
| > - Class names are usually capitalized, and function names
| > lowercased.
| > Enums are named like Classes, values are usually in lower-case.
| >
|
| Do you mean this one:
|
| > - Long variables are named like thisLongVariableName.
|
| So without the trailing underscore then?
No.
Private class member variables get a _ at the end.
| For me variables are temporary variables inside a function or variable
| passed to a function. We are talking here about class members. Note
| that this "thisLongVariableName" notation is used almost exclusively
| for class methods and general functions. If we use that for members
| and variables this would be misleading.
Then it is misleading. We use the same naming scheme for member
functions and member variables.
| Really if you look at current source code it is mostly this style:
|
| class ThisIsOneClass
| {
| void thisIsOneMethod(OneType one_type);
|
| OneType one_type_;
| }
Eh.. no. you have to look at more code.
| I think this coding style is nice as it is not misleading. So either
| we update the code rules or we change the source code. I obviously
| prefer the later.
but it is a mix of systems.
(and we have trouble sometimes to not follow stl and boost leads.)
--
Lgb
