Ominous to some, frustrating debate to others, non-plus to most: Hungarian notation. Unity uses it in some (not all) of their example scripts, and all of their own source code. MSDN doesn’t suggest Hungarian notation as a preferred method. Instead saying public consts and properties should be pascal case and private fields can be whatever you want them to be. I mean in a way that’s answer isn’t it: ‘private fields are just what you want them to be’. Prefixes are ignored by the inspector and so it’s purely a personal preference. While, of course, keeping consistency across teams/projects. Sure. I get that. BUT. What do you do, and why? I flip between both trying to find what suits me most, and would appreciate something to lean me to either side of this non-plus fence.
If you really want to be controversial you could ask people if they like to keep the open curly brace on the same line as their if/for statements
I used to use m_MemberName but depending on which codebase I’m working on I’ll usually just adopt their standards. Lots of people use ‘memberName’ or ‘_memberName’ etc…
I usually work alone, so it’s no fuss. I know it’s good to share a ‘standard’ if working with someone else, as it’s more comfortable, and that’s cool with me.
I don’t find myself often using hungarian notation, but I can see its merit, nonetheless (for those who do use it).
On personal projects I’ll stick with ‘m_MemberName’ even though it’s old fashioned - I like it because it’s very obvious that it’s a member variable and not a local one. Recent projects I’ve worked on all seem to use 'memberName’ though for members and ‘localName’ for locals. I think some of them caused problems in the Unity Inspector (m does from what I remember).
Yeah I have to admit I’m totally torn. On one side I don’t like the clutter of the ‘m_’ prefix. Intellisense can tell me that it’s a member variable, and it’s strange to only use Hungarian notation for member variables (as well as perhaps statics, consts). On the other hand I like the idea that ‘wrong code should look wrong’. So when you’re accessing another class, and you’re accessing a m_ prefixed name, you know it’s missing a property, and you may not know whether that subsystem is supposed to have that level of access for that field. That visual cue is nice… But then, messy Hungarian lol.
Honestly I did not used to do the hungarian notation but started doing it recently. IMO it seems to help differentiate between private, local and public or protected.
Previously I just used _privateVariable and regular camelCase for locals which wasn’t bad, but for some reason I just started noticing that the m_ looks nicer than the naked _ prefix. Maybe it’s just bias because I’ve been using the basic _ prefix for so long on private members.
Either way it’s completely up to your preference and has zero bearing on anything. Maybe in the future I’ll get tired of it and think the _ is better because it’s cleaner, who knows. ReSharper corrects all my naming based on my preferences so it’s super easy to stay consistent.
Most of the time I find it in C and C++ code.
Personally, I don’t find it aesthetic, especially when there are lots of different single character prefixes.
In C#, I prefer:
Writable fields: _someField (private, sometimes protected, almost never internal, never public)
Readonly fields: SomeField (any access modifier, looks like a property)
Constants: SOME_FIELD (any access modifier, looks a bit ugly for many people, but for some reason I got used to it).
The book “ShowStopper” describes some of the fights at early microsoft about this. One of the half-crazy big shots who was personal friends with “billg” was a big advocate of Hungarian, but they had hired guns that made VAX/VMS and those guys had some real macho swagger and their own style. They all agreed IBM was a bunch of **ssies for writing design documents – real men write code and don’t add bugs.
It’s a pretty good book in general, and gives a feel for the kind of status-conscious environment where that argument happens.
It sounds like either way we’re all doing something relatively similar. It’s just little tweaks here and there to aesthetics. Okay good. I wasn’t sure whether to use camel case for private fields, as technically it is cleaner. It just makes me so wary as I like clean SOLID principles, and making sure correct access between different classes helps so much. With Unity having their properties as camel case too it could be easy to mix up what’s a property in your class and what’s a field that shouldn’t be public (assuming you’re working with devs who make everything public for giggles).
I think I read that too, or at least some blogs talking about it. Though it missed out the swagger and **ssies lol.
I really need to talk to my boss about getting resharper.
Whoops. Forgot about that part: the book was advertised as a typical puff piece about how a Great Company uses Great Processes to make Great Products. Sounds pretty boring. But once you get into it, it’s the opposite - cool details of a messed-up team at a typical messed-up 80’s software company.
So the easy but wrong message is the Windows NT team spent lots of time working out the 1 universal coding standard. That’s one of the secrets to their great success. But after reading ShowStopper, the real message is they argued about Hungarian notation because they wasted time arguing about all sorts of stupid things.
My member fields are always private, so I have no concern about getting confused from another class.
I use properties for everything, even inside the class that owns the field, so there’s no concern about missing functionality added to a property later.
That means, typically, I only have three types of members to worry about:
properties are always PascalCase
locals are always camelCase
methods are PascalCase with Brackets()
The one exception is property methods. Since you can’t have any locals in property methods, camelCase is available again, so I use that for my field names.
Didn’t had the chance to read through all the comments, but for the part about local and member variables you can use syntax highlighting to tell them apart.
Systems hungarian notation was useful at the time when we didn’t have Intellisense (or one that worked as awesome as it does now). At the time my IDE of choice was Turbo C++. It even had syntax in color!
Today? It’s made largely redundant thanks to Intellisense. I could just as easily hover over a variable and gain way more info on it than I ever could with hungarian notation – at least not without bending over backwards trying to cram as much info as possible into the notation such as m_lpczFooBlah.
tl;dr: Systems hungarian is evil. Don’t use it. Be kind to your fellow coders.
As for the other part of hungarian where “wrong code should look wrong”… meh. Visual Studio still does a pretty good job of analyzing your code and pointing out code smells using curly underlines. Just make your locals look different from your class scoped variables (I use underscores for that), and functions and variables should (obviously) look different from each other (I use upper case vs lower case for that).
To further expand on “wrong code should look wrong”, I don’t think you need to come up with a special notation for that. Just use plain english.
For example:
House house = new House();
var person = house;
Does that code look wrong? It should – you’re trying to assign a person as a house. The code will compile. It may even run. It’s just that “person” will actually be a House object.
Now if you’re the type of programmer who use abbreviations for everything:
House h = new House();
var p = h;
Does that code look wrong? I certainly can’t tell from just this bit of code. I’d have to look at how p is used. It’s also not english, so that doesn’t help me here.
That can lead to funny bugs. Suppose the postage and handling property sets a minimum of $3. handling=price*0.15f; if(firstClass) handling+=1;. applies the minimum too soon.
That’s part of the debate whether languages should have Properties. The argument against is, inside the class it’s too easy to think of them like variables, forget they’re functions, and not think about side effects.
That sounds like a violation of the SRP.
Plus, there’s a simple work around which also adds thread safety.
var handling = price * 0.15;
if (firstClass)
handling++;
Handling = handling;
On the other hand, what if I added code like this
public Decimal Handling
{
set
{
if(handling != value)
{
handling = value;
OnPropertyChanged(nameof(Handling))
}
}
}
It would be a mistake not to use the property unless I also litter my code with OnPropertyChanged … which gets out of hand pretty quick.
Anyways, I can see both sides of that coin. This would make a god topic for code standards within a team and is probably more important than whether you start your field names with an _ or not.
