Linked by Thom Holwerda on Wed 2nd Dec 2009 23:17 UTC
Features, Office A few weeks ago, we talked about how the rise of computing, a field wherein English is the primary language, is affecting smaller languages, and more specifically, the Dutch language (because that's my native tongue). Of course, it's not just the smaller languages that are affected - English, too, experiences the pressure.
Thread beginning with comment 397583
To read all comments associated with this story, please click here.
Comment by Stratoukos
by Stratoukos on Wed 2nd Dec 2009 23:52 UTC
Stratoukos
Member since:
2009-02-11

...and many claim it has something to do with the limited space programmers had to write identifiers. The small size of displays in the early days of computing may have played a role too.


As far a I know, the reason was that spaces where not allowed in identifiers (and still aren't) and the underscore character was not added until a lot later. But even today, it's infinitely easier to write aFunctionThatDoesSomething that lifting your hand or stretching your small finger to write a_function_that_does_something. Consider that when you are programming you have to write these identifiers all the time and that for most the two are equally readable and you can see why camel case is so common in programming.

Reply Score: 1

RE: Comment by Stratoukos
by Doc Pain on Fri 4th Dec 2009 21:31 in reply to "Comment by Stratoukos"
Doc Pain Member since:
2006-10-08

As far a I know, the reason was that spaces where not allowed in identifiers (and still aren't) and the underscore character was not added until a lot later.


After languages (like RPG, older versions) required identifiers to reside in a certain position within the line (e. g. colums 2 - 6 for this and that, column 7 for something else), the space character has been introduced as a statement separator. Later on, the space character and the tab character were means of "pretty coding"; in some languages, they even are a syntactic element today.

But even today, it's infinitely easier to write aFunctionThatDoesSomething that lifting your hand or stretching your small finger to write a_function_that_does_something. Consider that when you are programming you have to write these identifiers all the time and that for most the two are equally readable and you can see why camel case is so common in programming.


The easyness of _ depends on its place on the keyboard, and this depends on the keyboard layout. The german layout, for example, places _ where ? is on the english / US one, this means it's exactly left to the right shift key. But because most programmers are used to the english / US layout, camel case (camelCase?) has been so widely adopted, I think.

According to reading: I agree that myNiceFunction() and my_nice_function() are relatively equal. A problem can arise when you follow conventions that suggest the case for certain text elements within the source code, such as in C: full UPPERCASE for #define macros, beginning with a Capital for enums (I'm not sure about this, but I think I remember that I read that somewhere) and regular lowercase for all other identifiers.

Using _ instead of space gives the advantage of automatic parsing: For example, function names with _ can be easily found and turned into documentation, simply by replacing the _ by a ' ' (a literal space). It's not that easy with camel case where the end of one word has to be determined by the case of the letter, then turning the letter into lowercase again and preceeding it by a ' '. If you now have scripting tools in mind, you recognize that automatically processing _ is much easier.

Finally, just giving a very individual opinion: I mostly use the_underscore_convention for longer identifiers. If the identifiers get really too long, I shorten them and give a comment about what the abbreviation stands for, sviftdft() /* some very interesting function that does funny things */. But in the past, I even wrote right away, without capitalizing the beginning of a word, justallinone, which I today would consider a quite bad style. But much better than my Pascal days, without spaces and cases and everything, init;bk(0);setpicardcolor(x0+x1+xk+ax(rs(r,10,12),qq[x])+q,f[q[ni],kk[ i+1]); - just plain terrible... :-)

Reply Parent Score: 2