Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | 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.
|
| Where is that written? And what about protected member?
No _.
| In any case I
| never use public member variables.
Very good.
I even think that protected member variables should be avoided.
| > | 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.
|
| This is really not the case in current frontends/* source code.
Right. That code as not been following the rest of the source.
| For frontend/[qt3,qt4] I am quite sure I am right. But most code in
| the kernel is C-ish... So it is difficult to extract a rule there. But
| for your pleasure, let's look at some:
|
| BufferView:
|
| Pimpl * pimpl_; // should be Pimpl_
No. Variables, just as functions has a lowercase first letter, so
pimpl_ is correct.
| BufferView_pimpl:
|
| Timeout cursor_timeout; // should be cursorTimeout_
| bool multiparsel_cache_; // should be multiparselCache_
| lyx::pit_type anchor_ref_; // should be anchorRef_
| int offset_ref_; // should be offsetRef_
yes.
|
| mutable bool refresh_inside_; // should be RefreshInside_
refreshInside_
| encoding:
|
| std::string Name_; // name_
| std::string LatexName_; // latexName_
| Uchar encoding_table[256]; // encodingTable_
|
| EncodingList encodinglist; // encodingList_
| Encoding symbol_encoding_; // symbolEncoding_
right.
|
|
| So you see it's difficult to extract a clear figure from this code and
| I would say that the "one_type_" style is used quite often...
Yes, we have gotten confused by boost and stl/std.
--
Lgb
