|
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 [^]
|
|
|
|
|
Same here. But with C# I still have a small piece of Hungarian in that I use m_ for object level variables.
Regards,
Brian Dela
Now Bloging![^]
|
|
|
|
|
Brian Delahunty wrote:
I use m_ for object level variables
I still use the "m_ " prefix for variables in a dialog box that are subject to dialog data exchange. Old habits die hard, I suppose.
Software Zen: delete this;
|
|
|
|
|
i assume this refer to Hungarian notation with prefixes.
|
|
|
|
|
In fact, this time, CListCtrl is not that off-topic and therefore should be avoided for this survey.
--
Affordable Windows-based CMS: www.zeta-producer.com
|
|
|
|
|
I do use prefixes sometimes but only in a few cases:
1) A leading 'm' to show module level vars
2) A prefix to show referances to controls (ie: frm, cmd, cmb, etc...)
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
like i Created prefix l_ for local member of function
"I Think this Will Help"
<h5
alok gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
I also put s_ in front of variables declared 'static' at file scope.
I put S_ in front of functions declared static at file scope.
|
|
|
|