Hey guys, I have this great idea for a procedural generated MMO with persistent single shard world that dynamically adapts to changes of the players in real time. Every blade of grass will be modeled and characters will age and scar over the course of their life! I also have spent the past three months balancing and perfecting the damage values for all the weapons (which of course, are procedural generated content as well). Just need a coder.
Like I'm not disagreeing on the use of underscores, I'm just saying that you should first and foremost follow whats agreed upon and second refer to the standards for that language. If Microsoft says avoid underscores when writing C# code and you insist on using them then I'm going to be annoyed. 1) I don't find that underscores makes the code any more readable and 2) It's more difficult for people who expect those naming conventions from the language.
No, first and foremost is local consistency.
I do agree that if you have a choice to make you should stick with whatever is typically used for that same language (hopefully that's what's stated in an official style guide).
However, if you ever get the opportunity to actually set a standard (you won't), I'd have to argue that the Pythonic standard is the best.
Consistency is the biggest thing of course. Code where people are using their own conventions when they touch the project is a fucking nightmare.
I would largely disagree with Pythonic standard. If I write a program in Python I'm going to use it. Pythons functionality is largely based on it's naming conventions to begin with. Then again I think we're both being biased to what we've dealt with the most.
I don't necessarily disagree with using underscores but when you are using them all over the place and using 4-5 in a method name then you might want to reconsider either the names you are using or your conventions for naming.
Pythons functionality is largely based on it's naming conventions to begin with.
You mean the other way round, right?
Two quick reasons why underscores are generally better: 1) It's more like written language - underscores separating words are as close as you reasonably get to spaces separating words. 2) Underscore separators don't create any conflict with other uses of capitalization, such as for abbreviations.
Your first point I'm on the fence about. It does look a bit more like natural language but when your code is littered with underscores it makes it difficult to discern other special characters. It also reduces conflict in names, but that is easily averted with using an agreed upon naming convention. It doesn't reduce bug susceptibility to any degree but that is beside the point.
EDIT: Actually I disagree with myself on conflict. I don't think that is an issue at all really. You're going to run into similar problems whether you have underscores or not. That's a supplementary convention.
EDIT2: I'm not sure I know what you're talking about exactly. Give me an example.
I don't see what the big deal is. I happen to prefer CamelCase myself, but I've got no problem with underscores. One thing I learned within my first couple months working professionally is to just go along with the existing conventions and it now becomes more or less instinctive that I follow along when working with a piece of code. My first two jobs were C shops that used underscores. My next two jobs were C and C++ shops that use CamelCase. It's all good.
Interestingly enough, underscores seem to come mostly from a Unix background. Many or all of the multiword Unix and POSIX API calls (clock_gettime(), pthread_mutex_lock(), etc.) use underscores, and most of the developers at my first two jobs had Unix backgrounds. On the other hand, just about all the Windows kernel and user APIs (CreateProcess(), OpenFile(), etc.) use CamelCase, and most of the developers at my current job had Windows backgrounds. Of course, CamelCase also seems to be pretty common in a lot of object-oriented programming, such as C++, Java, C#, etc. Python seems to be a bit of the oddball due to preferring underscores, though.
CamelCase for class names. If functional language, then fucntions get CamelCase. UNIX people are right. Anything that comes from Windows programmers is wrong.
This is curious, I'm going to ask my friend who worked/works with a lot of unix people and do straight C all day. I'm interested to see what their conventions are. Unix people also LOVE to abbreviate everything, which grinds my gears.
CamelCase for class names. If functional language, then fucntions get CamelCase. UNIX people are right. Anything that comes from Windows programmers is wrong.
You've never had to program Motif or raw X11 code, have you? The Win32 GUI APIs beat the pants off of that swill, although, admittedly, GTK+, Qt, and the like made it much less painful.
CamelCase for class names. If functional language, then fucntions get CamelCase. UNIX people are right. Anything that comes from Windows programmers is wrong.
You've never had to program Motif or raw X11 code, have you? The Win32 GUI APIs beat the pants off of that swill, although, admittedly, GTK+, Qt, and the like made it much less painful.
Those aren't part of UNIX. There are shitty libraries for every language.
Finally realizing that 2x speed playback of podcasts is the best thing ever.
Also, on the above topic, I program in Java everyday. The official Java libraries use CamelCase. Therefore, I use CamelCase. I've pretty much always used CamelCase from day 1 though since that's how I was taught in school, and I've mostly only programmed in C/C#/C++ and Java.
My friend's company has Windows and Unix customers and actually actively differentiates their code to mimic the standards in whichever environment they are working in. So all their Windows drivers are camel case and their kernel code and unix drivers use underscore separators.
I just found out that thisCase and ThisCase are both called CamelCase. I use the first one for variables and functions and the 2nd for classes.
Same here, for the most part. I also use the first one for methods and functions. The general rule I follow is types start with a capital letter and everything else starts with lowercase. I also use ALL_CAPS for constants.
Anyone who uses StUdLy CaPs needs to be flogged, though.
Comments
I do agree that if you have a choice to make you should stick with whatever is typically used for that same language (hopefully that's what's stated in an official style guide).
However, if you ever get the opportunity to actually set a standard (you won't), I'd have to argue that the Pythonic standard is the best.
I would largely disagree with Pythonic standard. If I write a program in Python I'm going to use it. Pythons functionality is largely based on it's naming conventions to begin with. Then again I think we're both being biased to what we've dealt with the most.
Two quick reasons why underscores are generally better:
1) It's more like written language - underscores separating words are as close as you reasonably get to spaces separating words.
2) Underscore separators don't create any conflict with other uses of capitalization, such as for abbreviations.
EDIT: Actually I disagree with myself on conflict. I don't think that is an issue at all really. You're going to run into similar problems whether you have underscores or not. That's a supplementary convention.
EDIT2: I'm not sure I know what you're talking about exactly. Give me an example.
Interestingly enough, underscores seem to come mostly from a Unix background. Many or all of the multiword Unix and POSIX API calls (clock_gettime(), pthread_mutex_lock(), etc.) use underscores, and most of the developers at my first two jobs had Unix backgrounds. On the other hand, just about all the Windows kernel and user APIs (CreateProcess(), OpenFile(), etc.) use CamelCase, and most of the developers at my current job had Windows backgrounds. Of course, CamelCase also seems to be pretty common in a lot of object-oriented programming, such as C++, Java, C#, etc. Python seems to be a bit of the oddball due to preferring underscores, though.
Wait, I forget, you don't pay attention to official Unix standards, and substitute your own standards for what constitutes a "Unix."
Also, on the above topic, I program in Java everyday. The official Java libraries use CamelCase. Therefore, I use CamelCase. I've pretty much always used CamelCase from day 1 though since that's how I was taught in school, and I've mostly only programmed in C/C#/C++ and Java.
I originally wrote "Hunting hipsters is a thing now" and made myself laugh.
Holy shit alternating caps reminds me of my AOL days.
Anyone who uses StUdLy CaPs needs to be flogged, though.
PhD
pH