1

I am working on an application which uses Win32/MFC framework and C++ programming language using Visual Studio 2010.

My question is which naming convention needs to use for variables, function name, class name and etc. I heard Microsoft suggest to use “Hungarian notation” naming convention.

Can you please let me know which standard to use?

Rup
  • 33,765
  • 9
  • 83
  • 112
Umesha MS
  • 2,861
  • 8
  • 41
  • 60

2 Answers2

7

You might have a truly good reason to want your code to look familiar to other programmers who have learned MFC. If so, then you could emulate the conventions of the MFC Samples and Tutorials, and do what they do...

But MFC is a legacy library which originated very early, and times have changed. Microsoft's style guidelines now specifically say NOT to use Hungarian notation:

http://msdn.microsoft.com/en-us/library/ms229042.aspx

That aside, rather than blindly following any particular document, it is probably better to evaluate each individual convention. For instance, when MFC samples make classes and have member variables, they start the name with m_. StackOverflow has questions about this particular idea and you can read about alternatives:

Why use prefixes on member variables in C++ classes

I'm more aligned with Qt's API Style Guidelines, and most of their conventions work for me:

http://doc.qt.nokia.com/qq/qq13-apis.html

Speaking of which, Qt is a nice C++ offering that has continued to evolve and mature. Blows MFC out of the water (completely) AND is cross-platform...

http://qt.nokia.com/products/developer-tools/

If you want to be locked in the Microsoft universe go for .NET and C#. That would be a step up, and you wouldn't be stuck with the MFC abandonware.

Community
  • 1
  • 1
