My principle is to start general and get more specific. A good label on something is the fastest way to provide information. Name your functions for what they do and your properties/vars for what they store.
I like my function/object-constructor internals to answer three questions in order:
- What's local to this scope? (vars and a list of funcs defined later)
- What's the general action of this thing (basic method calls that lead to output/changes)
- How does the internally defined stuff work (hoisted function definitions last)
The merits of function hoisting for legibility are of course debatable but I prefer general stuff first, details later to trying to learn the general action of a thing while swimming in a sea of internal function definitions. Note: function hoisting only works with function <label>()
definitions, not when you assign anonymous functions to vars as in var someFunc = function(){}
.
On the jquery front, I would use the .animate(options, settings)
object arguments approach since object literal labels can add a lot more clarity (for instance to what 500 means) but I'm sticking with what you have here in case there's a JQ version issue. Also it's easy to miss methods in chaining. It's okay to use line-breaks between '.' operators and we often do where I work to make all method calls clear.
$('.card').click(animateCards); // name well and intent is clear sooner
function animateCards(){
//locals(1)
var optionsObject = {
//<everything in the first animate arg object>
}
//actual comment I would put in my code typically follows:
//functions defined at bottom:
//animateCallback - list so we can see the local funcs
//main (2)
$(this) //breaking chaining into lines like this can be helpful
.stop()
.animate(optionsObject,500,animateCallBack);
//internal functions (3)
function animateCallback(){
//<everything in animate's callback arg>
}
}//end animateCards - always indicate ending brackets of longer functions