"public void DoSomething ()" vs "public void Do_Something ()"

Usually I start function like this:

public void DoSomethingSpecial ()
{
//Does something special
}


But sometimes I've got this habit where I use underscores:

public void Do_Something_Special ()
{
//Does something special
}

Will starting a function with underscores be deprecated in the future if I keep this up?

 

There won't be any compilation problems, and those are completely legal names for functions or other identifiers.

In terms of coding standard practices, though, it may not be a good habit (assuming you're hoping to work with any other programmers in the future, as you would if you're going into it as a career). Personally, reading names with underscores between every word feels like someone is talking. like. this. and. stopping. between. every. word. And I know I'm not alone in that. So, if you code like this, you run the risk that your future coworkers may be really annoyed with you.

 

I agree with StarMantra (including. the. slow. speak.)

I'd like to point out that, to nitpick, you are not starting a function name with an underscore, but simply use an underscore to optically widen the gap between parts of the function fame. Function (or attribute) names that started with an underscore historically had some significance in some C compilers and for that reason were frowned upon unless used for a very specific purpose. So I recommend you don't do that either

 

If you only ever work with yourself, do whatever you want! It's your code and nobody else is going to care.

But if you plan to make it a profession with other people, you will most likely find that underscore usage isn't a high thing. Personally, it's annoying to look at. I would suggest if you want to go this route, you consider what is generally standards. While you may find some things are still up in the air (variables starting with underscore...), there are some things that do tend to stick no matter how you learned to program.

 

I'll take this moment to expand slightly on when it IS generally accepted to use underscores, in my experience.
1) private backing variables:

Code (csharp):

1. private int _health;
2. public int health {
3.    get {
4.       return _health;
5.    }
6.    set {
7.       _health = value;
8.       if (_health < 0) Die();
9.    }
10. }

The leading underscore is a good way to hint that no other code should be using _health, but rather, _health is meant only to be used indirectly, through the "health" property.

2) indirectly used functions (often with threads or recursion). You have a FindInChildren() method, which does a little pre-setup, then calls a FindInChildren_Recursive which calls itself as needed. But FindInChildren_Recursive is private, and so named to hint that it should not be used except in the context of the FindInChildren() method. Same sort of thing for threads, where the code intended to be run in a thread is in SomeFunction_Threaded(), again hinting that it isn't meant to be used except in that specific context.

If this post comes off as little more than "underscores are only useful as programmer repellent", then that's a pretty accurate representation of how I think a lot of coders feel about them. You use underscores when you want to keep other programmers away from something.

 

Variables allow underscores for that exact reason -- so you can use them as fake spaces in names. In fact, the

do_something_special

style came first. Underscores have been around forever and aren't going anywhere. "Pascal-casing" became popular only with Java, from which C# borrowed heavily. Back then, people laughed at Java's weird "far too many words smashed together" style. C and C++ still use the underscore style.

You mentioned a leading underscore. As csoFranz wrote, that's really things like

_doSomething()

. Commonly that indicates helper-type special-case functions. Say you use code completion and see

getTownName()

and

_getRawTownName()

. The 2nd is probably something used by getTownName(). The underscore does a nice job hiding it way up on top.

I like to save underscores for when upper-case looks wrong.

handleTap_ProductMode()

seems better than

handleTapDuringProductMode()

.

 

That probably comes from long-ago C. Before we had public/private variables, we used a leading underscore as an informal "private". Everyone knew that cat._sound was probably some obscure format for internal use, and we really wanted cat.noise.

 

I've also been using underscores in variables sometimes and they can look hideous.

I would do something like:
"public string Player_Name" instead of "public string playerName"

*Edit
I use camel casing on a regular basis.

It's good that I've received some feedback because now I can tell what is annoying and what isn't when I'm working with other c-sharp programmers in the future.

 

The underscore style uses lower-case only. It would be

player_name

(which should make sense, since we wanted to write "player name", not "player Name"). Upper-case can then be saved for when needed.

BNY_player_name

is the BNY namespace (a trick in languages without namespaces, like, I think, javascript), or acronyms like

align_DNA_sample

.

 

THIS

I've been programming professionally for 13ish years (14? I don't know... I'm getting old). And programming since uhhhhh 199X?

This is my habit, this is a habit I've seen everywhere, some people have contention with it but will usually admit that if they're going to allow _, these are the ONLY conditions under which they'd allow it. All other usage is bizarre and disconcerting.

You have to keep in mind... a programming language is NOT in the favor of the computer. If we wanted to write for the computer, we'd all still be writing machine code/assembly.

The entire point of higher level languages is to make it human readable. And what comes with that is common syntactical practices.

