views:

390

answers:

4

Given this following sample code which clones a table row, sets some properties and then appends it to a table:

$("#FundTable").append(
    objButton.parents("tr").clone()
        .find(".RowTitle").text("Row " + nAddCount).end()
        .find(".FundManagerSelect").attr("id", "FundManager" + nAddCount)
                                .change(function() { ChangeFundRow(); }).end()
        .find(".FundNameSelect").attr("id", "FundName" + nAddCount).end()
);

Does anyone have any suggestions as to how this might be formatted to be easier on the eye? Is there any accepted convention for doing this?

It would be useful to have a set of rules that can be followed, and that can be incorporated into a set of standards.

+4  A: 

How about:

$("#FundTable").append(
    objButton.parents("tr").clone()
        .find(".RowTitle").text("Row " + nAddCount)
        .end()
        .find(".FundManagerSelect").attr("id", "FundManager" + nAddCount)
        .change(function() { 
            ChangeFundRow() 
        })
        .end()
        .find(".FundNameSelect").attr("id", "FundName" + nAddCount)
        .end()
);

I find that chaining, when used in moderation, can lead to better readability.

karim79
+1  A: 

Don't chain so much.

var newContent = objButton.parents("tr").clone();

newContent.find(".RowTitle").text("Row " + nAddCount)
newContent.find(".FundManagerSelect").attr("id", "FundManager" + nAddCount)
    .change(function() { ChangeFundRow() });
newContent.find(".FundNameSelect").attr("id", "FundName" + nAddCount);

$("#FundTable").append(newContent);

Less chaining, but it seems easier to read imo.

Frank Schwieterman
+14  A: 

I would refactor to this. I find more than 3 chained methods uneasy on the eye

       var $clonedRow =  objButton.parents("tr").clone();

       $clonedRow.find(".RowTitle") 
                 .text("Row " + nAddCount);

       $clonedRow.find(".FundManagerSelect")
                 .attr("id", "FundManager" + nAddCount)
                 .change( ChangeFundRow );

       $clonedRow.find(".FundNameSelect")
                 .attr("id", "FundName" + nAddCount);

       $clonedRow.appendTo("#FundTable");
redsquare
I like this, because it mirrors my approach to regex -- having one uber-regex is often less understandable than 2-3 smaller bite sized ones
Jeff Atwood
This is much better. Just because you *can* chain doesn't mean you *should*.
Peter Bailey
I've always wondered about this, I must confess. My nervousness with this approach is that you are caching a variable that is already cached (on the chain stack). Given that some could be quite large, isn't it better to chain, or is this an acceptable overhead?
James Wiseman
@Jeff Atwood - That scares me a little. If 1 regex = 2 problems, then it follows that 3 regexes = 6 problems! Sorry, couldn't resist.
karim79
I perf test my js almost too much and I have never noticed any overhead with this. I would always vote for readability over a slight performance hit especially one that is quite hard to monitor.
redsquare
@redsquare: it's a big question of taste though isn't it? @Jeff: I disagree that large chaining is like an uber regex. Yes they're both long statements, but that's about where the similarities end. jQuery chains, neatly indented, are very readable even as plain english.
nickf
redsquare
+7  A: 

I indent as if it were bracketed:

$("#FundTable")
    .append(objButton.parents("tr")
        .clone()
        .find(".RowTitle")
            .text("Row " + nAddCount)
        .end()
        .find(".FundManagerSelect")
            .attr("id", "FundManager" + nAddCount)
            .change(function() {
                ChangeFundRow(); // you were missing a semicolon here, btw
            })
        .end()
        .find(".FundNameSelect")
            .attr("id", "FundName" + nAddCount)
        .end()
    )
;
nickf
I lose the fact that something is being appended to fundtable here.
redsquare
you could split and add an extra level of indentation on line 2 there
nickf