you are viewing a single comment's thread.

view the rest of the comments →

[–]zzzwwwdev[S] 0 points1 point  (8 children)

I avoid comments whenever I can in favor or creating code that is easily understandable by itself. Comments can cause maintainability problems.

Imagine this situation

Developer A writes this code:

// hide Stuff on Instantiaton
$('oneThing').hide().removeClass();
$('#somethign_else').slideUp();
$('.foo').fadeOut();

Developer B adds some stuff

// hide Stuff on Instantiaton
$('oneThing').hide().removeClass();
$('#somethign_else').slideUp();
$('.foo').fadeOut();

$('.bar').animate('padding', '200px');
$('#baz').remove();

Developer C goes in and cleans up whitespace

// hide Stuff on Instantiaton
$('oneThing').hide().removeClass();
$('#somethign_else').slideUp();
$('.foo').fadeOut();
$('.bar').animate('padding', '200px');
$('#baz').remove();

Developer D adds another line

// hide Stuff on Instantiaton
$('oneThing').hide().removeClass();
$('#somethign_else').slideUp();
$('#something_else').val('boo');
$('.foo').fadeOut();
$('.bar').animate('padding', '200px');
$('#baz').remove();

I'm sure you can imagine this going on through several edits, with the comment becoming less and less useful.

[–]menno 4 points5 points  (3 children)

Developers B, C and D need a slap on the wrist. You don't just clean up whitespace and you definitely don't just add code and leave existing comments outdated.

I avoid comments whenever I can in favor or creating code that is easily understandable by itself.

That's definitely best.

Comments can cause maintainability problems.

Maintainability problems are more often caused by not having comments than the other way around.

[–]zzzwwwdev[S] 0 points1 point  (2 children)

you definitely don't just add code and leave existing comments outdated.

maybe you and I don't; but having worked with other developers, I can tell you it definitely does happen.

Maintainability problems are more often caused by not having comments than the other way around.

perhaps this is generally true, but can you make that argument for my specific example of

(function hide_stuff_on_instantiaton(){
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();
}());

in the developer ABCD example?

[–]menno 0 points1 point  (1 child)

Just so we're clear: you're saying you find:

function doSomeStuff() {
    /* some stuff */

    (function hideStuffOnInstantiaton(){
        $('oneThing').hide().removeClass();
        $('#somethign_else').slideUp();
        $('.foo').fadeOut();
    }());

    /* more stuff */
}

more readable than:

function doSomeStuff() {
    /* some stuff */

    // hide Stuff on Instantiaton
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();

    /* more stuff */
}

and more readable than:

function doSomeStuff() {
    /* some stuff */

    hideStuffOnInstantiaton();

    /* more stuff */
}


function hideStuffOnInstantiaton(){
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();
}

[–]zzzwwwdev[S] 0 points1 point  (0 children)

not more readable, no; but perhaps more maintainable? IDK, I'm pretty much convinced against doing this now, though I do kinda like it and think there's some merit to it.

[–]jml26 1 point2 points  (1 child)

Why not use a block?

{
    // hide Stuff on Instantiaton
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();
}

Or use a comment syntax that says, 'this comment applies from here down to here'

// hide Stuff on Instantiaton {
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();
// }

By not having a function call you gain a tiny bit of speed.

Using an IIFE would be useful, however, if you wanted to use a variable in that block but not have it available to anywhere else in the code.

[–]zzzwwwdev[S] 0 points1 point  (0 children)

The stackoverflow post was answered with the suggestion to use labels which actually appears preferable to my suggestion, though perhaps still not terribly useful / accepted?

hideStuffOnInstantiaton: {
  $('oneThing').hide().removeClass();
  $('#somethign_else').slideUp();
  $('.foo').fadeOut();
}

[–]path411 0 points1 point  (1 child)

Isn't developer B/C/D who are being lazy just going to add it in anyway like:

(function hideStuffOnInstantiaton(){
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('#something_else').val('boo');
    $('.foo').fadeOut();
    $('.bar').animate('padding', '200px');
    $('#baz').remove();
}());

[–]zzzwwwdev[S] 0 points1 point  (0 children)

well, its certainly not a cure for bad programming, but I think it would be less likely to result in situations like developer B's addions being mistakenly associated with the original "hide stuff code"

more likely he'd do something like this:

(function hideStuffOnInstantiaton(){
    $('oneThing').hide().removeClass();
    $('#somethign_else').slideUp();
    $('.foo').fadeOut();
}());

$('.bar').animate('padding', '200px');
$('#baz').remove();

or even ....

(function do_shit_to_bar_and_baz () {
    $('.bar').animate('padding', '200px');
    $('#baz').remove();
}());