Abbreviation for word "array"?
in [General Programming]
|
Prev: Binary heap "tie breaking" question
Next: CFP: SAS'2010 - 17th International Static Analysis Symposium, Perpignan, France
From: BGB / cr88192 on 14 Feb 2010 12:46 "bartc" <bartc(a)freeuk.com> wrote in message news:FTWcn.38920$Ym4.15387(a)text.news.virginmedia.com... > cbcurl wrote: >> On Feb 10, 7:19 pm, Moi <r...(a)invalid.address.org> wrote: > >>> } 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? > 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
From: Daniel on 14 Feb 2010 21:03 On Feb 14, 8:57 am, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: > "Daniel" <google-...(a)ehdp.com> wrote in message > > news:1745db59-1138-4c53-a640-977ff62bdca8(a)t34g2000prm.googlegroups.com... > > 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... 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
From: bartc on 15 Feb 2010 05:20 Daniel wrote: > On Feb 14, 8:57 am, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: >> "Daniel" <google-...(a)ehdp.com> wrote in message >> >> news:1745db59-1138-4c53-a640-977ff62bdca8(a)t34g2000prm.googlegroups.com... >> 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
From: cbcurl on 16 Feb 2010 13:01 On Feb 11, 12:12 pm, "bartc" <ba...(a)freeuk.com> wrote: > cbcurl wrote: > > On Feb 10, 7:19 pm, Moi <r...(a)invalid.address.org> wrote: > >> } 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? 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.
From: cbcurl on 16 Feb 2010 13:04
On Feb 11, 12:52 pm, Daniel <google-...(a)ehdp.com> wrote: > 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 |