Oh SuRe YoU CaN TyPe LiKe ThIs AnD iT's CoNsIdErEd EnGlIsH.

But any regular English speaker/reader would scream at you for the ludicrous nature of it. As they would for not using punctuation, run on sentences, failing to capitalize, MISUSE OF ALL-CAPS (I still do this), etc etc etc. Sure none of these are against the rules, but they're against the social contract we all as English speakers/writers/readers have agreed upon. Well in the programming world, the same goes there. (and this also implies, each language has their own general rules. And each family of languages tend to share similarish rules)

So in the end... is 'Do_Something_Special()' perfectly legal C#? Yeah, the compiler will never tell you otherwise. But a code cop (a tool designed to flag non-standard code), your peers, and your boss (if you ever get a job in this field) will vocally point out how bonkers you are for writing like a degenerate code imbecile!

With the only exceptions being other people who write the same way you do. Because there is a minority who uses it...

It actually has a name. All of these naming conventions have names.

camelCase - leading letter is lower, each following word starts upper-case.

PascalCase - leading letter is upper-case, each following words starts upper-case.
(funny enough doesn't have a wiki article, but is talked about in other articles like camelCase and the naming conventions article)

snake_case - all words separated by _

...

Also, in C-like land there is another semi-acceptable usage of _ other than the 2 StarManta mentioned. And that's the SCREAMING_SNAKE_CASE which is often used for things like consts or other static identifiers (Java will use them for enums).

 

All hyperbole aside about being a degenerate code imbecile.

Really, the big issue that arises, and I try to tell this to my team at work who have NO gosh darn standard to their naming conventions (they'll mix naming conventions in a single block of 10 lines of code)...

Is that it makes you look amateur/novice.

Because you haven't conformed to the naming conventions of the language you're using. It implies to other coders of that language that you haven't used it for very long since you haven't even picked up the common syntax of the community. And if your conventions are random, it implies you haven't been programming in general for very long.

For example... when I started at my job my first task was to evaluate every one on the team (I was hired at a more senior level). Then I had a sort of meeting/lecture where I attempted to demonstrate some do's and don'ts of code conventions. In said meeting I was able to estimate everyone's background down to language they learned with, years of experience they had, and paradigm they preferred all based on each person's style of coding.

They were blown away I was able to accurately guess such things.

They're now also annoyed because I can just read a block of buggy code and without looking in the commit-log, I can tell who created the bug.

But that's the thing... if you're intimate with a language, you'll be able to notice foreigners/non-native speakers very easily. And to not conform to the norms makes you look like that.

With all that said.

If you're just a rebel and want to fly your own way...

WELL

You do you boo.

 

Actually, I think we discussing a first world problem (like the scandalous fact that my community's glass recycling container doesn't accept magnum-sized champagne bottles. How am I to recycle those? hello???)

Interesting as discussing naming conventions may be, I find it far more annoying when reading code from some programmer who may keep with those conventions, but really, really sucks at naming variables. I'm talking variable names like 'peter' (used to store a 'visited' state while parsing a network topology) or the unthinking 'i', 'j' and 'k' while iterating three levels of attributes (while trying to find a matching flight).

IMNSHO thinking smartly about a variable's name is more important than how you write it down. How often do I see crap like

Code (CSharp):

1. Semaphore semaphore = Task.busy;

when it would be far better to name it 'coreStatus'?

Ah, well.

BTW: @lordofduct: really loved your 'I know where you came from'. Here's one for you: if my variables are all uppercase and consist of 8 characters max, where did I grow up?

 

> ❌ DO NOT use underscores, hyphens, or any other nonalphanumeric characters.
— https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines

 

Yes, this too can be annoying as hell to many, including myself. All of these fall under conventions, just the convention of picking variable names.

Thinking about how you name your variables from all aspects is important IMO. May that be the name you picked, and how you write it down. It's why I mentioned normal English language standards. As an analogy I'd compare the names you pick to the breadth of one's vocabulary.

If I talk like child with small word.

I sound unskilled in the language. And yes, more so unskilled than if I suck at punctuation.

Usually it requires more than just 1 aspect to narrow it down. But with that I'd immediately assume you're old school as all heck. Maybe C on old Unix systems which had an 8 character max for names early on to speed up compilation. The all caps though could also point to old db systems like PICK where people often used all caps since they were case-insensitive. But of course you could have picked it up elsewhere such as DOS's FAT filesystem, which could have influenced your batch files as a child and you carried it into adulthood. But it's not enough to go on alone to say precisely... nor is in a region of convention preference I'm super experienced with if it's caused by a convention far past my years (I'm only in my mid to late 30s).

Though not sure if by "where did I grow up" you mean actual physical locale. Cause I can't do that. Only the strangest of strangely skilled people could. That or if I had met you physically... I know where my team mates grew up by accent alone.

But yeah, it's more than just how you name variables, or what you pick variable names to be. It's also how they organize their code, if/how they apply the paradigm chosen by the lead, how they leave comments, etc. All of that together can usually paint a very good picture of someone's experience. Similarly to how in English slang/accent/mannerism (hand gestures)/etc can all be used to figure out where that speaker came from (and even if they're non-native, like how a German may speak English even if they've mastered the accent).

 

of course I meant "In which Computer Language Village did I spent my childhood".

The all caps is (as you correctly derived) because there was no lowercase, the 8 chars because the designers of the 6502 Assembler that I used deemed eight to be a reasonable limit (the Label column only had 8 spaces -- it was dsigned for a 40 column sceen). When I was 14, my older brother got an Apple //, and for reasons I still don't understand I simply groked assembly. I feel better now

 

The Apple-II came with a really terrific manual, and had using 6502 assembly in the back. Told you the memory locations to access the hi and low res screens, the funny layout, and how the bits combined for colors; but also just how to program using BNE's and the accumulator and so on. As a kid, I learned assembly from it. Thought it was the greatest thing I ever read. I assume it was written by Steve Wozniak.

I remember it was spiral-bound with loose wire, and smaller -- maybe 6 by 8.

 

... and the Glossary contained the helpful description "Feature: a bug as described by the sales department". The built-in mini-disassembler (also written by Woz) simply blew my mind. A year later, when I studied DOS3.2's RWTS routines I seriously considered founding the Church of Steve (I was dimly aware that there was another Steve at Apple. Didn't consider him relevant - he was the Marketing guy after all). A bootstrapper in 254 Bytes? Self-Synching nibbles? How can a single person come up with so many incredibly simple solutions for really difficult problems? True Genius.

 

I'm in a "professional" situation where nobody works on my code ever, it doesn't get reviewed at all. It just has to work. And still I use syntax to keep private and public stuff apart. Even without speaking of best or worst practices, it's a nice way to jog your memory in the future. In my line of work (web) requirements can change on a whim. I have not published any games yet (I'm about a month into Unity) but I'm already having situations where decent naming conventions pay off.

 

That translated badly into English. If you don't use "proper syntax", the program won't run. I assume you're not reminding us to end lines with semi-colons.

 

Yeah sorry, not my native language. I modified to the post to reflect my intent.

 

But microsoft rules are random. The only reason to use them is so other microsoft kids don't pick on you at lunch. I was reading something that reminded me of this: "why do interfaces start with an I" on stackExchange: https://stackoverflow.com/questions/681700/interface-naming-convention

The top answer is "so you can tell they're interfaces". But a joke comment on it has double the votes. The good answer, with citations, explains they didn't want to, but some older code used I's and they figured it would be easier to keep it.

If all you care about is making a good game, you could roll dice and come up with rules as good or better than theirs.

 

I actually like most of the naming conventions recommended by Microsoft. It's not the fact that it's coming from Microsoft, but it feels (most of the time) right. Highly subjective, I know. And sure, this is also based on the fact that mixing the existing .Net types with one's own convention feels wrong and simply looks just ugly in some cases.

Then, there are also the developers coming from other backgrounds, and those who started way back earlier who have generally a very different mindset. The latter also tend to rant about "higher level languages" in general, and all the patterns, conventions, syntax sugar and architectural solutions and decisions ...

Anyway, for me personally, as a rather young developer, it's one of the better conventions out there, because it helps to distinguish types, semantics and intents quite well, at least better than most of the other conventions out there.

 

Но ведь удобнее, когда все говорят на одном языке, не так ли? The same concerns code conventions — when you hire people it's better for them to face idiomatic code base with widely adopted practices, not some home-made rules, convenient for one “dice-roller”. It's a matter of compatibility between people.

 

It looks like you've summed it up in one sentence. You like them ... well, actually they merely "feel right". In other words, you've gotten used to them; they may not be the best, but they're good enough and it's not worth changing. I agree. Using any Style at all is the big gain.

If you're interested, you can find discussions. StackExchange has many. Try "identifier camel vs. underscore". The "why do interfaces start with an I" popped up without me trying. There's another about open-curly on a new line or not. I even reskimmed their "C# coding conventions" page -- that's a lot. I tried briefly to find rules for using "is" or "has" in front of bools, but nothing came up.

All-in-all, C# rules come out as so-so. The benefit is when you see code in a funny format, it will be easier to read. Instead of "hey, that's not C# style" it will be "cool, I heard of this style, but never had a chance to see it in nature".