Re: Simple memory class
On Jun 25, 12:17 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Barzo <dba...@gmail.com> writes:
0- I prefer the following case conventions:
- global variables, type and class name in CamelCase (with an
initial capital, without a specific prefix).
- local variables, parameters, method names in camelCase (with an
initial lowcase).
- I rather not use underlines in my identifers.
That's very much a personal preference. Just define a
convention, and stick with it. About the only objective rules
are:
-- Distinguish between preprocessor symbols and the others.
This is in some ways a absolute rule; on the other hand,
most programs shouldn't define any preprocessor symbols
anyway, except include guards (which should be inserted by
the editor, and should have a format which can't be mistaken
for anything else), so it really doesn't matter. The
"standard" convention, however, is that preprocessor symbols
are all caps. (I don't always follow it myself. But except
for include guards, all of my preprocessor symbols do have a
standard prefix which is all caps, and with very few
exceptions, all have very limited scope---I'll define a
macro for some boilerplate text, invoke it a couple of
times, and then immediately #undef it.)
-- Distinguish between type names and others. C++ parses
differently depending on whether a symbol names a type or
something else. The most frequent convention here is to
start a type name with a capital, anything else with a small
letter.
A lot of coding conventions don't respect this, so it
probably isn't an absolute rule, although I've found it
quite useful. Also, it doesn't address templates---whether
a name designates a template or not also affects parsing,
but all of the conventions I know treat the names of class
templates like type names, and the names of function
templates like function names.
-- Mark the separation of individual words in a symbol. There
are two wide spread conventions here: use an underline
(which looks sort of like a space), or start each new word
with a capital. E.g. "newValue" or "new_value" (but not
"newvalue". Which convention you choose isn't too
important, as long as you choose one, and stick to it.
1- Names starting with one or two underlines are reserved to the
system. Do not name it _buffer.
It is unfortunate that you cannot give the same name to a
method and to a field, but since I don't like prefixing the
field name by a letter (mBuffer), and I don't like readers to
be prefixed by get (getBuffer()), nowdays I tend to name fields
suffixed by an underline (which is ok for user identifiers).
vector<T>& buffer();
void setBuffer(const vector<T>& newData);
vector<T>& buffer_;
Leading and trailing underlines aren't very visible.
In principle, a name like "buffer" (and unqualified noun)
should be a type, not a variable or a function. The variable
would be myBuffer, or someParticularBuffer, and the function
name would contain a verb. And of course, if you follow this
rule strictly, you don't need anything else to distinguish
between typename and others. In practice, however, it doesn't
always work out that well. And some functions are just
"accessors"; conceptually, the function is simply the
presentation at the interface level of a member data element.
In such cases, get... and set.. do seem superfluous to me. So
some sort of convention does seem useful: my current practice is
to prefix member variables with "my" (e.g. myBuffer), and static
member variables with "our" (e.g. ourBuffer); this looks like
the original rule in which variable names should be qualified
nouns.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34