13

I name my variables using the .Net conventions:

  • camelCase for variables and fields (I tend to use _camelCase for private fields in a class)
  • PascalCase for methods, properties and classes

The only place I deviate is on constants and Enums where I actually prefer the Java SCREAMING_CAPS style.

My company's codebase is littered with the pseudo-Hungarian notation style from VB6 and VBScript, if not full-blown Hungarian i.e.

  • s or str for Strings
  • i or int for Ints
  • d for decimal (or sometimes double)
  • o or obj for any kind of object

I cringe whenever I see that code style used in someone else's code (even in greenfield code, not just the legacy cruft), and I refuse to use that style myself. I've brought up standardizing on the .Net naming conventions in the past and it's just ignored - the people who write in Hungarian notation continue to do so, those of us who don't like me continue to use our own style; I'm a little afraid that if we do standardize (which I keep pushing for, but nobody else seems to care), it'll be on Hungarian notation and not the recommended way and then I'll be forced to write code like that.

Am I making a mountain out of a molehill in regards to this? Should I not care if the code is littered with redundant identifiers and not descriptive names, and continue to use my own way and push for that to become the standard?

Improve this question
1
  • 2
    Good question. Naming conventions are there to help, not to hinder. When they hinder (because their original purpose is no longer relevant) then ditch them.
    – Gary
    May 19, 2011 at 13:41

7 Answers 7

Reset to default
7

The only thing you should care about is that you're working in a team where people don't care about cleaning up things a bit. That is very sad.

Do what you do, continue to use the modern style and invite people (but not force them) to adopt it as well. It will take time of course. After some time you will see whether it's going anywhere and what you might be doing next.

P.S. How about arranging a meeting on this issue and invite everyone involved. Then you will get their full attention, denote the problem and present your approach. It will give them something to think about. Perhaps from your local attempts they're not taking you very seriously.

Improve this answer
2
  • +1 These days Refactor Rename is so efficient that you'll hardly notice the impact of making the change.
    – Gary
    May 19, 2011 at 13:40
  • 2
    Sadly people on my team don't even use that. They're afraid to rename things even when the name is misleading. For instance there's a method called SendNewCustomerEmail that is used for sending all kinds of emails, not just new customer emails. It has a comment from a current developer that says "Note this name is misleading" but nobody has ever even considered actually renaming it to something more generic and useful, and if I do it I'll be asked by the manager to explain why I'm changing code that doesn't need to be changed instead of adding value.
    – Wayne Molina
    May 19, 2011 at 15:03
3

I think you might need to ask yourself whether or not the hungarian notation is affecting your personal output/quality, or if it is more just hurting your ego. By ego, I mean that things generally work fine, but you would never want someone you respect from outside to see the shamefully outdated code. While I think that concern does have its own merit, you have to weigh it against the quality/productivity hit that would be taken by everyone who had to switch.

This is sort of a technical debt question, since you are clearly correct that this style Hungarian makes no sense in .Net (with the exception of interfaces with "I", but thats for another time), however, this might be the sort of technical debt your team can live with until it naturally fades out.

Improve this answer
6
  • 4
    I don't even care for the "I" prefix, and only use it because it avoids having the Java conundrum of, say, an interfaced named CustomerRepository and the class being CustomerRepositoryImpl or similar.
    – Wayne Molina
    May 19, 2011 at 13:28
  • 3
    +1 - It does seems there should be some better way. I do use "Hungarian Light" from time to time, but the prefixes are always business related, not type related. For example, everything in Accounting has an AP and an AR side, and they often have the same name, such as Invoice. Having an ARInvoice and an APInvoice seems perfectly reasonable to me. Hungarian is not ALL bad ALL the time.
    – Morgan Herlocker
    May 19, 2011 at 13:32
  • @Wayne M You may want to look at programmers.stackexchange.com/questions/75956/…
    – Gary
    May 19, 2011 at 13:39
  • I wouldn't really consider that "Hungarian notation" because as you said it's a business meaning with a well-defined abbreviation that people know, along the same lines of having code that uses XML prefixed with Xml instead of ExtensibleMarkupLanguage. In an accounting module I would expect to see invoice objects like arInvoice and apInvoice that convey business context, but seeing objArInvoice or oApInvoice is just silly IMO. I guess it could be worse, it could be clsApInvoice for the actual class name
    – Wayne Molina
    May 19, 2011 at 15:05
  • 1
    @ironcode : That's actually what's called Apps Hungarian Notation, versus the Systems Hungarian Notation, and is a lot better. Most people are using the Systems unfortunately. en.wikipedia.org/wiki/…
    – Miki Watts
    Jul 13, 2011 at 9:19