HostileFork says dont trust SE
  • 32,904
  • 11
  • 98
  • 167
  • 1
    The link about hungarian notation you posted, does not talk about C++/MFC. Also, you might want to leave out your personal preferences, as it doesn't really answer the question. – Jörgen Sigvardsson Dec 14 '11 at 09:28
  • 1
    @JörgenSigvardsson You won't find canonical formal practices documents for MFC programming relevant in 2011. Microsoft never used it in their own products and barely supports it now. I cited the only place you're going to find practices to follow, and that's ancient MFC samples, so it's better to draw from modern systems. If you really feel like breaking down in depth the way that MFC samples and source code use Hungarian notation (and consider that to be *"the answer"*) then by all means post it, instead of telling me to "leave out my personal preferences" in answers on StackOverflow. – HostileFork says dont trust SE Dec 14 '11 at 09:39
  • And here I thought SO was about helping people out, instead of pitying. I'm not getting in your way. – Jörgen Sigvardsson Dec 14 '11 at 21:06
  • 1
    @JörgenSigvardsson Again: if *your* idea of help differs from mine then great, answer in that vein. But if someone is speaking like they're starting a new MFC project and expressing curiosity about code quality--that's different than asking about maintaining some legacy code. If anyone is putting MFC and "best practices" in the same breath in 2011, *something* is amiss and it's important to make sure they know it's dead. Because old books, stale webpages, and historic Microsoft marketing won't necessarily tell them that. – HostileFork says dont trust SE Dec 14 '11 at 21:34
  • @JörgenSigvardsson the link about Hungarian Notation does discuss C++/MFC you just need to dig a bit deeper. Follow "Guidlines for names" and "General Naming Conventions" to http://msdn.microsoft.com/en-us/library/ms229045.aspx where it specifically says "do not use Hungarian notation." – Bowie Owens Dec 15 '11 at 00:01
  • The "do not use Hungarian" is with respect to .Net - generally speaking Microsoft doesn't use prefixes in anything written in C# (except perhaps in some interop code). If you look at some new Win7 APIs, you'll see that Microsoft still uses leading p's and dw's - eg. [AddAce()](http://msdn.microsoft.com/en-us/library/windows/desktop/aa374970(v=VS.85).aspx) – BrendanMcK Dec 15 '11 at 10:33
  • @BowieOwens: That document talks about the naming conventions for the .NET environment. MFC is still hungarian, and probably always will be. "When in Rome, do as the Romans do." - why break an already established pattern? – Jörgen Sigvardsson Dec 15 '11 at 15:29
  • @JörgenSigvardsson Yes...in Rome you *should* do as the Romans do: namely drive around on your motorcycle, get some coffee at a Starbucks, and take photographs of the ruins. Because people will look at you funny if you dress up in a toga, demand to see Ceasar, and try sacrificing people to lions... – HostileFork says dont trust SE Dec 15 '11 at 15:35
  • An answer on Hungarian notation, that doesn't mention, that there are **two** types of [Hungarian notation](https://en.wikipedia.org/wiki/Hungarian_notation), is inevitably wrong or misleading to half of the readers. This answer talks about Systems Hungarian, which is hardly relevant in application code. On the other hand, Apps Hungarian is *very* valuable. It's a concise language to disambiguate semantics. After all, you do want to know, whether an `int` encodes a coordinate in client or screen space. That's what Apps Hungarian provides, in a concise way. – IInspectable Jul 25 '19 at 18:36
  • Besides, Qt is crap on Windows. It's broken at its core, and cannot **ever** implement a reliable user interface. Often not an issue, if you're a mouse juggler, but if you value a usable keyboard interface, Qt cannot deliver. It will break, at some point. Inevitably. Always. And it cannot be fixed. MFC may not be as easy to use, but it certainly produces quality UIs, unlike Qt. – IInspectable Jul 25 '19 at 18:40
2

Oh boy. That's almost like asking people what religion you should follow. At least you didn't ask what text editor you should use...

My 2c: do what works for you. Also consider whether you are just coding for yourself, or whether you expect other people to read or work on the code you write, and whether you are starting a project from scratch, or building on existing code.

Naming convention really doesn't matter much, so long as:

  • You pick names that are meaningful and describe the purpose of the variable/function/other. (Key issue here is purpose; let the compiler deal with the type.)

  • Be consistent in how you apply any other aspects of the convention (indentation, casing, prefixes, use of underscores, etc).

Generally speaking, if code is well-written, the details of the convention don't matter much.

As for Hungarian and prefixes: Win32 and C++ still uses them somewhat, while .Net and C# don't.

I'd highly recommend reading this long but very insightful article by Joel Spolsky that goes to great length to outline how and why a prefix convention can be actually very useful, if done correctly, and also where it's just a pointless chore.

These days, I don't bother with most Hungarian prefixes, except for a few (note that these are just my personal preferences, they're ones that I've found to be useful over the years):

  • p for pointers, because in C++, unlike C#, it's useful to know when you're dealing with a reference vs an object, and how many levels of indirection you're dealing with.
  • m_ for member variables (Sometimes _ in C# depending on existing code; see HostileFork's note below re _ as a prefix in C++.)
  • cch for character counts, cb for byte counts. Its really important in Win32 to not get these mixed up; pass a character count to memcpy or a byte count to GetWindowText, and you'll have trouble. This is the sort of use of prefixes that can help keep your code clear and obviously correct (or incorrect, as the case may be - "ah, of course, I'm passing a cch to memcpy, that's the problem!").

For me, the first two of these help make the code more readable; the third example here helps both with readability, but can also be a useful technique for ensuring correctness - a bit like a mnemonic, if you will.

J Bryan Price
  • 1,364
  • 12
  • 17
BrendanMcK
  • 14,252
  • 45
  • 54
  • 1
    +1 don't fight with collaborators over established standards *(when in Rome...)* I'll bring up names starting with `_` then a lowercase letter are reserved by C++ for the private implementation of the compiler. If underscores are to be used they should be at the end of the member name. Proper C++ (ex: passing a CString by reference to `GetWindowText` instead of a memory buffer and length) usually mitigates concern about CCH/CB...so cases where you have to worry should be reviewed for proper abstraction use. Starting with `p` makes it look like your IDE can't hint you, so it's a bit dated. – HostileFork says dont trust SE Dec 15 '11 at 14:36
  • Good point on the `_`. For me, the p-prefix is partly 'cultural'; it's ubiquitous in pretty much all Win32/COM code/samples/articles - so much so that without it, the code may well look like C++, but doesn't look "Win32/COM" and feels off. Yes, it's dated; but so is Win32/COM - so it's appropriately dated usage :) – BrendanMcK Dec 15 '11 at 15:35