Naming Conventions & Notations

[The Saint]

Hi everybody,
I am starting the often talked about topic again. Apologizes for the same. Actually I lost track of the two different naming conventions that we used to use in C++, namely the Hungarian Notation and the other called Hottinger Notations in which we use only ADTs so as to reduce the dependency on the data type.
For example, if there is a user id that is currently int. We declare an ADT for the same. This makes it feasible for us to change the same to UINT without any change in the code at multiple places.

If any of you have more info on the above please share it.

[cilu]

What is Hottinger Notations? I don't know anything about it and cannot find anything on the web about it.

[The Saint]

Me too not sure of the name. One of our senior guys had told us abt this. He described as I have in the example and called it Hottingar notation. Even I could not find anything abt the same.

[cilu]

and the other called Hottinger Notations
He described as I have in the example and called it Hottingar notation.

I see that you don't actually know its name. Neither Hottinger nor Hottingar can be found with yahoo, neither directly not indirectly while searching for naming conventions in C++. Perhaps is something developed in your company and isn't largely used.

[ovidiucucu]

I have Gooooogle searched for "Hottingar notation", also for "Hottinger notation" and nothing was found.
Anyhow, if you use MFC and Windows API, it's good to use "Hungarian" as long as it's the notation used in these libraries, and do not experiment others less known by other C/C++ programmers.

Once my boss said: "We must unify the naming convention in our company: from now use the convention of Java team!", "Well" I replied "I think it's better if the Java team will use ours."
So remained each with own notation... :D And please, don't give him (to my boss) another cool ideas... :D

[cilu]

Anyhow, if you use MFC and Windows API, it's good to use "Hungarian" as long as it's the notation used in these libraries, and do not experiment others less known by other C/C++ programmers.

I feel the same.

[ovidiucucu]

I feel the same.
What about your boss? :D :D

[The Saint]

Hi guys,
Thank you for the interest. As far as the name goes, rest assured that we did not baptise the notation.

[santoct2002]

Hi

Naming convention... Coding standards.. It is all well prepared and documented properly with so many sections.. even professional working in CMM level 5 are not following the same.. It seems you are all following it, You are lucky guys discussing about different naming conventions.

I too followed, I will give you a simple example why it is very hard to follow.
Suppose I have 150 points in coding standard, I am having 5000 lines of code,
When I am doing code review I have to check 150 * 5000 = 7,50,000 times.

Say for each check you are taking 30 seconds.. approxmately you have to spend 7 hours to complete your code review.. I dont think any project dead line will give you 7 hours to do code review that too for only 5000 lines. In real life professionals are spending most of the time to find out solution for the task assigned to them..

[cilu]

Sorry, I'm a little confused here. What exactly is your point? :confused:

[ovidiucucu]

Hi

Naming convention... Coding standards.. It is all well prepared and documented properly with so many sections.. even professional working in CMM level 5 are not following the same.. It seems you are all following it, You are lucky guys discussing about different naming conventions.

I too followed, I will give you a simple example why it is very hard to follow.
Suppose I have 150 points in coding standard, I am having 5000 lines of code,
When I am doing code review I have to check 150 * 5000 = 7,50,000 times.

Say for each check you are taking 30 seconds.. approxmately you have to spend 7 hours to complete your code review.. I dont think any project dead line will give you 7 hours to do code review that too for only 5000 lines. In real life professionals are spending most of the time to find out solution for the task assigned to them..
Because I'm working to a project having more than 100000 (effective) lines of code, it means we must hire ASAP few "code reviewers". :D
Let's be serious, an hour of code review from time to time it's enough. It's not like teachers verifying homeworks...

[santoct2002]

I believe that doing proper code review will ensure that very less exception in your piece of work.

I dont mean here that code review means simply looking variable name, indentation and comments, It really means looking logic flow, NULL ponter checking , memory allocation and deallocation, intialization of variables and list goes on..

I feel hiring a code reviewer for a 25 member team will defently add value to your code quality. Same time programmer should be very conscious about coding standards when he is doing coding.

But remebering all standards when you are typing each line of source is really a tuff job..

[marsh_pottaye]

Not intend to offense. Just a remark: if a company hires bad programmers, then for sure it must hire a lot of good code reviewers. :D

[cilu]

I dont mean here that code review means simply looking variable name, indentation and comments, It really means looking logic flow, NULL ponter checking , memory allocation and deallocation, intialization of variables and list goes on..

Agree, but if do that by checking every line of source code you'll transform yourself into a compiler. I don't think code review should transform into a formal demonstration of the code correctness, semantically and sintactically. Its aim is to find flaws in design and coding. But not to the extent of hiring code reviewers to do nothing else than check programmers code. So, basically I agree with this.

Let's be serious, an hour of code review from time to time it's enough. It's not like teachers verifying homeworks...

[santoct2002]

If you want to deliever a bug free software.. there should be some good process to achieve it. I agree that doing code review by programmer at a predefined interval will yield good quality of code.. But who knows that in your team out of 25 memebrs 20 of them following strictly and 5 is not..

There must be a process to ensure your code follows standards .. atleast there might be a peer review ..

[Andy Tacker]

<moved Thread>

[ovidiucucu]

If you want to deliever a bug free software.. there should be some good process to achieve it. I agree that doing code review by programmer at a predefined interval will yield good quality of code.. But who knows that in your team out of 25 memebrs 20 of them following strictly and 5 is not..

There must be a process to ensure your code follows standards .. atleast there might be a peer review ..
Do not confuse "code review" with "testing".

[ovidiucucu]

... and just IMHO: if somebody must be hired to move parenthesis, change variables names, verify functions complexity, remove the memory leaks, and other tasks of this kind, for sure something must be changed in that company... the programmers.

[santoct2002]

You dont understand,

finding bugs at testing stage cost you more ... there can be chance for a tester to miss a bug , which can be found by a real user which will cost you more.

Already defined best coding practices (coding standars) will avoid most of the bugs.. also testers effort.

[Hokutata]

... there can be chance for a tester to miss a bug , which can be found by a real user which will cost you more.
There is a chance for everybody to miss a bug, including the real user. :D

[ovidiucucu]

You dont understand,

finding bugs at testing stage cost you more ... there can be chance for a tester to miss a bug , which can be found by a real user which will cost you more.

Already defined best coding practices (coding standars) will avoid most of the bugs.. also testers effort.
Well, we can infinitely continue here and of course I'll be always the person who does not understand ;) :D.
By the way, what standard (i.e. ISO or ANSI) impose a coding style?
Please give a concrete answer.

[santoct2002]

Hi Ovidchu,

Well, till now no standards like ANSI and ISO, but you can come up with your own standards.

for example when you are working with pointer you can define some standard way of coding it.

1. Assign Null when declaring a pointer
MyObject* obj = NULL;
2. Check NULL condition after memory allocation and before first use of that pointer.
if (NULL != (obj = new MyObject()))
{
obj->function()
}
3. After the use delete pointer and assign NULL to it.

delete obj;
obj = NULL;

4. Check for Not Null condition within a function defintion for a formal parameter which is a pointer variable.

Like this you can come with rules specifically for each language, when you are designing your coding standards, you can take following things are important factors.
1. Indentation
2. Logic flow (avoid more then one return statement with thin a function or one function exit)
3. Function description, usuage, input outpout details
4. Intialize all variables.
and list goes...

[ovidiucucu]

Thank you very much. We know that.
Just relax and write a book with your "own standards"... ;) :D

[cilu]

Thank you very much. We know that.
Just relax and write a book with your "own standards"... ;) :D
I want to sign up in a waiting list for a signed copy of that book.

[santoct2002]

It is there in market... check it out. :wave:

[Hokutata]

It is there in market... check it out. :wave:
Is it signed by Mother Teresa, also? :p

[santoct2002]

Hi,

You can get this book in following address..

Milky Way,
Solar Systems,
Earth .

It has more demand, so buy it before get sold out. :D :thumb:

[KevinHall]

I know I'm joining the discussion late, but the problem with Hungarian notation and MFC is that if you change the type of a variable, then you must change the name everywhere. Some type changes really don't require changes everywhere. For example, changing float to double, short to int, unsigned short to size_t, etc....

[Hokutata]

I know I'm joining the discussion late, but the problem with Hungarian notation and MFC is that if you change the type of a variable, then you must change the name everywhere. Some type changes really don't require changes everywhere. For example, changing float to double, short to int, unsigned short to size_t, etc....
Well, this may really be a big, big problem... :D :D
Anyhow, if you cannot be sure at the beginning what type of variables you must declare, just "Edit\Replace" and push <Replace All> button, of better use a tool like UltraEdit and "Serach\Replace in Files".

[Hokutata]

Hi,

You can get this book in following address..

Milky Way,
Solar Systems,
Earth .

It has more demand, so buy it before get sold out. :D :thumb:
May we try on the Moon also? :D

[kensan]

I know I'm joining the discussion late, but the problem with Hungarian notation and MFC is that if you change the type of a variable, then you must change the name everywhere. Some type changes really don't require changes everywhere. For example, changing float to double, short to int, unsigned short to size_t, etc....

Just to add my 2 cents. This is from my personal experience, ymmv*:
1. Concerning the types float -> double and short -> int, I don't usually deal with floats and doubles. And in the case of short's and int's, I call them all int's so I don't have to change the variable name.
2. Usually when I DO have to change types it's in rearchitecting something so the types drastically change, like float to float*. So in that case I kinda WANT to examine every instance of the variable.

Bottom line is, in my experience (vast to some, newbie to others) hungarian is not that much of a pain in the butt. Getting comfortable with it takes a bit of time.


* your mileage may vary

[The Saint]

Hi everyone,
I know I'm joining the discussion late, but the problem with Hungarian notation and MFC is that if you change the type of a variable, then you must change the name everywhere. Some type changes really don't require changes everywhere. For example, changing float to double, short to int, unsigned short to size_t, etc....

One way we used to handle this was by using Abstract Data Types. We used to have a common header file where in we will define our own data types. For example the user id as on date could be int. So we would define

typedef int UserID;
Later if this is to be changed to long, then all we need to do is change the typedef to long. This way the effect use to be minimized.

[KevinHall]

Here's an excellent snippet from a book I've been reading on this subject:


Hungarian Notation
I'm going to be as brief as possible since this subject is like opening Pandor's box! I don't believe that decorating a variable with its type is particularly helpful, and I do think that it is a porting nightmare. Hungarian is inteded to provide readers of code with rich information regarding the variable, as in:


short sMaxHandleIndex; // s prefix denotes short
char const **ppcszEnvBlock; // ppcsz denotes pointer to pointer to const
// char representing a zero terminated string

What happens when the code containing sMaxHandleIndex is ported to another architechture on which the maximum number of handles can be a larger range than can be expressed with short? The type might be changed to long, in which case the variable name decoration is now an outright lie.


long sMaxHandleIndex;

Clearly porting undermines the who raison d'etre of Hungarian notation. The other part of it is that knowing every little bit about a variable's type is often highly irrelevant, and can be quite detrimental to readability.


typedef map<string, map<string, int> > string_2_string_2_int_map_map_t;

string_2_string_2_int_map_map_t s2s2immIncludesDependencyTree;

Don't laugh; I've seen this (with actual names changes, of course) in real code! s2s2imm is not really a help here, is it?

[KevinHall]

And generally speaking, I have to agree with the book. Applying Hungarian notation to STL variables, class typedefs, and others can be a real mess.

namespace XYZ
{
template <typename T>
class MyClass
{
public:
typedef map< string, map<string, T> > string_2_string_2_T_map_map_t;
};
} // namespace XYZ

//...

XYZ::MyClass<double>::string_2_string_2_T_map_map_t::const_iterator xyz_mc_dbl_s2s2tmm_cit_DependecyTreeIterator;


I'm sure I didn't follow Hungarian notation correctly on this -- or is there a standard in Hungarian notation to deal with namespaces, classes, templates, and class typedefs? Regardless of whether there is or not, I doubt anyone would argue that trying to come up with a Hungarian notation for XYZ::MyClass<double>::string_2_string_2_T_map_map_t::const_iterator would not be a mess! But these types of things really do come up in C++.

[ovidiucucu]

And generally speaking, I have to agree with the book. Applying Hungarian notation to STL variables, class typedefs, and others can be a real mess.
Returning to OP.
Maybe the Hottinger Notation would be better in this case. :D

[TheCPUWizard]

Lets get back to basics...On the olde mainframe, all identifiers were logged in a book which had sequential numbers.

var78781 = var12321 * var48889

Need the meaning...go look it up in the log book!

[Zeb]

Lets get back to basics...On the olde mainframe, all identifiers were logged in a book which had sequential numbers.

var78781 = var12321 * var48889


