Misspelled something? No problem, use an alias!

The_Quiet_One

We have a new guy with us. We are maintaining a client's website that uses a lot of Javascript, but the guy we hired admitted he hadn't worked with JS in years and the last time was in highschool to make "kewl cursor effects" for his counterstrike site years before the popularity of AJAX. We still took him onboard because he had good experience with other languages we use and, among our other staff, he still knew more JS than most of the rest of the team, who was more in the .NET web-service side of things.

He was assigned a simple task (the client wanted the submit button of a form to only be displayed after the page had completely loaded) to kind of get his feet wet, and said he was encountering an error that just made no sense: document.getElementById wasn't found to be a valid function. I come to look at his screen, and this is what I saw...

function toggleSubmitButtonDisplay() {

var btn = document.getElementByID('btnSubmit');

btn.style.visibility = (btn.style.visibility == 'hidden' ? 'visible' : 'hidden);

First of all, I explained to him that we use jQuery, which makes this sort of thing a bit easier, and thought I gave him the docs. Second of all, I told him he made the common mistake of capitalizing the "d" at the end and it should be document.getElementById(...). He smacked his head and said, "Oh, geez, a decade since I last coded JS and I still make that dumb mistake". I smiled, remembering when I was starting with Javascript back in the day I made the same kinds of mistakes.

A few minutes later, he said that was the only thing that was causing issues, and I verified it was working as expected. However, when I looked at the source, I was surprised to see document.getElementByID was still miscapitalized. Confused, I looked at the SVN changelog and found he added the following line at the top of the file:

document.getElementByID = document.getElementById;

After asking him about this "solution" he explained that he did it this way because back when he was in high school he made the same mistake over and over again, and figured the best way to combat the bad habit was simply by allowing both variations instead of having to correct himself over and over again. I wonder how soon before all of our JavaScript files are filled with these kinds of "aliased" functions with inconsistent spellings throughout the script just because he can't bother to just get into the habit of typing it correctly the first time around...

da_Doctah

Reminds me of the "abbreviations" file every user had on Stratus. They set up every new user with a file full of shorter names for commands, like "dal" for "display_access_list" and "ccd" for "change_current_dir", and then everyone could add their own favorite typos. Mine had things like "lsit" for "list" and "stpe" for "step".

PJH

@RHuckster said:

I wonder how soon before all of our JavaScript files are filled with these kinds of "aliased" functions with inconsistent spellings throughout the script just because he can't bother to just get into the habit of typing it correctly the first time around...

Is that rhetorical, or is it still in SVN?

frits

@da Doctah said:

Mine had things like "lsit" for "list" and "stpe" for "step".

Waht?

lolwtf

To be fair, 'Id' is braindead.

Renan

@lolwtf said:

To be fair, 'Id' is braindead.

Care to elaborate?

The_Quiet_One

@PJH said:

Is that rhetorical, or is it still in SVN?

I have since fixed it and asked him to just "spell it right" from now on, which he sort of frowned at me over, but agreed to do. We'll see if he produces better JS code if and when he has more JS tasks to do.

Matt_Westwood

@frits said:

@da Doctah said:
Mine had things like "lsit" for "list" and "stpe" for "step".

Waht?

and "shit" for "this". Who hasn't done this?

da_Doctah

@Matt Westwood said:

@frits said:
@da Doctah said:
Mine had things like "lsit" for "list" and "stpe" for "step".

Waht?

and "shit" for "this". Who hasn't done this?

You only made "shit" an abbrevation for "this" if you were actually in the habit of mistyping it that way. Touch-typists all have their own little favorites that always need correcting, and apart from the net-friendly "teh", they're not usually shared with others. Another of mine, which doesn't come into play with Stratus commands, was "form" when I should be typing "from".

I also made a point of taking the "delf" for "delete_file" out of the standard abbrevs I was given. That one's too destructive (given wildcard capability for the file name) to make it any easier than it already is to do before you realize you didn't mean to. Better you should have to type out the whole thing every time to keep you aware of what you're doing.

Fun part was when somebody recognized one and effectively disabled another actual command by adding the correction. After inadvertently running the wrong command a few times, they'd come up with some kind of workaround. Either prefix the real command with a ! to suppress abbrev expansion, or come up with a different name altogether for one of them. (One guy had "shitcan" for "delete_dir" with a recursive follow switch setting.)

@RHuckster said:

"Oh, geez, a decade since I last coded JS and I still make that dumb mistake"

Was it him being honest about it, or did you mean a decade since he started coding JS?

[quote user="Renan "C#" Sousa"]@lolwtf said:

To be fair, 'Id' is braindead.

Care to elaborate?[/quote]Yes. Please.

boomzilla

@Zecc said:

[quote user="Renan "C#" Sousa"]
@lolwtf said:
To be fair, 'Id' is braindead.

Care to elaborate?

Yes. Please
[/quote]
Absolutely! We need another coding standards flame war!

The_Quiet_One

@Zecc said:

Was it him being honest about it, or did you mean a decade since he started coding JS?

He hasn't touched JS since he was a pimply highschool student. Years go by and now he's in his mid-late 20s and he's hired as a .NET developer, but because I wanted a second JS guy on board, and he seemed eager to get back into JS, I just gave him that small task just to get his feet wet again and see how he does. I don't know why, but it just seems really hard to find someone who is a .NET developer AND a JS developer, and this guy was the closest I've found.

Scarlet_Manuka

The original post did mention that.
@RHuckster said:

but the guy we hired admitted he hadn't worked with JS in years and the last time was in highschool to make "kewl cursor effects" for his counterstrike site years before the popularity of AJAX

PSWorx

Reminds me of a math student who was on our uni a while ago. He had to write a lengthy paper on some complicated math problem I've not the slightest clue of.

However, apparently halfway through the paper, he got mixed up with his variables and introduced a new variable for something he had already defined earlier, then kept using it for quite some time until he noticed.

So, in the first half of the paper he was using "u" and in the second half he was talking about "x" instead.

His solution: His paper now starts with the line: Let x := u.

ochrist

TRWTF is case sensitive programming languages (and OSes btw).

@boomzilla said:

@Zecc said:
[quote user="Renan "C#" Sousa"] @lolwtf said:
To be fair, 'Id' is braindead.
Care to elaborate?
Yes. Please

Absolutely! We need another coding standards flame war![/quote]I just don't see why 'Id' is braindead. I don't have any particular preference between 'Id' and 'ID'.

@Scarlet Manuka said:

The original post did mention that. @RHuckster said:
but the guy we hired admitted he hadn't worked with JS in years and the last time was in highschool to make "kewl cursor effects" for his counterstrike site years before the popularity of AJAX

Sure, I just find it strange that he would say "I still make that mistake" instead of "and again I'm making this mistake", or something.

Whatever. You probably didn't even quote him word for word. This was just mindless nitpicking; ignore it.

@ochrist said:

TRWTF is case sensitive programming languages (and OSes btw).

Now this is a coding standard flame war. (but I agree in wrt OS/FS)

ochrist

@Zecc said:

@ochrist said:
TRWTF is case sensitive programming languages (and OSes btw).
Now this is a coding standard flame war. (but I agree in wrt OS/FS)

Hmmm.... I feel misunderstood. I have nothing against the languages or OSes per se (I use a lot of them myself), just the fact that they are case sensitive.

File names and program code should be human readable, and humans don't really see the big difference between ID or Id (or betwen say Bigclient, BigClient, and bigClient). But then again weak typing is not helping this either.

@ochrist said:

Hmmm.... I feel misunderstood. I have nothing against the languages or OSes per se (I use a lot of them myself), just the fact that they are case sensitive.

File names and program code should be human readable, and humans don't really see the big difference between ID or Id (or betwen say Bigclient, BigClient, and bigClient). But then again weak typing is not helping this either.

I came out rather agressive, sorry. It's just that I don't believe programming languages being case insensitive.

Compiled languages should signal an error when they find a case mismatch. I don't care for double being different from Double. Make it the same.

As for scripting/dynamic languages, where objects and/or classes are more like dictionaries ... well, I don't think it's so linear. You can either consider them as a special case of compiled language, where compilation is on the fly, and signal an error; or let the programmer suffer the consequences of mistyping. I personally prefer the latter for I don't think it's worth the slight performance hit, but I find it harder to defend this stance.

boomzilla

@ochrist said:

TRWTF is case insensitive programming languages (and OSes btw).

FTFY

Actually, TRWTF is NTFS, which is actually case sensitive, but is almost never used that way.

dhromed

Case-sensitive URLs.

Now there's a WTF.

"Wikipedia doesn't have an article called PCM_Audio"

Oh, because its called PCM_audio.

This is part of the implementation, though. Wikia urls are case-insensitive.

@boomzilla said:

@ochrist said:
TRWTF is case insensitive programming languages (and OSes btw).

FTFY

Actually, TRWTF is NTFS, which is actually case sensitive, but is almost never used that way.

Incidently, I am making a backup of my girlfriend's home dir - she uses Ubuntu with ext3 - to her NTFS external drive. I get a bunch of errors because she has files with "forbidden" characters such as ( ) ? :.

There is also a directory with the following path (spaces added for clarity) ~ / .macromedia / Flash_Player / #SharedObjects / UQDJ44XD7 / www.gamemotion.com / games\timeforcat.swf containing a single file t4c_save.sol. Notice the Windows-style backslash. A small WTF.

too_many_usernames

[quote user="Renan "C#" Sousa"]@lolwtf said:

To be fair, 'Id' is braindead.

Care to elaborate?[/quote]

Maybe the function is actually making a psychological request rather than one based on the common abbreviation for "identity."

Lorne Kates

[quote user="Renan "C#" Sousa"]@lolwtf said:

To be fair, 'Id' is braindead.

Care to elaborate?[/quote]

This Id is the unconscious, instinct driven part of the personality. By definition it just seeks pleasure and avoids pain, but doesn't rationalize or plan. So perhaps 'braindead' is a bit of an overstatement-- but mindless or unthinking would be acceptable.

The_Quiet_One

document.getElementByEgo('donaldtrump');

FUNCTION_NOT_FOUND

Dammit, I wanted to summon him and punch him in the face. Oh well.

kilroo

@RHuckster said:

document.getElementByEgo('donaldtrump');
FUNCTION_NOT_FOUND
Dammit, I wanted to summon him and punch him in the face. Oh well.

'donaldtrump' is more likely his ID, not his ego. I suppose it might be the same thing, but he still wouldn't bother answering you.

I'm now tempted to write something that uses document.getElementBySuperego at some point. Far, far more tempted than I've ever been to write anything that uses jQuery.

TheChewanater

This is why I prefer using all lowercase with underscores to separate words. "document.get_element_by_id" can't be confused with "document.get_element_by_i_d".

Also, this is in my ~/.bashrc:

alias maek=make

Xyro

@TheChewanater said:

Also, this is in my ~/.bashrc:
alias maek=make



alias cd..='cd ..'  


alias fail='tail -f'

Not sure why my fingers like to keep typing "fail"...

Joeyg

Mine has

[code]
alias iv='vi'

alias vi='vim'

alias mkae='make'

alias grpe='grep'

alias eixt='exit'

alias exti='exit'

alias exut='exit'

alias poewroff='poweroff'

alias fuckoff='clear; banner stop reading over my shoulder'

alias notheft="clear; banner no-theft; echo This system is locked.; echo If the laptop lid is shut or this program closed,; echo SFU security will be paged immediately. To safely; echo unlock, please enter your password.; echo; passwd > /dev/null"

[/code]
...and that's slightly different on all my systems.

Weng

I know a guy who had aliased every command so he could type them in any letter order. It was INSANE.

lolwtf

[quote user="Renan "C#" Sousa"]@lolwtf said:

To be fair, 'Id' is braindead.

Care to elaborate?[/quote]Does it really need elaboration?

"ID" is not a word, so shoehorning it into your naming convention as if it were makes no sense. Although technically an abbreviation, it's treated as an acronym. Hence why everything everywhere with this one exception writes ID rather than Id.

getElementByID => makes perfect sense.

getElementByid => acceptable, consistent.

getElementById => what?

You don't write Php or Wtf do you?

(also haha, CS turned "Trwtf is Php" into "TRWTF is PHP" in the tags.)

The_Quiet_One

@lolwtf said:

[quote user="Renan "C#" Sousa"]@lolwtf said:
To be fair, 'Id' is braindead.

Care to elaborate?

Does it really need elaboration?

"ID" is not a word, so shoehorning it into your naming convention as if it were makes no sense. Although technically an abbreviation, it's treated as an acronym. Hence why everything everywhere with this one exception writes ID rather than Id.

getElementByID => makes perfect sense.

getElementByid => acceptable, consistent.

getElementById => what?

You don't write Php or Wtf do you?

(also haha, CS turned "Trwtf is Php" into "TRWTF is PHP" in the tags.)[/quote]

I beg to differ. http://en.wikipedia.org/wiki/Camel_case#Current_usage_in_computing

It's all about the preferences of the developer who is choosing a specific naming convention. Some prefer to preserve the "all-caps" acronym, whereas others prefer to preserve the "CamelCase" design in order to prevent some people who are skimming through to confuse it with a constant or some such. I've seen many APIs and libraries that do something like getXmlNode instead of getXMLNode. I'd call getElementById just as acceptable as getElementByID... as long as they're consistent about it and choose to keep all acronyms capitalized in their function and class names.

Also, how in the world is "getElementByid" acceptable in any form? Byid is not a word! Would you say getxmlNode is "acceptable" too?

Sutherlands

@lolwtf said:

[quote user="Renan "C#" Sousa"]@lolwtf said:
To be fair, 'Id' is braindead.
Care to elaborate?

Does it really need elaboration?

"ID" is not a word, so shoehorning it into your naming convention as if it were makes no sense. Although technically an abbreviation, it's treated as an acronym. Hence why everything everywhere with this one exception writes ID rather than Id.
getElementByID => makes perfect sense.
getElementByid => acceptable, consistent.
getElementById => what?

You don't write Php or Wtf do you?

(also haha, CS turned "Trwtf is Php" into "TRWTF is PHP" in the tags.)[/quote]

var isTheRealWTFPHP;

var OMGWTFBBQROFL;

hmmm... how about

var isTheRealWtfPhp

public void ConvertDocToXml(Doc x)

hey, better separated!

You think that "Byid" is a word? That doesn't even make sense.

Not writing acronyms the same as regular words? You mean people actually write functions capitalizing XML, SCUBA, NATO, RADAR?

dhromed

@lolwtf said:

getElementByID => makes perfect sense.
getElementByid => acceptable, consistent.
getElementById => what?

I've added my comments.

getElementByID => makes perfect sense. => Makes sense as well, but no more than id or Id.
getElementByid => acceptable, consistent. => Not consistent: Breaks camelCasing.
getElementById => what? => strictly camelcased. Predictable; consistent.

@lolwtf said:

You don't write Php or Wtf do you?

Different usage context, also actual acronyms rather than acronym'd abbreviations. Argument rejected.

-----

I write Id and Html in method names, because we use strict camelcasing. No confusion, no questions, no looking up in the library reference. Choosing to uppercase acronyms is inconsistent with all the other method and variable names.

TheChewanater

The solution is simple - don't use camel-case. Using capitalization to separate words is silly, since capitalization isn't exclusively used at the beginning of words. Sure, you could have a special exception for acronyms, but it's not always clear to everybody what's an acronym and what isn't without looking up the documentation. Also, you could just treat acronyms like normal words, but good luck enforcing that.

void fire () {
	fireMahLASER (getLASERXMLDocument ());
	
	// Or was it...
	fireMahLaser (getLaserXmlDocument ());
	
	// Or was it...
	fireMahLaser (getLaserXMLDocument ());
}

// Versus

void fire () {
	fire_mah_laser (get_laser_xml_document ());
	
	// It certainly wasn't...
	fire_mah_l_a_s_e_r (get_l_a_s_e_r_x_m_l_document ());
	
	// Nor was it...
	 fire_mah_laser (get_laser_x_m_l_document ();
}

Sutherlands

Of course, why didn't I see? Instead of using a capital letter to denote the start of a word, use an underscore, because underscores are used consistently at the beginning of words! This is much clearer and easier to understand. There is no way a developer could understand "use a capital at the beginning of a word, and the rest is lowercase". No, "use an underscore at the beginning of a word, and the rest is lowercase" is much cleaner. And it looks better too! I'm off to refactor all my code!

fatbull

_re _ou _ure _his _s _ _ood _dea?

TheChewanater

TheBestWayToArgueAgainstACodingStyleIsToComposeASarcasticReplyUsingSaidStyleAsIfItWereMeantForNaturalLanguage.

By the way, I have yet to hear a real argument supporting camel case. Perhaps that can be this thread's mandatory offtopic flamewar?

Sutherlands

I have yet to hear a real argument supporting underscores, so I guess we're even.

The_Quiet_One

@TheChewanater said:

By the way, I have yet to hear a real argument supporting camel case. Perhaps that can be this thread's mandatory offtopic flamewar?

All I'd say is use whatever convention the language itself uses. If your language's core libraries use camel case, then you should use camel case. If it uses underscores, than you should use underscores. Otherwise, things just look ugly when you're mixing naming and styling conventions. I'm not a coding style zealot, but I certainly am a zealot for consistency, and I prefer to conform to standards rather than make my own and confuse everyone who's accustomed to a certain convention for whichever language we're coding in.

A simple document defining "guidelines" followed by occasional code review sessions and some IDE code formatting cues make this sort of thing easy. When you get hired in a new job, I can understand that old habits from your previous job could make you stumble a bit as you get used to the new guidelines, but eventually you'll get used to it. Every profession has the same problems. Journalists, pilots, even in clothing retail you have to learn to fold clothes according to their standards. Why are coding standards any different?

Sutherlands

@TheChewanater said:

TheBestWayToArgueAgainstACodingStyleIsToComposeASarcasticReplyUsingSaidStyleAsIfItWereMeantForNaturalLanguage.

By the way, I have yet to hear a real argument supporting camel case. Perhaps that can be this thread's mandatory offtopic flamewar?

The best way to argue against a coding style is to create a straw-man about how hard it is to apply acronyms consistently under said style.

boomzilla

@Sutherlands said:

I have yet to hear a real argument supporting underscores, so I guess we're even.

While I generally agree that it's futile to fight against standards, I find camel case much more difficult to read than underscores. I find neither difficult to type, but definitely have to spend more effort reading camel case symbols.

Sutherlands

@boomzilla said:

@Sutherlands said:
I have yet to hear a real argument supporting underscores, so I guess we're even.

While I generally agree that it's futile to fight against standards, I find camel case much more difficult to read than underscores. I find neither difficult to type, but definitely have to spend more effort reading camel case symbols.

I'm the opposite way. I also find underscores extremely slow to type, because of all the stopping and shifting.

TheChewanater

@Sutherlands said:

I also find underscores extremely slow to type, because of all the stopping and shifting.

I agree that can be true at first, but they're easier to read since it's not all jumbled together.

I believe there's a made up statistic often cited on this forum about how many times code is written compared to how many times it's read.

dhromed

@TheChewanater said:

I agree that can be true at first, but they're easier to read since it's not all jumbled together.

Meh.

It's what you're used to.

boomzilla

@Sutherlands said:

@boomzilla said:
I find camel case much more difficult to read than underscores.

I'm the opposite way.
I also find underscores extremely slow to type, because of all the stopping and shifting.

No more shifting than camel case. I get it that if you've always done camel case, you're used to it and whatever, but the idea that some people read camel case easier than underscores is confusing to me. The underscore is basically like a space, which we're used to in normal reading (unless maybe you're German, and are used to smashing words together). Maybe it's a different technique of reading, like speed reading or something, one way or the other, where you take it all in at once or something.

too_many_usernames

I like how camel case is strange anyway: the first 'word' in an identifier is pretty much never capitalized. It's like reverse of normal sentences where only the first word is capitalized.

I personally assumed that underscores were/are used because they are effectively spaces.

At the end of the day, it really is about conforming to whatever standard applies on the project.

I get more irritated when I see things in a large project written by multiple people when in one place you have an identifier with a name like inputA_value_max but in another place you have, for a similar input, inputB_max_value; it's impossible to do a consistent search with this kind of nonsense. And management gets mad at me when I bring up these 'cosmetic' issues.

pjt33

@too_many_usernames said:

I like how camel case is strange anyway: the first 'word' in an identifier is pretty much never capitalized. It's like reverse of normal sentences where only the first word is capitalized.

Where for "pretty much never" you must mean "pretty much never in the codebases I've looked at". In standard Java conventions class names are camel case starting with a capital and member names (except static final fields) are camel case starting with lower case. However, in standard .Net conventions both the class names and the member names (same exception) are camel case starting with a capital. I've no idea what the conventions are in,say, PHP.

upsidedowncreature

@pjt33 said:

camel case starting with a capital

I thought if it starts with a capital it's PascalCase, not camelCase?

dohpaz42

@boomzilla said:

No more shifting than camel case. I get it that if you've always done camel case, you're used to it and whatever, but the idea that some people read camel case easier than underscores is confusing to me. The underscore is basically like a space, which we're used to in normal reading (unless maybe you're German, and are used to smashing words together). Maybe it's a different technique of reading, like speed reading or something, one way or the other, where you take it all in at once or something.

The underscore character is cumbersome to type because of its position on the keyboard. It disrupts the rhythm of typing, which when not used to it, and can slow you down. I used to be all about the underscore-separated naming convention. But somewhere along the line I love my taste for it, and decided for the camel case style where the first letter is not capitalized. I never did like the - as someone else mentioned - PascalCase; it just looks ugly.

Really, the only argument for one or the other style of casing would be for consistency; if you inherit a project that uses one style, you should continue using that same style; lest you rewrite the entire code base to switch an aesthetic "problem" (of your own making). To me, that is just not worth the time and effort, and potentially could break things if you're not careful. If you start a new project, and do not have a set specific coding standard to follow, then you can choose whichever case style that suits you.

As for the OP, there is nothing necessarily wrong with aliasing, if it is done for the right reasons; using it as a crutch because you're too lazy to change a bad habit is definitely not a right reason. If, however, you come into an existing project that is riddled with case-sensitivity issues (maybe it was developed originally on a case-insensitive OS, but for whatever reason got moved to a case-sensitive OS later), you could alias the "broken" case to the correct case until such a time that all "broken" instances were fixed. This actually occurs a lot on Mac OS X; the Mac OS X journaled file system does support case sensitivity, but because so many applications (Adobe CS is one of them) can't remain consistent in their case sensitivity when referencing files, they recommend that you not use case sensitivity. CS2 used to let you install, and you could easily rename the offending files to fix the problem. CS3 and above won't even let you install if you have case sensitivity enabled. It's a damn shame too.

PJH

@dohpaz42 said:

The underscore character is cumbersome to type because of its position on the keyboard

Really? I suppose, assuming a US QWERTY-style keyboard, you'd also complain about having to type the right paren, minus sign or plus sign often? The former two you don't appear to have a problem using since you used quite a few of them in your post.

Is it really that difficult for you to use your left little finger on the shift and your right little finger for the -/_?

@dohpaz42 said:

[...]when not used to it[...]

Well if that's the only problem, there's an easy solution...