Sign in to follow this  
  • entries
    149
  • comments
    510
  • views
    94468

Changes

Sign in to follow this  
noaktree

113 views

Not much interesting. I have been updating my code to conform to safer C++ practices. Also I have been standardizing naming notations as I go along. I'm almost through the math library. Boring stuff...
Sign in to follow this  


6 Comments


Recommended Comments

With this project I am using Hungarian notation though I have modified a few of the prefixes and also added some. What do you typically use?

Share this comment


Link to comment
Ugh, hungarian notation! I hate it [smile], though there are few people who love it, I think.

I used to use it sometime in the past, until I realized it wasn't really adding much to me. In fact, it added nothing. The point behind hungarian notation is encoding a variable's type into its name:
1. This, in theory, would be helpful in loosely-typed languages, not strongly-typed ones like C++. That said, even in loosely-typed languages it isn't practically helpful.

2. If the type of the variable changes, you have to change its name accordingly, and all its references. A very bad idea, unless your IDE comes with refactoring (e.g. VS 2005), in which case it's a bad idea, because it:
(a) Takes a little bit of time (to replace the references)
(b) Requires rebuild (bad in medium and large projects)
(c) Possibly other things I don't know, but they're ugly [grin]

3. The type of the variable should be available from its name AND the context. e.g. When I'm storing geometry IDs, I don't say:
DWORD dwGeometryID;

Instead:
typedef DWORD geometry_id_t;
geometry_id_t geometry_id; // or only id, depending on context


The latter is:
a. More clear
b. If I later decide that geometry_id_t should be a short instead or whatever, I just change the typedef (though I'd still rebuild). Typedefs are really powerful if used correctly, by the way. And they can help you in cross-platform development situations (e.g. The PalmOS has the socket type NetSocketRef, while windows has it named SOCKET,...etc).

There's no reason to name the id dwID or something, because its type is obvious. Generally, when working with a variable, I know its type - A variable never stays alive for a long time without use for me to forget its type. Refactoring and self-documenting code make your functions really specific in what they do, and rather short (see [1]) - meaning you really don't have enough time to "forget" a variable's type in the middle.

4. I prefer my code to look (as much as possible) like pseudo code - as high-level as possible. Types aren't encoded/defined in pseudo-code.

You can really find out a lot of the pros and cons of hungarian notation through google. A quick search gave me [2] as a first result.

Now that I ranted enough about what I don't use, I'll start talking about what I do use [smile]. I generally use the convention of the language I'm working with. If I'm using C/C++/php, I use the underscores_to_the_rescue syntax. I just LOVE IT. I use an additional '_t' to indicate types (Otherwise you wouldn't be able to make an instance of the type foo_bar and name it foo_bar). I love this, because:
1. It looks more like pseudo-code (i.e. an underscore's like a space)
2. It's easier to read when using long function/variable names, which I often do (see [1])

The most common complaints about them are:
1. Harder to type: Not really (to me, at least). But I've been thinking about a little app that'd allow you to select a window, and then convert all Shift+Space or whatever messages directed at the window to underscores (for those who can't type it fast enough). It'd be a nice experiment, I think [smile]

2. Doesn't look good when hyperlinked in documentation (because hyperlinks are usually underlined, and then the underscores don't stand out): I disagree with this, and even if it was true, the benefits would outweigh this (to me).

Bjarne, on his website, uses a slightly different convention. Some_type for types (first letter uppercase). I've not tried it before, but I think it'd work ok.

When I use C#/VBScript, I stick to CamelCase naming for functions, and firstCamelCase naming for variables, because:
1. If you do otherwise, FxCop is going to complain like you've killed his mother
2. That's how the preferred convention for that language

I do prefer the Java naming convention to this one, though, where methods are firstCamelCase too, because object.doSomething() looks more natural than object.DoSomething() to my eyes. But I don't use it.

This stuff is rather subjective by the way, so don't take my word on it. Decide on what works best with you, and keep in mind that you'll work with conventions you don't like anyway when you work with other teams (Unless you happen to be the lead and specify your team's convention to be yours [smile]).

[1] There's a great article series called "The Craftsman" in here that talk about modern practices and test-driven development. Search for "Craftsman" in that page, and start with #1. I believe there are ~26 ones.

[2] Hungarian notation: The Good, The Bad, and The Ugly

Share this comment


Link to comment
Thanks Coder! I'm dumping my hungarian and switching to the type method. I guess yesterday's work goes in the trash. [smile]

I am going to keep an underscore before my private members (_Name) as this seperates them from the public ones when accessing members from an object. Know of a better way? So should I still use the m_Name prefix for members?

Edit: Thanks for the link to "The Craftsman"! I'll read them all.

Share this comment


Link to comment
Quote:
I'm dumping my hungarian and switching to the type method. I guess yesterday's work goes in the trash.[smile]

Be careful not to switch to a notation you don't like - this stuff, as you must've known by now [grin], takes time.

Quote:
I am going to keep an underscore before my private members (_Name) as this seperates them from the public ones when accessing members from an object. Know of a better way? So should I still use the m_Name prefix for members?

IIRC, identifiers with a leading underscore are reserved for implementation extensions (not exactly sure about what it's reserved for, but it's reserved for something).

That doesn't mean your code will break, it just means an implementation could use that underscore-prefixed name as a keyword (e.g. _asm, _finally) in which case you'd have to change it. Some people use a trailing underscore, but most people I know use the 'm_' prefix. Some people use no prefixes at all. As always, use what suits you best.

Share this comment


Link to comment
Quote:
Be careful not to switch to a notation you don't like - this stuff, as you must've known by now, takes time.
Oh I know [smile] I have been at it for the last 10 hours. I'm liking the name_that_looks_like_human_language style much better and my code is already looking much better. Besides that I am adding greater meaning to many of my variable names. The idea that my code could look more like pseudo code really appeals to me. I appreciate your suggestions and wisdom.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now