I am not afraid of long variable and function names. I generally
follow
the naming recommendations in "Code Complete".
But I also find special abbreviations often to be more memorable and
useful, such as cnt for count, ndx for index, pck for pick, lo / hi
for
low / high, var for variable, rng for range, max / min, etc. And I
have
some variable names that are so long that it would help me to try
abbreviating "array".
I was thinking "ara" or "ary", but am not that excited about them,
maybe because they have two syllables or maybe because I
(and others) am not used to them.
Any thoughts? Is there a standard or suggested way to abbreviate
the word "array"? I looked in "Code Complete" and searched the
internet and found very little mention.
Thanks,
Daniel
arr?
--
Peter
vec, row, col
ray?! ;)
--
Peter
> It would be helpful for me to have an abbreviation of the word "array".
> Or an abbreviation for an alternate word that means the same thing. I
> use the word "array" as used in C, Java, or any standard language.
>
> I am not afraid of long variable and function names. I generally follow
> the naming recommendations in "Code Complete".
>
> But I also find special abbreviations often to be more memorable and
> useful, such as cnt for count, ndx for index, pck for pick, lo / hi for
> low / high, var for variable, rng for range, max / min, etc. And I have
> some variable names that are so long that it would help me to try
> abbreviating "array".
>
> I was thinking "ara" or "ary", but am not that excited about them, maybe
> because they have two syllables or maybe because I (and others) am not
> used to them.
>
> Any thoughts? Is there a standard or suggested way to abbreviate the
s
struct person {
int num;
char name[111];
date birth;
} persons[] =
{{ 1, "moi", 123456789}
,{ ... }
};
, but this is only possible for non-Hungarian naming.
HTH,
AvK
<--
arr?
-->
ARR!
we be the pirates of the ship in the C!...
or maybe capture a booty of fresh Java!...
beware of icebergs if you C#!...
or such...
How about "a"?
This issue was solved centuries ago in mathematics. All
variables are single-letter names. The quadratic equation
is written as:
a x^2 + b x + c = 0,
not
first_coeff * unknown^2
+ second_coeff * unknown
+ constant_term = 0.
In matrix algebra, an array is denoted by a single letter, say "a",
and the array's generic term is a[i]. Making it arr[ndx] just
muddies things.
--
Rouben Rostamian
I would suggest ra
Thanks for the replies and suggestions.
I had hoped there was some standard, because it's
better to use coding conventions that others understand.
My guess is there is no standard.
I think any almost any programmer would understand
hi / lo / cnt / ndx / max / min. I don't think it's quite as
obvious what arr / ray / vec / ra mean.
Just to clarify for Rouben, I'm not using the word "array" by
itself, or in a short name. In that case, it would be silly to
abbreviate. I'm using the word in combination with other words
in a much longer variable name, with multiple concepts in the
same name. As one example of many in the software:
"RWA_CAT_Set_HiPckNdx_Array_g". I need to trim two
characters to meet an internal coding standard. "Array"
is the likely victim.
As somewhat suggested, I could just use the single letter "a" in
the longer variable name to indicate an array, akin to Hungarian. But
I think using just one letter would be too obscure, especially for a
var name that is already pretty complicated and hard to understand.
And the program already uses many 3-character short-hands to
categorize variable types (CAT=category, RNG=range, TBL=table,
CHT=chart, etc), so I'd prefer to continue the convention.
The RWA_CAT_Set_HiPckNdx_Array_g example is a read-write
array (indicated by RWA). But, on reflection, it's actually an array
of pointers, not an array of arrays (which I was implying by saying
"Array"). Each pointer points to a read-write array (each element
is a "high pick index" for a "categorical set"). I apologize for the
detail. The point is another possibility is to use the well-known
abbreviation "Ptr" in place of "Array", since the concept is "pointer
to array". This would avoid the naming issue, but lose the
information
that behind the pointer is an array.
Another choice is to use RWA for "array". I already consistently use
RWA to start certain variable names. A negative is you can't easily
pronounce RWA. But it is pretty easily recognizable, at least to me.
My guess is others would pretty easily understand RWA (read-write
array) and ROA (read-only array), but I don't really know.
So I'm be thinking about the following choices, especially the last
three:
RWA_CAT_Set_HiPckNdx_Array_g - Original name. Need to trim by 2
RWA_CAT_Set_HiPckNdx_A_g - Too obscure? It's certainly short.
RWA_CAT_Set_HiPckNdx_Ra_g - Not personally attracted to this one
RWA_CAT_Set_HiPckNdx_Vec_g - Many people don't know what vector is.
RWA_CAT_Set_HiPckNdx_Ray_g - Not bad, but I like arr better.
RWA_CAT_Set_HiPckNdx_Arr_g - Kind of like it (ARR! ARR! ARR!)
RWA_CAT_Set_HiPckNdx_Ptr_g - Avoid naming issue. Use different
concept.
RWA_CAT_Set_HiPckNdx_RWA_g - Extend existing internal convention
Thanks,
Daniel
[need an abbreviation for "array"]
> > > I was thinking "ara" or "ary", but am not that excited about them,
> > > maybe because they have two syllables or maybe because I
> > > (and others) am not used to them.
>
> > > Any thoughts? Is there a standard or suggested way to abbreviate
> > > the word "array"? I looked in "Code Complete" and searched the
> > > internet and found very little mention.
I think this s fundamantally a bad idea. It's slipping and sliding
towards Hungarian. I's suggest the ultimate abbreviation either "s" OR
NOTHING AT ALL.
say we have a type BaseStation. Then an array of basestations might be
BaseStation base_stations [MAX_BS];
or even
BaseStation base_station [MAX_BS];
I like the singular because I can write things like
process (base_station [n]);
the down side is I have to invent another name for a single base
station.
> > I would suggest ra
yuk
> Thanks for the replies and suggestions.
>
> I had hoped there was some standard, because it's
> better to use coding conventions that others understand.
> My guess is there is no standard.
no, and too much disagreement
> I think any almost any programmer would understand
> hi / lo / cnt / ndx / max / min. I don't think it's quite as
> obvious what arr / ray / vec / ra mean.
I prefer i or j for ndx and I'm not keen on cnt (too near a rude
english word)
> Just to clarify for Rouben, I'm not using the word "array" by
> itself, or in a short name. In that case, it would be silly to
> abbreviate. I'm using the word in combination with other words
> in a much longer variable name, with multiple concepts in the
> same name.
arg! It's a Hungarian! Burn him!
> As one example of many in the software:
> "RWA_CAT_Set_HiPckNdx_Array_g".
very like the sound I make when I see something like that. Or eat
somethign bad. I assume the prefix is some sort of namespace (a bit
long I'd say).
RWA_CAT_hi_pick_indexs
RWA_CAT_hi_pick_indices
RWA_CAT_hi_pick_index
RWA_CAT_hi_pick_index_table
RWA_CAT_hi_pick_index_list
I prefer table/list to array as it seems less implementy. I hope the
trailing _g doesn't indicate GLOBAL DATA... [can we burn him /twice/?
he's gone all crispy]
> I need to trim two
> characters to meet an internal coding standard. "Array"
> is the likely victim.
_g is two characters...
> As somewhat suggested, I could just use the single letter "a" in
> the longer variable name to indicate an array, akin to Hungarian. But
> I think using just one letter would be too obscure,
unlike RWA_CAT_Set_HiPckNdx_Array_g
> especially for a
> var name that is already pretty complicated and hard to understand.
> And the program already uses many 3-character short-hands to
> categorize variable types (CAT=category, RNG=range, TBL=table,
> CHT=chart, etc), so I'd prefer to continue the convention.
>
> The RWA_CAT_Set_HiPckNdx_Array_g example is a read-write
> array (indicated by RWA). But, on reflection, it's actually an array
> of pointers, not an array of arrays (which I was implying by saying
> "Array"). Each pointer points to a read-write array (each element
> is a "high pick index" for a "categorical set"). I apologize for the
> detail.
no it helps
categorical_set_high_pick_index
drop all the junk
> The point is another possibility is to use the well-known
> abbreviation "Ptr" in place of "Array", since the concept is "pointer
> to array". This would avoid the naming issue, but lose the
> information
> that behind the pointer is an array.
I don't like ptr (or anything else that indicates a pointer). C uses a
* to indicate its a pointer and that's good enough for me. If you
don't use global data then your variables will be defined nearby.
> Another choice is to use RWA for "array". I already consistently use
> RWA to start certain variable names. A negative is you can't easily
> pronounce RWA.
except in glasgow
> same name. As one example of many in the software:
> "RWA_CAT_Set_HiPckNdx_Array_g". I need to trim two
> characters to meet an internal coding standard. "Array"
> is the likely victim.
I often use "list" or "lst"; they're both somewhat shorter than "array" (and
a bit easier to type for some reason). Perhaps "set" if not inappropriate.
Or "Ax" if you don't want to lose sight of "Array".
Or you could try getting rid of some underlines: you don't need both
underlines and mixed case.
--
bartc
This is what I have done for years, using the plural form of a noun
for arrays or other
container types.
I loath type-encoding naming conventions like Hungarian because they
force you to
rename your variables every time you refactor their types. The
compiler does a fine
job of keeping track of static type declarations, so what is the point
of forcing the poor
developer to maintain a type-encoding naming convention?
- Christopher
>> } persons[] =
>> {{ 1, "moi", 123456789}
>> ,{ ... }
> This is what I have done for years, using the plural form of a noun
> for arrays or other
> container types.
This is not too reliable. Would be npersons be a number, or an array?
--
Bartc
Thanks for additional suggestions. In response to last few posts:
Yes, I confess _g indicates global variables. I use as few as
possible,
but it ends up being a lot. There is a lot of data that applies to the
whole
program. In practice, the global variables have not caused a problem
for the program. Probably because I'm pretty careful about naming
and using access routines. And externs are automatically generated.
I also dislike Hungarian. I agree I am slipping and sliding in that
direction. But I do want to know that it's an array, without having
to guess or remember. There are cases where is helps make
variable names partly "implementy", as someone said.
I agree RWA_CAT_Set_HiPckNdx_Array_g is obscure. I know what
it means, but it probably looks like garbage to others. On the other
hand, it's trying to describe a complex concept, so it's going to take
some effort to understand no matter what.
I could make the name (and others like it) longer, but that might
mean lines over 80 columns, which I still avoid, at least for ".c"
files.
The reason for the underscores it twofold. 1) Easier to read. 2)
Parallel
with other names. There is a series of such global names, like
ROA_CAT_IMP_IntFmt_ColCnt__g
ROA_RNG_RUN_Unique_ID______g etc. etc. Making the names
parallel makes it much easier to keep track of everything and build
common access functions.
Yes, something like categorical_set_high_pick_index is MUCH easier
to read and less jarring. But it would have to be twice as long to
really
describe the complex concept, and also the parallel concept would
break down too, once I started just optimizing each name by itself.
I appreciate the "s" suggestion. I take it that means change
int *RWA_CAT_Set_HiPckNdx_Array_g [CAT_VAR_CNT]; to
int *RWA_CAT_Set_HiPckNdxes_____g [CAT_VAR_CNT];
(or something similar) to indicate each RWA (read-write array)
array slot contains (points to) series of "CAT_Set_HiPckNdxes".
(Sorry I previously omitted declaration.). I think maybe I used to
use "s" and for some reason changed to "Array" because it seemed
clearer to me what was going on (array instead of count).
One problem is the "s" might disrupt the way the
parallel organization of names. For example,
BOOL RWA_CAT_Pck_IsMarked_Array_g [CAT_VAR_CNT];
changes to RWA_CAT_Pcks_AreMarked_____g and now not
parallel with RWA_CAT_Set_HiPckNdxes_____g. Maybe it's
close enough and would work. Anyway, I appreciate the suggestion.
Daniel
p?
--
Ted DeLoggio
snip all...
<--
RWA_CAT_Set_HiPckNdx_Array_g - Original name. Need to trim by 2
RWA_CAT_Set_HiPckNdx_A_g - Too obscure? It's certainly short.
RWA_CAT_Set_HiPckNdx_Ra_g - Not personally attracted to this one
RWA_CAT_Set_HiPckNdx_Vec_g - Many people don't know what vector is.
RWA_CAT_Set_HiPckNdx_Ray_g - Not bad, but I like arr better.
RWA_CAT_Set_HiPckNdx_Arr_g - Kind of like it (ARR! ARR! ARR!)
RWA_CAT_Set_HiPckNdx_Ptr_g - Avoid naming issue. Use different
concept.
RWA_CAT_Set_HiPckNdx_RWA_g - Extend existing internal convention
-->
IMO, this naming convention is horrid...
it doesn't really look all that likely to address, well, any of the usual
reasons for using naming conventions:
clarification (what is code, what does it do, ...);
improving modularity (by avoiding clashes and reducing "accidental"
code/data sharing).
one would actually just be almost better off using plain hungarian...
there is also the variant where the type is added on as a suffix (rather
than a prefix), usually so that the start of the name can be used for
scope-related purposes (usually though, the main reason I would do this
would be to facilitate overloading in C, where the same conceptual function
may be used with different argument types, ...).
I typically don't do as much with variables, as most variables are either
locals or contained in a struct, and thus don't need as much (usually names
for locals are kept short).
in the cases I use globals, usually they are scope-named, but I don't do
much more than this (although, often, globals are marked static, since as a
general rule I don't share globals, and even then, it is usually only with
other code in the same library/subsystem, and out of necessity).
even then, globals typically hold "non-volatile" data (they are either
constant data or semi-constrant / "stable").
storing volatile values in globals is something I try to avoid if possible.
it can be very problematic, especially if multi-threaded code is involved
and it is possible that threads may step on the variable (for constant data,
threads don't matter, and for semi-constand data, it only requires that a
mutex be used to syncronize access if multiple threads may be involved, such
as to remove risk of threads seeing the data in an inconsistent state).
most other data then goes into special structs which are used as contexts
(usually these holding much of the shared state for a given subsystem, and
may in turn hold pointers to other contexts, ...).
or such...
in cases where I have done similar:
"nperson" would normally be used, but for "npersons" the 'n' would take
precedence.
in general, I may used plurals for arrays, but have ended opting against
plurals for most other collections (such as linked lists), since as a
general rule it seems out of place to be using a plural to work with a
single item at a time.
as for hungarian in general:
there is a time and a place for it;
using it everywhere makes code ugly;
but, sometimes it does have its uses, and in these cases using it can offer
a payoff.
its main use is mostly for allowing different versions of "a variable" or "a
function" to exist at the same time differing only in type, although
granted, for variables usually this is only shortly before I usually end up
changing over to using a struct instead (usually with these variables split
off into using different names within the struct).
the function case is mostly a side-effect of C, and so is generally less
needed for C++ code (which can itself handle overloading). however, for
functions, for other reasons the type is usually a suffix (sort of like in
OpenGL and friends...).
I also use different naming conventions to differentiate between internal
and external functions as well, ...
as a general rule, global code/data uses scope prefixes (which basically
tell where the code/data is in the overall project, as well as reducing
clashes). likewise goes for prefixing source-file names and (often) headers.
> --
> Bartc
I agree RWA_CAT_Set_HiPckNdx_Array_g looks horrid, but I don't see
much of an
alternative. It means an array ("RWA"), each element of which is an
array (actually
a pointer). Each element of the second array holds the "HiPckNdx" for
a "categorical
set". I won't try to explain what "HiPckNdx" or "categorical set" are.
It's domain-specific
to analyzing data. But they're certainly not Hungarian, although they
might look so to
someone not familiar with the domain. I think any program may look
horrid if you are
not familiar with the domain. The only parts that are Hungarian-like
are "RWA" and
"Array". I find them helpful to explain what the variable holds. As I
mentioned in
previous posting, there are many other symmetrically named variables
in a coding
convention. Anyway, I grant it's an imperfect system, but it works
well in practice.
I was just looking for a memorable 3-character name for "array".
Besides a lot of constant data, I do store a lot of volatile values in
globals that mostly
retain program settings the user has selected. I agree fewer globals
is better. But I
don't see any alternative. Luckily (I guess) the program is not multi-
threaded.
Could you explain a little (or give a link or book reference) about
"special structs which
are used as contexts" as an alternative to globals? I'm not sure on a
practical level what
you're referring to. Do you save state to disk? I used to do that in
some cases, back
when memory was more of a concern, but moved away from it a while
back.
Thanks,
Daniel
>> RWA_CAT_Set_HiPckNdx_Array_g - Original name. Need to trim by 2
>> RWA_CAT_Set_HiPckNdx_A_g - Too obscure? It's certainly short.
>> IMO, this naming convention is horrid...
> I agree RWA_CAT_Set_HiPckNdx_Array_g looks horrid, but I don't see
> much of an
> alternative. It means an array ("RWA"), each element of which is an
> array (actually
> a pointer).
Oh, a Table.
> I was just looking for a memorable 3-character name for "array".
tab?
--
bartc
Use your head. What do you think it would mean?
If you take the prefix 'n' to mean "number of", which is a common
enough convention, then this would obviously be a number.
Note that my suggestion is to use the plural, not merely suffix with
's', e.g. number-of-persons is not actually plural.
> I agree RWA_CAT_Set_HiPckNdx_Array_g is obscure. I know what
> it means, but it probably looks like garbage to others. On the other
> hand, it's trying to describe a complex concept, so it's going to take
> some effort to understand no matter what.
If you think that is an acceptable name, then there is no point in
even having
this discussion. You have already abandoned readability for others, so
just
do whatever works for you.
- C
What if you had an array of those?
--
bartc
<--
I agree RWA_CAT_Set_HiPckNdx_Array_g looks horrid, but I don't see
much of an
alternative. It means an array ("RWA"), each element of which is an
array (actually
a pointer). Each element of the second array holds the "HiPckNdx" for
a "categorical
set". I won't try to explain what "HiPckNdx" or "categorical set" are.
It's domain-specific
to analyzing data. But they're certainly not Hungarian, although they
might look so to
someone not familiar with the domain. I think any program may look
horrid if you are
not familiar with the domain. The only parts that are Hungarian-like
are "RWA" and
"Array". I find them helpful to explain what the variable holds. As I
mentioned in
previous posting, there are many other symmetrically named variables
in a coding
convention. Anyway, I grant it's an imperfect system, but it works
well in practice.
I was just looking for a memorable 3-character name for "array".
-->
hungarian would actually look nicer...
anyways, usually stuff like this is much more a matter of style than of
domain.
usually, a similar style may be used regardless of the particular domain.
<--
Besides a lot of constant data, I do store a lot of volatile values in
globals that mostly
retain program settings the user has selected. I agree fewer globals
is better. But I
don't see any alternative. Luckily (I guess) the program is not multi-
threaded.
-->
bleh...
<--
Could you explain a little (or give a link or book reference) about
"special structs which
are used as contexts" as an alternative to globals? I'm not sure on a
practical level what
you're referring to. Do you save state to disk? I used to do that in
some cases, back
when memory was more of a concern, but moved away from it a while
back.
-->
no, no state goes to disk.
the simple desccription is that one has nearly all of their state stored in
a struct, and they pass a pointer to this struct around to all the places
they have code which may need any of this state.
anyways, this struct typically serves a similar role to a common use of
objects in OO languages, where nearly all of the functions which accept a
given context could be regarded as methods of the context/object.
so, usually, there will be a function to create/initialize the context (IOW:
a constructor), and often another to destroy it. for everything else, it is
passed around, and generally held by the creator (although, it is often
treated opaque outside of the code responsible for working on it).
I typically disallow direct access to struct fields, essentially demanding
that access be done via special functions designated as getters/setters...
similarly, different regions of code often use different contexts (or, IOW,
they are in different "objects").
or such...
I can't imagine why one would have such a thing, but the plural would
be numbers-of-persons,
which I suppose one could abbreviate to ns-persons, although I
wouldn't. I would probably just
call it n-persons-array. See there is no hard and fast rule other than
to make the code readable
by humans.
I always use 'arr' for arrays. Seems intuitive to me.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
First explain why you would even have such an array. I often find that
data structures that are hard to name indicate the code needs to be
refactored.
If you have a Soldier object, then you could group them in Squad
objects, which are themselves grouped into Platoons, Companies,...etc.
Grouping them into Soldier_Array and Soldier_Array_Array etc would be
unhelpful.
So if you have a need for a list of pointers to arrays of strings, isn't
it better to give it a name like Catalogue to both describe and justify
the grouping of the data, rather than some horror like str_ary_ptr_lst?
Cheers,
Mike
Yes, I don't think I've ever used 'array' or any of it's abbreviations as
part of a variable name.
But I have used 'list' or 'table' or whatever, or a plural, or sometimes a
name that implies a list or collection or table. In short, I've used
everything except 'array' (although I do make use of that for type names).
--
Bartc
> mike wrote:
>> In article <0c7fc58c-cc7d-4292-880f-aefab63e7622
>> @t21g2000vbo.googlegroups.com>, cbc...@gmail.com says...
>>> On Feb 16, 10:21 pm, mike <m....@irl.cri.replacethiswithnz>
>>> wrote:
>>>> In article <5225f641-a135-4c5f-a091-11eeb2731264
>>>> @z11g2000yqz.googlegroups.com>, cbc...@gmail.com says...> On
>>>> Feb 16, 2:33 pm, "bartc" <ba...@freeuk.com> wrote:
<snip methods for indicating arrays in identifiers>
>>>> And then the number of entries in _that_ array would be
>>>> n-n-persons- array or n-ns-persons or ...
>>>
>>> First explain why you would even have such an array. I often
>>> find that data structures that are hard to name indicate the
>>> code needs to be refactored.
>>>
>> That is my point - an array is a useful data structure, but is
>> not generally a good or useful in the high-level description of
>> the data. Knowing, for example, that variable 'x' is an array of
>> arrays of arrays is (with a few exceptions) not particularly
>> useful and shouldn't be part of the name of the variable.
>
> Yes, I don't think I've ever used 'array' or any of it's
> abbreviations as part of a variable name.
IIRC, the only time I've used "array" or an abbreviation of "array"
was when writing general array manipulation functions in PHP.
> But I have used 'list' or 'table' or whatever, or a plural, or
> sometimes a name that implies a list or collection or table. In
> short, I've used everything except 'array' (although I do make use
> of that for type names).
I think you make a good point here. When it comes to discussing
identifiers in general, it can be tough, because choosing a good
identifier greatly depends on the context in which a variable is
declared. So "list" or "table" will certainly be sufficient in the
proper contexts.
I find Rob Pike's "Notes on Programming in C"* an insightful guide
concerning programming style in general.
* <http://www.lysator.liu.se/c/pikestyle.html>
--
Curtis Dyer
"Don't worry about efficiency until you've attained correctness."
-- Eric Sosman, CLC