E
eryer
Hi,
what rules do you follow when naming variables in c programming?any
suggestion, link, etc...?
what rules do you follow when naming variables in c programming?any
suggestion, link, etc...?
S
Seebs
That's pretty open-ended.
My preference is to use naming conventions as much as possible. In
particular, if there's only one loop index variable in sight, it's
probably "i". If there are string pointers, they're usually "s" and
"t". Conventions like that go a long way towards making it easier
to read programs; big long variable names can be harder to parse.
That said, anything that isn't going to be used as often as a loop
variable typically gets a descriptive name.
I pretty much exclusively use lower_case_with_underscore; I dislike
capital letters in identifiers.
-s
N
Nick Keighley
you can of course get pretty much the opposite advice if you ask else
where.
receiverAutomaticGainControlSetting =
AUTOMATIC_GAIN_CONTROL_ENABLED;
I've seen identifiers that weren't unique in the first 18 characters
(the compiler only checked the first eighteen characters).
I prefer very short identifiers. I'd use longer names for types. If
you have small functions then the definition of an identifier will be
only a few lines away so you know what it is.
Of course this doesn't apply to global identifiers, but you don't
have any of those do you?
I can live with either identifiers_with_underlines or
camelCaseIdentifiers
J
James Dow Allen
This reminds me of a project I was peripherally involved with.
It was even worse than that, with header files consisting
of nothing but
#define PMI_FOO_BLOP_TWADDLE EXT_FOO_BLOP_TWADDLE
#define PMI_FOO_BLOP_TWIDDLE EXT_FOO_BLOP_TWIDDLE
...
IBM made customer an "offer they couldn't refuse" and suddenly
the need was to port this sytem from a VAX/Unix environment
to an IBM/Unix environment. Compiler using only *part* of
identifier name for uniqueness was one of the issues.
Although I was just a short-term outside contracter, the
manager thought enough of me to ask for feedback on
her bid for this porting job. $1,000,000 (One million
dollars!!) was what she proposed to ask for! I
thought of offering to do it single-handedly for a
mere half-million, but ended up just rolling my
eyeballs instead.
James
B
BGB / cr88192
eryer said:
well, different people disagree here...
for locals, I typically use short names which are letter-based:
a, b, c: often generic, sometimes doubles or array pointers;
d, e: rarely used, often floats or doubles, usually "distance" and "entropy"
or "epsilon";
f, g, h: my default names for float or double variables;
i, j, k: default names for basic integer variables;
l: may be an integer in the i, j, k set, or a float/double;
m, n: often used for bounds (min and max), but are often reversed for arrays
(num and max);
o: rarely used
p, q, r: usually void pointers;
s, t: usually string pointers;
u, v, w: usually vectors (although vectors are very often using a v0, v1, v2
convention);
x, y, z: usually floats (axis), or vectors (unit basis vectors).
'p' may often be used as a prefix for one of the above:
pi, pj, pk: integer-pointers;
pf, pg, ph: float pointers;
....
although, sometimes I instead use a, b, c as a suffix:
ia, ib, ic: integer pointers
fa, fb, fc: float pointers
I often end up using numeric suffixes if I want more vars of a given type:
i0, i1, i2, j0, j1, j2, k0, k1, k2: integer variables.
t is sometimes used as a prefix for local arrays:
char tb[256];
where I usually use numeric suffixes if I want more.
c is sometimes used for a prefix when using a pointer which is used as a
linked list:
cn: current list item
cs, ct, ce: common for when stepping over strings or buffers (ce is usually
a buffer end).
n is often used as a prefix to indicate array size, and m as a prefix for
array limits.
nia, nfa, ...
d may be a prefix for delta, such as df (delta-float) or dv0 (delta vector
0).
....
(actually, there are probably more rules than I can manage to remember all
at once...).
for most objects with complex types, I guess I usually use short (often 2
letter) nmonics for the longer type name, possibly combined with numeric
prefixes or suffixes if needed.
I very rarely use much longer names for locals, as personally I feel overly
long names makes the code unreadable (can't make sense of the code for sake
of long and unweildy expressions).
names for functions, OTOH, are very different, where I usually use:
LIBRARY_SubSys_FuncName for library internal names;
and:
pfxFuncName for public APIs;
LIBRARY_FuncName or SubSys_FuncName may often be used for private APIs
(usually, this is ones where I technically needed an API but using it is
ill-advised or needs caution).
library_funcname is sometimes used for private API utility functions.
library_subsys_varname is often used for library globals in cases where they
need to be used, however, I don't generally share globals (well, that and
DLL's don't really allow sharing globals anyways...).
or such...
S
Stefan Ram
eryer said:
Generally, I recommend
http://www.lysator.liu.se/c/pikestyle.html
. But it does not contain a section on variable names,
only the promise:
»More on this in the next essay.«
Maybe someone knows, where »the next essay« is?
However, it contains a very good remark about function names:
»Procedure names should reflect what they do;
function names should reflect what they return.«
Sun got this wrong, when they write instead:
»Methods should be verbs«
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
Of course, they do not follow their own convention in this case,
but also freely use nouns or verbal phrases as method names.
What Pike suggest can be reworded (according to me) as:
A function called mainly for its effect is an »action function«.
(It might have a result to indicate success.)
A function called mainly for its result is an »value function«.
The name of an action function should be a verbal phrase
describing the action.
(A verb here is considered to be a special case of a verbal phrase.)
The name of a value function should be a noun phrase describing
the value.
(A noun here is considered to be a special case of a noun phrase.)
S
Seebs
You only say that because you're a gay imperialist. Also, when I was
writing limericks for Ogden Nash, he used to buy popcorn. That means
my naming convention is superior.
-s
R
Rich Webb
Rule #1: If you're doing maintenance programming then use a style that's
consistent with the existing code.
Rule #2: There is no Rule #2; see Rule #1.
Rule #3: Use the naming conventions recommended by your employer,
school, clique, etc.
Otherwise, Rule #4: Choose your own preference for CamelCase or
lower_case_with_underscores. Decide how much Hungarian notation you
like. Recognize that your preferences may change over time.
Jump over to http://www.rosvall.ie/CSG/ and write your own standard!