How-much-space-do-those-hyphens-take?(arcanesentiment.blogspot.com)
arcanesentiment.blogspot.com
How-much-space-do-those-hyphens-take?
http://arcanesentiment.blogspot.com/2008/07/how-much-space-do-those-hyphens-take.html
8 comments
I guess the guy has a point, but ... I still disagree. There are only two ways to name multiword identifiers, this-is-a-multiword-identifier or this_is_a_multiword_identifier. Both take the same amount of space, and the lisp-version is easier. No serious programmer would write thisIsAMultiwordIdentifier, so it doesn't matter that it's shorter. It saves a few bytes, but it will ensure that your program is completely unreadable.
I disagree with your assumption that no serious programmer would use camel case. Apple's APIs use it and I don't think I've ever seen any program that uses them without using camel case. I find it very easy to read and prefer it to hyphens and underscores.
I guess the guy doesn't have a point. It's irrelevant if hyphens tak 2 or 4% of code. They are still practical (better than underscores), you have to use something to separate word in long identifiers and as you pointed out, cammelCase is not the right way.
Hey guys, lets all dance on the head of a pen together--ruminating on the blatantly obvious!
Anyway all those extra bytes are mostly inconsequential unless you're sending that code over the wire on a regular basis (as with client-side javascript).
Anyway all those extra bytes are mostly inconsequential unless you're sending that code over the wire on a regular basis (as with client-side javascript).
Amen. Any discussion of code style (symbol naming, whitespace conventions, braces, whatever) that is based on an argument about how long it takes to type the code is just wrong. A good typist can write thousands of lines of code an hour at least. That is so far below the development speed of even the best hacker as to be pure noise.
There's a mild case for different code styles from a readability perspective, I guess. But arguing for (e.g.) case insensitive symbol names because the it takes too long to reach the shift key is just insane. But regardless: code readability is 90% a function of organization, not style. I will always prefer to work on well-organized code in mixed styles (or languages) than spaghetti code that adheres strictly to an elaborate style convention.
There's a mild case for different code styles from a readability perspective, I guess. But arguing for (e.g.) case insensitive symbol names because the it takes too long to reach the shift key is just insane. But regardless: code readability is 90% a function of organization, not style. I will always prefer to work on well-organized code in mixed styles (or languages) than spaghetti code that adheres strictly to an elaborate style convention.
This (how much space hyphens take) is a total non-issue. What a waste of time.
I mapped the windows keys on my keyboard to the underscore character, and disabled the normal one to force myself to get in the habit of using it. It takes a bit of getting used to but now I_can_type_these_all_day without wrist strain.
Not much - 7.7% in standard functions (mostly in uncommon functions), 3-5% in a selection of user code.