2

The best argument against hungarian notation, beside modern IDEs, which have plenty of methods to show the type, visibility and more stuff of a variable whith the color, with tiny symbols and with tooltiptexts while hoovering, is, to take it seriously.

  • Encourage more distintcion (b)ool (f)loat (c)har (l)ong (s)hort (conflicts with String? no: (S)tring), (v)oid.
  • Encourage encoding the visibility. I'm from Javaland, and hope it fits for .net as well: (pri)vate, (pub)blic, (pro)tected (def)ault should be useed.
  • .net has final/const? Make it a prefix! Do I hear 'volatile'?
  • Why do int and long need a prefix, but different objects don't? That's not logical. Create an abbrev.tab. where every new Object gets a distinct abbrev.
  • Variables which might be null and such, which never should be null, can be prefixed too. Clever people put the whole DbC into the prefix of a variable.

Seriously: On refactoring, you might change a variable from int to long, from String to char. You shouldn't need to change the name, too.

In IDEs, you get the names often sorted in a Box at the side. sorted by name, where it is easy to find. If most of the variables start with o or i, it is disturbing for the eyes, to get to the significant part of the name.

The additional characters disturb the semantic of the variable. An integer 'sane' gets 'i_sane', which looks more like 'insane'.

The hungarian notation was helpful in languages, which lack a type system. You don't need it, if the compiler enforces specific types. If you decorate your lamento about hungarian notation with an empathical 'yes, for the elder programmers, it made sense in the past to use it!', those elder programmers might be vain, and prefer not to be identified as old.

But you have to be careful, for the technique to work. Maybe you can lower your voice when speaking of 'elder programmers', to let them feel, how careful you are about them, how much they need the care. So that a third person in the room will recognize, that you're trying to hide something, which will of course raise his curiosity.

Improve this answer
1
  • Sadly I've also seen eSomeEnum used as well in places; thankfully not often.
    – Wayne Molina
    May 19, 2011 at 13:34
2

Buy a copy of Framework Design Guidlines and drop it on your manager's (or whoever controls coding style) desk. Be sure to put a post it note conspicuously pointing to the introduction where they highlight the importance of consistency. To further drive home the point get a copy of Clean Code and put a bookmark in there on the section regarding coding conventions.

Improve this answer
1

In some respects this is a subjective issue, and it's one of those programming minutae (spelling?) debates that I entertain for a while then avoid. Whilst I think hungarian notation is a sin that should be banished, I think consistency is more important.

In that vein I'll do my best to convince a team to use domain centric variable naming rather than type based naming conventions, but if it all gets to hard I'll back off to accept a standard of naming that everyone must comply to on a common code base.

I'm not in favour of some generically mandated standard imposed by a standards group, but that software teams develop their own standard, and more importantly, stick to it.

Improve this answer
1

With resharper renaming variables is so fast that I can undo ill considered naming conventions so fast, that I don't have to leave the old, wrong headed conventions stand.

If you don't have refactoring tools, then, I agree with the other commenters who have suggested following the codebase's existing convention as much as you can, even if it was wrongheaded. (up to a point, there are variable naming conventions that will turn into bug generators if you let them)

Improve this answer
0

Most of your concerns are valid and would make life easier for a new developer and probably your sanity. The one convention you should all adopt is descriptive names. You should be able to come to some consensus on that without drastically changing styles depending on how bad they are. For everything else, either wait until you are in charge or you replace current members with fresh developers that think and feel the way you do.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.