Which is better?

[EvLSnoopY]

Is it better to have a lot of broken down code in your web pages for clarity, with few comments, or is it better to have a lot of comments in your code with very few lines of code?

for example, the following is "broken down" code with few comments:


function initAll() {
for(var i=0; i<24; i++) {
setSquare(i); // Passing the value of "i" to the setSquare().
}
}
function setSquare(thisSquare) {
var currSquare = "square" + thisSquare;
var newNum = Math.floor(Math.random() *75) + 1; // Getting an integer between 1 and 75.
document.getElementById(currSquare).innerHTML = newNum;
}


Example - Less code with more comments:


function initAll() {
for(var i=0; i<24; i++) { // Beginning the loop
var newNum = Math.floor(Math.random() *75) +1; // Getting an integer between 1 and 75.
document.getElementById("square" + i).innerHTML = newNum; // writes the value of the random number to the table.
}
}


I was reading through a JavaScript book today and this question came to me; Hopefully someone will understand what I'm trying to ask here.

[ahk2chan]

Hi, the way I looked at this is, "breaking" down the code means modulizing it... and the key advantage to me by doing so is code re-use. In your example, if there are other part of the code that make use of the setSquare method (first code block), then if anything changes in the setSquare method, all you need to do is to change the method instead of modifying different part of your code (if you do it inline in your second code block.

So it is not a matter of amount of comment.

[Charles]

However, do keep in mind that with scripts, which are interpreted and not compiled, each line has a huge overhead. For scripts you are likely better off keeping down the code.

[EvLSnoopY]

Charles, I'm glad you said that. I've been under the impression for years that less is better, but when I had read that book yesterday I was completely thrown for a loop.

[Declan1991]

It's not entirely accurate to say less is better. While it's true that if you never use the setSquare function again, you shouldn't really have that function, but if you do, you're better off to define it as a function.

[tracknut]

Aside from "breaking down" code, I think the value of the comments should be considered here. Perhaps the comments you're listing here are purely just an example you whipped up, but I'd say these comments are pretty worthless. On a line of code like:

for(var i=0; i<24; i++) { // Beginning the loop

... I have no idea who might get any value out of "beginning the loop". Perhaps my grandmother, but certainly nobody who's developing code or maintaining your code. I'd find much more value in a comment block at the beginning of a function that tells what this function is intended to do, than in comments that repeat the language's syntax in some sort of English psuedo-code.

Dave

[EvLSnoopY]

Yea, tracknut I just made up the comments for example sakes. I know the comments I made up aren't meant to be worth anything. But I digress; back to the matter at hand. So declan would you agree that it's save to say that one should aim for shorter code when the opportunity permits itself?

[Declan1991]

Yes, shorter code is better (shorter as in less statements, not just running them all into one line), but you should never repeat your code. Ever.

And as a general rule, function calls are expensive. Compare
a.variable;
// TO
a.getVariable();

[EvLSnoopY]

Yea, hey declan I checked out some blogs and some articles on the subject of function calls and how expensive they can be. I honestly didn't realize how expensive they were.

[buntine]

Yea, hey declan I checked out some blogs and some articles on the subject of function calls and how expensive they can be. I honestly didn't realize how expensive they were.
It isn't 1972.

Unless you are writing truly life-or-death software, do not worry yourself with the computational expense of a method call.

Yes, shorter code is better (shorter as in less statements, not just running them all into one line),

Lets not get carried away here. Shorter code is not simply "better". For example, poor use of a recursive algorithm, although it requires less physical code (opposed to performing the same task iteratively), can be a surefire performance killer.

[Declan1991]

Let's not get carried away here. Shorter code is not simply "better".
That's why I said shorter as in less statements. But I suppose I should have clarified that I meant if one was to unroll loops and things like that while counting statements. Physical length of code is irrelevant as IBM found out.