|
|
i learned one thing... didn't know that my naming convention was Hungarian one...
i'm with you mike 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
|
|
What kind of formating is CListCtrl?
-prakash
|
|
|
|
|
Looks more like a classname than a variable name.
--
Meski
|
|
|
|
|
following an official directive a few years ago that everyone had to use hungarian notation in our UNIX code i started doing so.
given that we were using VI as our editor, were writing in C, and often ended up with long complicated functions (long story, but often the best solution) encoding basic information in the variable names turned out to really help me.
of course, most people didn't bother following the directive to use hungarian, and i found i needed to settle on a tweaked form of "standard" hungarian. all of the windows types didn't exist, so codes for them were of limited use 
when i moved to VIM i gained access to word completion, and to better features for finding out the type of a variable. still i found it easier to tell strings, ints, bools and other such basic types apart at a glance based on their names.
having got used to naming variables this way, and finding that it helps to reduce code errors i have stuck with it now that i have started windows programing in the .NET IDE. i know the IDE will tell me things about the variables, but this tends to require moving the mouse 
it is easier to have the info in the names, than it is to dig the mouse and mouse cable out from under a book, or pile of paper, and use it 
zen is the art of being at one with the two'ness
|
|
|
|
|
Sometimes - DoSomethingButton
Sometimes - isVar
But hungarian notation - very bad style for present, because datatype doesn't have matter against functionality of variable.
|
|
|
|
|
private string codeValue
public string CodeValue
{
get {codeValue}
}
public bool TestValue(string valueToTest)
{
bool isValid;
...
return isValid;
}
I use Camel to private and internal variables and Pascal to methods and properties.
The classes and samples of MSDN follows this way, isn't? 
Alexsander "Axia" Antunes
|
|
|
|
|
My convention is fairly simple: The name of the variable has to succinctly describe what it's for and the case style depicts the scope.
First of all, I write in straight C but I don't use C-style. All my names use a variation of Pascal and camel case. For global variables, the first character is a lower-case 'g', then I use PascalCase for the remainder. A function parameter gets PascalCase and a local (automatic) variable gets camelCase. Oh, and #defines are ALLCAPS (sometimes with an underscore between the words if that helps clarify the name).
'til next we type...
HAVE FUN!! -- Jesse
|
|
|
|
|
|
I like to simply keep my variable names SHORT and consistently named so
that my code in turn is SHORT and easy to READ...
throwing all those extra consonants in there just makes the
legibility plummet...
I also carefully indent and whitespace my code.
I mean come ON, when was the last time you looked through your
code and went, hmmm, ah yes, that's a plptstr_something.
No need for me to look up 8 lines and see what it's declared as!
I can see right HERE that it's declared as a pointer to some
kind of long string thing... uhhh...
Hmmm, now what is this variable USED for again?
I can't make out WHAT this stupid loop is doing...
WHO WROTE THIS CRAP, anyway???
hungarian breaks KISS...
...Steve
|
|
|
|
|
Oh, so you're the one who wrote this code: 
CVg vg;
CVG vG;
while(g != vg.g(G) && G == vG.G(g))
{
for(iG=gI; iG<Ig; ++iG)
{
vg.hnx(g.G(vG.hqX()));
vG.nx(G.qx(vg._i));
}
}
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
uhhh, that's short, but not consistently named...
whatever...
whenever I have to pick up someone else's code,
I totally reformat it into my preferred conventions.
Much easier to check for errors that way.
And well worth the time i spend doing it.
But if the code belongs to someone else,
I leave it ugly.
(Or convert it to my format to understand it and
make the changes in "ugly format")
When you get right down to it, the format you
use is the format that works best for you.
I'm picky.
You'll find my code rather terse and extremely
neat.
I don't particularly care how others write their
code... Whatever works...
It's a religious thing.
Not gonna try to force my beliefs on others...
...Steve
|
|
|
|
|
I was just giving you a hard time, Steve. Did you not see the: at the end... 
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
sorry - it's been one of thooooose monday mornings...
|
|
|
|
|
can't the while loop brackets ({ }) thrown off ?? 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
C# - camel case
straight C - this_is_my_var
C++ - hugarian m_bChecked
So yeah, I don't really know what to vote for....
Brad
|
|
|
|
|
When you weigh up the pros and cons there is no one style better than the other, so
better to use the same style as the existing codebase, otherwise you end up with a mish-mash of mixed styles in your code.
|
|
|
|
|
ed welch wrote:
there is no one style better than the other
Amen to that!!! Finally, a voice of reason.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Ours is a mix of Pascal (publics and protected), camel case (private), C-style (locals within a method), and FORTRAN (#define's).
I suppose the fact that we 'encode' access and visibility in our names does mean we use Hungarian notation (the notion that you encode metadata about the value in the name).
Software Zen: delete this;
|
|
|
|
|
I use somewhat of a mix of Hungarian notation and Camel Caps.
For example, all object and reference variables start with a prefix obj or ref. Pointers are p. Global variables have a prefix g_. For standard variables, 'n' is integer, 's' is short, 'c' is char, 'l' is long, 'f' is float and 'd' is double. For pointer-to-value types, only the pointer prefix is used, aka the type of pointed-to is not visible in the declaration.
I've fathomed a small syntax for my variables
expr:
[g_][type][name in Camel Caps]
The problem is that if I have a type double, like in g_dMaxSum, and I need to change it to float, it's always a find & replace run.
I use this for all languages I use. It might be difficult to read, and problematic in change situations, but I like it 
-Antti Keskinen
----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"
-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
|
|
|
|
|
This way, looking at code, I can't tell the type of a thing, but I can tell
what scope it has.
prefix meaning
"a" attributes
"g" static or global
"k" constant
"p" parameter
ex:
extern const COLORREF kDefaultColor;
struct TPixel {
COLORREF aBackColor;
CPoint aPosition;
void color( COLORREF pColor = kDefaultColor);
COLORREF color() const;
};
Furthermore, I use "C" or "T" to denote a C++ TYPE or a C STRUCT.
On member function accessors, I use "camelCase".
On member function not use for accessors, I use "PascalCase".
On local (stack) variable, I use "c_style_case".
I think that encoding the TYPE of something in a variable name defeats the
purpose of a language with strong type checking emphasis, such as C++.
I find it easyer to encode the scope. At least, it makes it easy to read.
|
|
|
|
|
|
My C++ code still uses Hungarian but my C# code follows the new guidelines and so is mainly camelCase for variables and PascalCase for methods.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
