shorthand methods

Question

Is it good or bad practice (or, when is it appropriate) to use shorthand methods?

Lets pretend we're using jQuery here, because it has a lot of them.:

jQuery.ajax()
jQuery.get()
jQuery.getJSON()
jQuery.getScript()
.load()
jQuery.post()

These are all really just shorthand forms for the ajax function, with the exception of load which combines another function later on.

I can use $.ajax( dataType: 'script',) to do the same thing as getScript, but why?

This to me seems insane, and overly complicates the API. Is this good, or bad, or what? Why isn't there a getCSS and a PostCSS and a postScript and a putScript too?

Answer 1

Hm, good question. I guess I would say that the number one rule of programming is DRY: Don't Repeat Yourself. You could argue that any function is "just shorthand for" whatever it does. But whenever you find yourself typing the same thing over and over and over, even if that thing is only two or three lines, it's worth at least asking yourself, should I make this into a function?

Now the authors of JQuery don't know exactly what kind of code you're writing, they just have a general idea of what JavaScript code out there in the world looks like. So maybe they originally just had $.ajax() and then over time they realized, you know, 99% of the time, people are either doing always GETs or always POSTs, it's rare that you do something like:

var method;
if (someComplicatedThing()) method = 'GET';
else method = 'POST';
$.ajax({method:method});

so why not shorten it up a little bit?

I agree it's possible to overdo it though, and have a zillion little functions that are all variants of the same idea, making the API seem overwhelming. So it's a question of finding the right balance, I guess.

• James Khoury: +1 for the balance. This seems to be an issue for my work right now also. My general rule of thumb is if I am going to want to change all of them at some point then I'll make it a function or if I am using it a dozen times (approx.) then I'll make it a function.
• Matt: I would add to that that, as jQuery is a library, from a library perspective you want an API that is readable and helps elucidate what it is doing. As programmers, I think we often read method/function calls and ignore parameters when scanning code, as it gives us an overview of what is happening. With descriptive function calls (that are simply shorthand methods), results in more informative code. This can be taken too far, but, as you've said, it's often about balance.

Answer 2

There is DRY, and there is readability. Every function is a black box from the call, the tendency is to DRY when you are 'one with the code' and the black boxes are fresh in your mind. Then, when you come back to the code later - you are trying to infer what is happening inside the boxes simply from the function names.

Congratulations, you have just atomized your code. And when you did it, you probably were using some type of naming convention that was conducive to typing instead of describing -- using short names that allowed you to 'zoom out' on the code line.

When you come back to it, your ego will be stroked with thoughts of "I must have been a genius the day I wrote this!" -- because you can't understand it now without sitting in the lotus position and meditating deeply.

There is a lot to be said in favor of 'flat coding' and copy/paste extensibility. On the other hand, you have the power of a well-developed framework.

You have to ask yourself, 'what am I making here' -- is any of this a framework that I can extract and formalize? Will I do it? What is my deadline?

So you have a tension along the spectrum of modularity/frameworks and flat code that says what it does right in your face. Don't take DRY and other best practices as a religion, look at your real-world goals and tackle the problem like an infantryman -- your job is to kill the deadline and not leave too many innocent corpses in your wake.