Click here to Skip to main content

Article

Programming conventions

bryce

Rate me:

4.00/5 (4 votes)

25 Mar 20021 min read

157.6K

15

46

Some programming convention tables for reference

Introduction

This is less of an article, more of a reference sheet to be printed out and stuck to the wall.

Hungarian Notation

"Hungarian notation" was developed by Hungarian Charles Simonyi of Microsoft ™, hence the name. Most programmers seem to stick to a flavour they like or develop a different flavour. This is a starting point for those who wish to use it. Add extra ones in the blank rows as you see fit.

Data Type	Prefix	Example
Boolean	b	bContinue
Int	n	nIndex
Short	n	nIndex
Character	c	cFirstInitial
Float	f	Percent
Double	d	dMetres
Long	l	lCarCount
String	s	sCustomerName
Null terminated String	sz	szCustomerName
Unsigned Integer (Word)	w	wCount
Unsigned long integer (DWORD)	dw	dwAtomCount
Pointer	p	pNext
Handle	h	hWnd
Function	fn	fnReport
Class	C	CParser
Class member variable	m_	m_
Array	a	aYears
Global	g_	g_szDirectory
Windows message	Msg	msgCut

You can add some of the prefixes together where they make sense.

For example a member variable which is a null terminated string , "m_szName".
Another might be for a global integer eg. "g_nElementCount".

Windows Resources

Resource Type	Prefix	Example
Menu Item Resource	`ID_`	`ID_EDIT_CUT`
String	`IDS_`	`IDS_STRING1`
Dialog Control	`IDC_`	`IDC_EDITBOX`
ICON	`IDI_`	`IDI_MAINICON`
Cursor	`IDC_CURSOR_`	`IDC_CURSOR_ARROW`
Dialog Box	`IDD_`	`IDD_ABOUTBOX`
Accelerator	`IDR_`	`IDR_ACCELERATOR`
Bitmap	`IDB_`	`IDC_ARROW`

Free free to email me your updates/suggestions and I will update the article as necessary.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Written By

bryce

Software Developer (Senior) TMR

Australia

This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

I understand you and I feel the same.
But wait...
To me this DOES makes sense that Microsoft has changed their conventions to some sort of mixture of pascal and camel casing, but I would only understand this for .NET framework and managed coding.
In this case (like C#) all built in types are inherited from the same base class 'object'. I would say that it is no longer so extremely important to have a sort of visual confirmation about the actual type in this case (since all types are basically the same).

In native C and C++ though, I believe it is still extremely important about knowing the actual typing everywhere (not to forget scope, 'm_', 's_' and 'g_' makes a hell of a difference to avoid name clashes with locals), and hungarian notation is a sort of tool / help to make the code much clearer to read (just like someone here wrote earlier).

So, what has been discussed is two other things here about hungarian notation:
1. What if I change the actual type and not change the notation?
Well, I say, then you are a sloppy coder and should do something else than programming. It is always one of the responsibilities of a programmer to maintain his code and keep it tidy. I don't think I can personally remember at any point that I have forgotten that. And besides, how often do you REALLY change the type of a variable?
2. Difference on the size of integers ('n' for both short's and int's).
Well, I admit this is a bad, but where I worked we had for long ago resolved this issue by simply having different notations for all possible types. Yes, this is possible. Just sit down a few hours in the beginning of a project, discuss the coding guidelines, style, rules and file / folder naming / structure and you will find solutions to things like this.

I have rather recently moved to a different company and in the current (C/C++) embedded project I'm working in, we settled for camel casing everywhere with the addition of '_p' at the end (!) of names for pointers.
Well, I don't like it at all, but if you are a team member you simply have to agree to the conventions that most of the team members prefer. Guess that's how democrazy works it will never be perfect for everyone, but for most.

All in all, my experience tell me that if you have become used to using HN, you will find that you make you own code much clearer in its intentions and typing, you will also find that it is much easier to read others code that write using HN.

Thanks for the article, even though I think it should be a little bit more complete (what about static members, STL types, COM/ATL types and windows controls etc.) and also take care of the HN issues that I mentioned in point 2 because this is not so good.

General News Suggestion Question Bug Answer Joke Praise Rant Admin

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Go to top