I think you meant to write
var78781 = var12321 * var48884 :thumb:

i've worked in systems like that. Absolutely fantastic. especially when the book has been lost (as was the case). thankfully, it was only a few modules like that, so i was able to map them to some actual explanatory names after only a few days of frustration!

[TheCPUWizard]

Thanks for pointing out the bug :D :D

The system I was referring to was the complete system for a large nationally known bakery [their product is in supermarkets and deli's across the country and begins with the letter "E"]. Thousands of Cobol, JCL, etc modules. At least two bookcases full of the "Dictionaries".....

[ovidiucucu]

i've worked in systems like that. Absolutely fantastic. especially when the book has been lost (as was the case). thankfully, it was only a few modules like that, so i was able to map them to some actual explanatory names after only a few days of frustration!
Don't be sad. Anyhow it seems that requires fewer personnel to maintain it than Asimov's Multivac. Well, not so sure... just we must wait until 2061 to see. :)

[darwen]

And now my two cents.

When you change an integer variable to something else I think you should change its name.

Then you can track down any possible range errors in the code.

Besides the fact that if you're writing code CORRECTLY the scope of a variable should be extremely small.

Here's some examples :


void Function()
{
int nValue = 0; // scope in the function, have to change very few things
}


Classes should always be small and well formed so changing a member variable from an int to whatever again causes very few changes.


class CMyClass
{
public:
int GetValue() { return m_nValue; }

private:
int m_nValue; // scope is inside the class


Another case is when passing a variable by reference/pointer. Here changing the name is positively benefitial. Consider this :


void MyFunction(short &rsValue)
{
}


If we change the value from short to int you will need to reflect the change inside of the function.

In summary : in a well-formed, well desgined application a variable's scope should be small meaning that if the type changes there shouldn't have to be too many places where you need to do a name change.

Darwen.

[Andy Tacker]

If I will collect all the "2 Cents" in CG forums, I guess I am gonna be a millionaire :D

I join Darwen. but Darwen, if we are working with something used at global level, there is no way out except for changing the each code line... Well, what i mean to say is that suppose the original code used int, later it was moved to double to get more accurate results... now what? all those division/mulitiplication calculations will loose thier accuracy if still storing output in "int". so, independent of the scope of your variable, their might be a lot of (let's say) calculation, which would be affected.

and I really liked the "Refractor" functionality in VS2K5.

[ovidiucucu]

Well Andy, take two more cents in your account. ;)

Why need change/replace variable types? I C++ we have templates, in VB nobody cares... :D

[darwen]

I'd argue if you're working on something at global level it should be encapsulated in a class i.e.


class CMyGlobals
{
public:
static float GetValue() { return m_fValue; }

protected:
CMyGlobals();

private:
static float m_flValue;
} ;


True you'll then have to go through and find all the instances of GetValue() and change them too : but the point I was trying to make was that if you change the size/resolution of a variable you SHOULD go through all instances of where it is used to check whether anything is going to break or not. And the best way of doing this is to change variable names.

Darwen.

[KevinHall]

But that is contradictory! If CMyGlobals or GetValue() does not have a prefix representing float, then there is no reason (from a name changing point of view) to check every instance where m_fValue gets used (via GetValue()).


Also, just out of curiosity, how does one deal with namespaces, templates, sub-classes, and class typedef's in Hungarian Notation. If it is something that people really should use, then there really out to be a standard way of doing things. Can someone tell me what the Hungarian Notation prefix for std::map<long, std::wstring>::const_iterator would be?

[darwen]

That was my point : if you wrap up global variables in a class their scope is limited to that class.

Personally I'd then change GetValue to GetValueFloat or something to track down everywhere it's accessed.

Darwen.

[KevinHall]

From a language lawyer's point of view, the variable is hidden, but in reality chaning the value to a double will require changing GetValue() to return double which will then have consequences everywhere else. So I don't see how this really solves anything. Am I missing something?

[darwen]

Fair point - I concede.

In actual fact one of the reasons I use Hungarian notation is for self-documentation purposes. At least if you change a variable name you can track down (in fact you HAVE to track down) everywhere it is used and address it.

Not true for comments.

Which is why I write self-documenting code, and standardised notation is a part of that.

Darwen.

[KevinHall]

<sorry -- accidental second post by my computer>

[darwen]

Yeah, sure.... *laugh*.

Darwen.