Giza aka Douglas Muth&#39;s LiveJournal

I like (and use) code that has underscores, because_my_eyes_parse_the_underscores_as_spaces, which_makes_it_easier_for_me_to_read.

Plus, a missed capitalization could make for a bug that's very difficult to spot.

From:

I prefer MixedCaseVariableNames. Underscores do not parse as spaces to me, and even if they did I'm not convinced my parser can handle spaces in variable names. MixedCaseVariableNames only introduce hard-to-find bugs if you use variables that differ only in case - a bad practice to get into. And of course, for those of us who use languages that are not case sensitive, this isn't a problem anyway.

From:

> MixedCaseVariableNames only introduce hard-to-find bugs if you use variables that differ only in case

Perhaps I should have worded my complaint better.

Let's say I'm working on a piece of code for the first time and there is a variable called FluxCapacitorIsThePower. If it's a weakly typed language that doesn't require me to initialize my variables, and I accidentaly type FluxCapacitorIsthePower in some place, I'm goint to have a hard time finding that. I think I would have a much easier time finding a missing character or underscore than I would have finding one that isn't capitalized properly.

From:

> If it's a weakly typed language that doesn't require me to initialize my variables, and I accidentaly type FluxCapacitorIsthePower in some place

True, in a language that does not require you to explicitly declare your variables (a different statement than yours; weak typing and initialization requirements have nothing to do with implicit variable declaration), and is also case sensitive, this would be a problem.

Do any such language exist? I can't think of any offhand.

From:

Sorry, my bad on getting explicit configuration confused with typing. Anyway...

I can cause such breakage in PHP with the following code:

$FooBar = 1;
print $FooBar . "\n";
print $Foobar . "\n";

This results in printing the value "1" on the first line, and nothing on the second line.

From:

s/FooBar/foo_bar/g
s/Foobar/foobar/g

From:

Okay then, let's say I have to deal with code that looks like this (as per your suggestion):

$foo_bar = 1;
print $foo_bar . "\n";
print $foobar . "\n";

Just by glancing at that code, I have a much easier time of figuring out is wrong. Clearly one variable name is longer than the other, and one has what my brain parses as a space in it.

Maybe our brains just work differently. :-)

From:

s/is longer/is taller
s/, an.*/\./

From:

nius.livejournal.com

*chuckles at you and Rusty* I actually like underscores, myself, but I guess I just like to make variable names a bit too long. But studycaps, yea, those suck.

From:

kianga.livejournal.com

... which has such gems as:

baseDir = [somePathString stringByDeletingLastPathComponent];

But I bet you can tell exactly what that method does, which is much better than the POSIX way where such a function would be called "strdlpc". And it's not difficult to type, as long as you have code completion. :-)

From:

> And it's not difficult to type, as long as you have code completion. :-)

Oh man, don't even get me started on that.

Why do people need IDEs for writing code, anyway? What's wrong with vim and a little syntax highlighting?

From:

IDEs make things Easier, Faster, and Less Prone to Swapping the Order of Parameters. Caps intentional.

From:

Um, if I'm confused about the order of parameters, this is what I would do in vi:

:e lib/class.php
/ functionname
dd
P
:w
:bd
P

Then I can write the function call with the proper parameters and delete the copied function line when I'm done. That approach has served me well in the past.

From:

In Delphi's IDE, I do this:

functionname(

and up pops the parameter list.
In JBuilder, if javadoc documentation exists for the fuction, that is also displayed.

From:

zenmouse.livejournal.com

This is really beginning to sound like slide rules vs. calculators, and we know who eventually won that fight.

Old, obscure methods, no matter how quickly and efficiently used by a master of such techniques will always lose to the paradigm of easier.

When it comes to fresh blood in the industry only masochists avoid the path of least resistance.

Just my fiftieth of a dollar.

From:

I agree. A good example is the Superior Technology of Microsoft Windows. As you may be aware, it has completely unseated traditional UNIX systems in applications such as Online Transaction Processing, clustering, and data warehousing, especially on the mainframe and supercomputer markets.

Oh, wait.

As I just illustrated, new technologies aren't always better, nor do they necessarily make you more productive. Case in point: vi/emacs. I work with some damned talented people in my office here, and everyone uses vi/emacs, straight from the command line. Nobody here uses any "visual editor", because the bloat of such would outweigh the increased speed in code writing. (As much as I liked BBEdit back when we worked in Allentown, it's quicker for me to ssh into the box, cd to the directory, and start up vi. Really.)

Another important thing to consider is that Shiny Code Writing Tools don't necessarily make up for ineptitude of the person behind the keyboard. Example: How many Visual Basic programmers do you know who are absolutely clueless about the fundamentals of programming? All the tools in the world won't help them architect better code.

From:

tailen.livejournal.com

I agree with the HateOfCapitalVariableNames. Especially because you have to move your eyes back and forth over it a few times to read it. Proper (non-computer) languages have spaces for a reason and getting rid of them does not help comprehension one little bit.

What ticks me off a lot more, tho, is how some people use unfathomably nondescriptive variable names like iTrp or cWtt. And convince themselves they're easy to decipher and good programming practice because the first letter indicate the type. Oh yeah, thanks a lot, that makes it easy for me to find the place they're declared. I still have to go through the whole code to figure out what the heck it's used for.

From:

Oh, you mean Hungarian Notation (http://ootips.org/hungarian-notation.html).

If memory serves, it came about because there were M$ programs that literally had dozens of variables in a particular namespace. Rather than doing something sensible such as say, refactoring the code or grouping like variables into arrays/hash tables, they decided instead to change the names of the variables to use Hungarian Notation to indicate what was stored in the variable. Ugh.

-- Giza (and you thought there was some nasty Perl code out there...)

From:

Well, Hungarian Notation specifies the type prefix, but doesn't say anything about the remainder of the variable name. People who remove vowels or other 'unnecessary' letters from what would otherwise be describe variable names deserve to be shot.

From:

triggur.livejournal.com

Like it or not, some languages' coding standards recommend MixedCaseNaming. Some people consider it easier to read than ____var_name_ (How many underscores was that again? Who knows.)

Perl's coding standards may not coincide. But there's a lot of perfectly mainstream languages that do, and even outside coding standards at the language level, different shops have different standards. So just get used to the fact that it will be different at every job you hold.

From:

> Some people consider it easier to read than ____var_name_ (How many underscores
> was that again? Who knows.)

Viewing that in a fixed width, I can easily count 4. :-)

My own coding standard on leading underscores is that I will start private methods/vars in a class with 1 underscore[1]. The only exception to this is when I code in Python, which mandates two leading underscores for private data. But in that case, I will never start anything in Python with a leading underscore.

[1] I originally did this in PHP 4, since there was no support for private vars/functions in classes. I ended up keeping that notation because I discovered that it helped me keep track of which functions were publicly callable and which were not just by looking at the function name.

From:

drzarron.livejournal.com

You Young Pups!

Back when computers were steam powered, we used to use LETTERS for variables and you never knew what they stood for and we liked it just fine!

----------------------------------------------------------
David M Stein

"GOD is REAL.. Unless declared integer."

From:

shockwave77598.livejournal.com

I've always had my own style, similar to that. The first word is the variable name and the second what sort of function it plays.

commFlag
bytearrayIndex
pidloopError
diallistPtr
mainloopState

I only throw one Cap into any name where appropriate. It's handy, though I can certainly see where long, drawn out names like those would be a pain to read.

From:

unciaa.livejournal.com

I use Shockwave's system also. I don't like underscores for two reasons:
1. an underscore is about 3 times slower for me to type than a capital letter. Capital letter = right finger + left finger.
Underscore = right finger + right finger. Also, I can touchtype common alphanumeric characters, whereas the underscore is one of the least used characters, making its use both slower and more error prone
2. It makes code easier to parse to me. Yes, underscores parse as spaces, and I don't want that. Spaces translate to new functions/variables, it makes it harder to see where the function_with_a_lot_of_words ends and where its parameters kick in.

Personal preference.

From:

unciaa.livejournal.com

His system of capitalization, rather. Function starts with a small letter, all consecutive words in it are capitalized. I don't usually shorten them though, I find that hard to keep track of.

From:

> Underscore = right finger + right finger.

Does this slow you down? I mean, for me, doing an underscore is right pinky finger + right middle finger. It's become second nature to me.

> Spaces translate to new functions/variables, it makes it harder to see where
> the function_with_a_lot_of_words ends and where its parameters kick in.

Isn't that what the opening parenthesis is for? o.O

From:

unciaa.livejournal.com

It's slower because I'm not used to using that character on a regular basis. Plus, as said, left+right is faster than right+right [or rather, it has a lower fumble rate].

void exampleFunctionNumberOne(int hello, float goodbye)
void example_function_number_one(int hello, float goodbye)

The first one, for me, is far clearer when it comes to seeing where the variables start. I could've cheated and put a space before that first int and made it even more obvious, but I don't really do that in practice. The division the space provides between "function name" (and unimportant designator) and "input variables" is worth the hassle of midname caps.

From:

I'd like to add a third example into that function list:

void exampleFunctionNumberOne(int hello, float goodbye)
void example_function_number_one(int hello, float goodbye)
void example_function_number_one (int hello, float goodbye)

In that list, the last one is what I would write, and what I would find to be most readable. Then again, in a proper context, it would really look more like:

void example_function_number_one (int hello, float goodbye) {

...which I think makes it look even more readable, thanks to the trailing brace that starts the code block of the function.

The more discussion I see on this entry, the more I'm beginning to think that different peoples' minds work different on matters such as this.

From:

Are you both mad? Underscore is left-pinky and right-ring.

From:

danieltheferret.livejournal.com

> Does this slow you down? I mean, for me, doing an underscore
> is right pinky finger + right middle finger. It's become
> second nature to me.

I use left + right for the underscore. Am I weird?

From:

kianga.livejournal.com

I sometimes use both studly caps and underscores to distinguish different programming "environments".

char *my_string = "hello world";
NSString *myString = [NSString stringWithUTF8String:my_string];

"my_string" is a traditional null-terminated C string, while "myString" is a Cocoa NSString object. If often mix these two styles when I call C functions from Cocoa. I associate underscores with low-level (C) functions, and studly caps with the higher-level (Cocoa) functions, classes or methods.

From:

That's a good idea.

From:

bigtig.livejournal.com

Bah... if the JavaFolksWhoLikeToNameThingsReallyLongAndFunny bother you, just declare all you variable in Java with a $ as their first character and whatch their minds implode.

Yes, it does work.

From:

Wonderful!

From:

megadog.livejournal.com

MAYBE WE SHOULD ALL GO BACK TO USING UPPER CASE ONLY LIKE IN THE GOOD OLD DAYS OF FORTRAN-60 ?

[DEATH TO ANYONE WHOSE RECORD-LENGTH EXCEEDS 72 COLUMNS]

From:

*evil snicker*

http://c2.com/cgi/wiki/

From: