• (cs) in reply to PiisAWheeL
    PiisAWheeL:
    Your argument is moot. What variables are in play when you flipped your coin? Did you start on the same side of the coin? How high did you flip it? what was the spin? The velocity? The windspeed? If you can duplicate those precisely, you should not expect a different result.

    Also, Flipping a coin has a predetermined number of possibilities. If you flipped a coin, you will get heads or tails. If you flip the coin and the outcome is, say, Velociraptor, THAT would be insanity.

    "Did you get heads or tails?" "Yes"

  • mousanony (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    Your argument is moot. What variables are in play when you flipped your coin? Did you start on the same side of the coin? How high did you flip it? what was the spin? The velocity? The windspeed? If you can duplicate those precisely, you should not expect a different result.

    Also, Flipping a coin has a predetermined number of possibilities. If you flipped a coin, you will get heads or tails. If you flip the coin and the outcome is, say, Velociraptor, THAT would be insanity.

    He's correct. I just flipped a coin and got "Irony fail". What's that?

  • (cs) in reply to foxyshadis
    foxyshadis:
    The revision tag(s) are in the bug log, duh. In most modern bug-trackers (I don't consider Bugzilla modern) they're integrated and can be clicked on to show the diff in question - along with the submitter, which should match the bug comment anyway. The commit message should also reference the bug if it was a specific fix. Seriously, stone age tools get you stone age inefficiency, it's time to upgrade.

    I don't think you understood what I'm talking about. I'm talking about the scenario where you do not know what the original bug was. The scenario where all you have is a piece of code and a repository. Personally, I don't know any code repositories that are sophisticated enough to pinpoint when individual lines of code were added. I use SVN and it certainly doesn't do that. To track down changes I can go through the revision history for the file; but when the revision history is several years in length that can take a while. On the other hand, if the block of code is conveniently labelled with the bug that it was supposed to fix, it takes mere seconds to look up the bug.

  • TK (unregistered) in reply to Snooder
    Snooder:
    foxyshadis:
    The revision tag(s) are in the bug log, duh. In most modern bug-trackers (I don't consider Bugzilla modern) they're integrated and can be clicked on to show the diff in question - along with the submitter, which should match the bug comment anyway. The commit message should also reference the bug if it was a specific fix. Seriously, stone age tools get you stone age inefficiency, it's time to upgrade.

    I don't think you understood what I'm talking about. I'm talking about the scenario where you do not know what the original bug was. The scenario where all you have is a piece of code and a repository. Personally, I don't know any code repositories that are sophisticated enough to pinpoint when individual lines of code were added. I use SVN and it certainly doesn't do that. To track down changes I can go through the revision history for the file; but when the revision history is several years in length that can take a while. On the other hand, if the block of code is conveniently labelled with the bug that it was supposed to fix, it takes mere seconds to look up the bug.

    Unless I'm misunderstanding you, "svn blame" (AKA annotate) does exactly that.

    Or was there something different you had in mind?

  • S (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    As I've said elsewhere, you can't fix stupid. You can't fix willfully subversive either, except by disciplinary procedures.

    Oh, you can fix both of them, if you take your "disciplinary procedures" seriously (and severely) enough... :)

  • Baboon (unregistered) in reply to Walky_one

    Sigh ... it's amazing how many idiots love to stat that code should have comments, and defend the values of comments. What these morons don't seem to realize is that you comment something because it's too fucking complicated. Good, readable code doesn't need comments, you can glance at it an know what it does.

    Another point, people update code, the don't comments.

  • (cs)

    On comments:

    If you are writing the code, add comments so YOU can understand it. In 6 months (more or less) you will have forgotten all the minutia of the problem, and you will probably start from scratch figuring it all out again and again. This is a very good rule to follow.

    You write a small 'hack' to get some details and massage some data. This program will grow into the most critical money making piece of software your company will produce, so you had better comment it for others to understand.

    Avoid comments like "// ..." (a well known author of a programming language does this) as if they were the plague. They don't help anyone and are work sinks.

    That completes todays programming lesson for today. Class dismissed.

    p.s. The metric ought to be "words (English) of comments" not "lines of code". If you can't explain it, nobody will understand.

  • (cs) in reply to Baboon
    Baboon:
    Sigh ... it's amazing how many idiots love to stat that code should have comments, and defend the values of comments. What these morons don't seem to realize is that you comment something because it's too fucking complicated. Good, readable code doesn't need comments, you can glance at it an know what it does.
    Trying to justify your bad habits, I see.

    A good comment doesn't need updating every time you do a little change to the code, and it tells you something not immediately obvious from the code. Sometimes the right algorithm or the right datastructure needs some careful explanation of why things have to be this way. If you've never done anything genuinely tricky (for example, what's special about the number 3215031751?) I could understand you not appreciating this fact.

  • (cs) in reply to PiisAWheeL
    PiisAWheeL:
    My engineering friends taught me this about statistics...:
    anonymous:
    ReverendBubba:
    "The definition of insanity is doing the same thing over and over and expecting different results."
    Call me insane then. I flipped a coin, heads. Then I flipped again... OMGWTF! Tails?!??
    You didn't carry out your experiment far enough. If you flip it twice again, you will get heads, then tails again. This occurs in order to satisfy the "law of averages".
    Your argument is moot. What variables are in play when you flipped your coin? Did you start on the same side of the coin? How high did you flip it? what was the spin? The velocity? The windspeed? If you can duplicate those precisely, you should not expect a different result.

    Also, Flipping a coin has a predetermined number of possibilities. If you flipped a coin, you will get heads or tails. If you flip the coin and the outcome is, say, Velociraptor, THAT would be insanity.

    So what you're saying is that, after typing "Ojbect o" and getting an error, I can expect a different result if I retype "Ojbect" much faster than I did the first time?

  • SG_01 (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    The main problem is that whatever you put in place to ensure good information trails, people will subvert it if they are so minded.

    No rules? People will submit checkins with no checkin comment, and comments like "fix problem" in the code.

    No empty commit comments allowed? People will submit this comment:

    .

    Regexes to guarantee a minimal format? People will submit this comment:

    Ticket 1234: .
    (or whatever other minimal commit comment is required to pass the filter).

    As I've said elsewhere, you can't fix stupid. You can't fix willfully subversive either, except by disciplinary procedures.

    Working with artists, I see a disturbing amount of changelists that have a description such as:

    changed
    added

    Or a variation of that.

  • Baboon (unregistered) in reply to dkf
    dkf:
    Baboon:
    Sigh ... it's amazing how many idiots love to stat that code should have comments, and defend the values of comments. What these morons don't seem to realize is that you comment something because it's too fucking complicated. Good, readable code doesn't need comments, you can glance at it an know what it does.
    Trying to justify your bad habits, I see.

    A good comment doesn't need updating every time you do a little change to the code, and it tells you something not immediately obvious from the code. Sometimes the right algorithm or the right datastructure needs some careful explanation of why things have to be this way. If you've never done anything genuinely tricky (for example, what's special about the number 3215031751?) I could understand you not appreciating this fact.

    Again still think your point is mute, name your methods/functions accordingly ... such a sudoPrime, does this need a comment no, naming variables/methods accordingly reduces the need for comments. I never said code doesn't need comments I said they are overused ... why does some crappy algorithm need comments because some fucktard doesn't know how to abstract or name it accordingly ... the Engrish (yes pun intended) is incredibly expressive ... it's amazing how useful it can be.

    I have yet to come across a lot of code that ever needs comment. The only time I use comments is when something is truly tricky such as a decent non-blocking concurrency algorithm. But again most decent programmers should be able to know what it does beforehand ... guess we will have to agree to disagree

  • (unregistered) in reply to mkl
    mkl:
    If something's *really* self documenting, no comment is better than any comment.
  • Norman Diamond (unregistered) in reply to mousanony
    mousanony:
    PiisAWheeL:
    Also, Flipping a coin has a predetermined number of possibilities. If you flipped a coin, you will get heads or tails. If you flip the coin and the outcome is, say, Velociraptor, THAT would be insanity.
    He's correct. I just flipped a coin and got "Irony fail". What's that?
    I told my father to call a coin flip. He said it would land on its edge. I flipped the coin. When trying to catch it, I missed. It rolled along the floor. It rolled until it reached a wall. It stopped, leaning against the wall.

    At least I didn't flip it again, expecting a different result. Better to be a loser than insane.

  • zeetwo (unregistered) in reply to dkf

    You seriously need a comment for a magic number???

  • korfu (unregistered) in reply to Anonymouse(r)

    gotta catch them all!

  • Jim Blog (unregistered) in reply to Baboon
    Baboon:
    What these morons don't seem to realize is that you comment something because it's too fucking complicated. Good, readable code doesn't need comments, you can glance at it an know what it does.

    Uh, no. That's a fine aspiration but we're not there yet & probably never will be. Complex systems can result in complex interactions which are not obvious from the individual steps being performed. In these cases, comments can be very useful in adding understanding of how the individual steps combine to accomplish the overall end-goal.

    But certainly comments should only be added where they increase the readability of code. If you're writing:

    // Increment i by 1
    i++
    

    then you've just decreased the readability, as you've written twice as many lines for no additional information. On the other hand, the following is a good & necessary comment:

    // WTFApp will have changed wtf-manager.conf which is only read on startup; restart server
    wtfServer.send(SGNL_RESTART);
    
  • Rodrigo (unregistered) in reply to faoileag
    faoileag:
    Pista:
    I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?
    It's an type-coercion idiom in Javascript, you ensure that msg is a string. So, yes, both "old reflex" and "other development platform" probably apply.

    Another one: in old VB it was used to "un-nulify" a String. To prevent the Error 91: Object variable or With block variable not set (NullPointerException in VB World), one could append the string with an Empty; this way the null became "", and other values remained unchanged.

    Right or wront, this is how null safe strings were made back then...

  • Norman Diamond (unregistered) in reply to Rodrigo
    Rodrigo:
    faoileag:
    Pista:
    I'm still wondering what was he hoping to achieve with msg = msg + "". Maybe some old reflex that got to him on some other development platform?
    It's an type-coercion idiom in Javascript, you ensure that msg is a string. So, yes, both "old reflex" and "other development platform" probably apply.
    Another one: in old VB it was used to "un-nulify" a String. To prevent the Error 91: Object variable or With block variable not set (NullPointerException in VB World), one could append the string with an Empty; this way the null became "", and other values remained unchanged.

    Right or wront, this is how null safe strings were made back then...

    Hmm, I suppose that idiom must have been so common that it didn't even need commenting.

    Alex, Rodrigo's comment should be blued.

  • (cs)

    I don't have a problem with putting the bug tracking number in there. On my project, I have to deliver source to a customer that doesn't have access to our source control or bug tracking system.

  • agreeable (unregistered) in reply to Commander Jack

    Right? My favorite part was this: and despite having no Java experience, he loves to "help out" the team by diving into the Java projects.

    When you have no experience, you should keep it that way and never "help out"?

  • Duke of New York (unregistered)

    TRWTF is anon's communication skills. What was he expecting?

  • lluismf (unregistered) in reply to Snooder

    SVN annotate is your friend !

  • (cs) in reply to Baboon
    Baboon:
    Sigh ... it's amazing how many idiots love to stat that code should have comments, and defend the values of comments. What these morons don't seem to realize is that you comment something because it's too fucking complicated. Good, readable code doesn't need comments, you can glance at it an know what it does.

    Another point, people update code, the don't comments.

    Not true at all. Code readability isn't the issue. It's WHY that particular piece of code even exists. I leave comments to my future self (and other team members) so that they understand why that piece of "brilliant" code needs to stay there without having to hunt through all sorts of different systems to hopefully locate it.

    For example, imagine starting a new job and finding something like the following in the billing system:

    if (today=="tuesday") { price = price * 1.0345; }

    That's a simple bit, totally readable, not complicated at all and certainly should make whoever sees that ask Why TF it's there. However, consider seeing the following right above that if statement:

    // 2004-12-24 mike: Per CEO Jim all prices are bumped by 3.45% on Tuesday's no exceptions.

    No WTF here and certainly a clear, concise and helpful comment for clear and concise code. You don't need to go through the ticketing system or blame or whatever the hell else you have. You just move on.

    Granted that comment could be reduced to remove the date and name (as blame etc has that) however that's just being nice. Never mind the fact that I've seen many places lose historical check-in history because the new dev manager likes this system better than that system. When that happens you never figure out what's going on and just have to hope that your refactoring isn't leaving vital stuff on the floor.

    -the idiot.

  • Andrew Au (unregistered)

    Best news of the day of mine! Stupidity is unbounded.

  • Mr Peabody (unregistered) in reply to mortfurd

    +1.. put the issue number in the commit message. Configure Bamboo + JIRA right and your code change will automagically appear in the relevant issue along with any associated code reviews and build versions (assuming you're using smart tags for those as well...)

  • potato (unregistered) in reply to anonymous

    Really, he should have said that the definition of insanity is doing the same thing continuously with no variation in input parameters, and expecting different results, is insane.

    Coin coin = new Coin("heads", "tails"); while(true){ coin.flip(); if(coin.sideUp.equals("a fucking potato")){ //It is insane to think this will ever be reached break; } } //enjoy your insanity

  • potato (unregistered) in reply to anonymous

    Bad post formatting before, sorry.

    anonymous:
    Call me insane then. I flipped a coin, heads. Then I flipped again... OMGWTF! Tails?!??
    Really, he should have said that the definition of insanity is doing the same thing continuously with no variation in input parameters, and expecting different results, is insane.
    Coin coin = new Coin("heads", "tails");
    while(true){
        coin.flip();
        if(coin.sideUp.equals("a fucking potato")){
            //It is insane to think this will ever be reached
            break;
        }
    } //enjoy your insanity 
    
  • The Crunger (unregistered) in reply to potato
    potato:
    Really, he should have said that the definition of insanity is doing the same thing continuously with no variation in input parameters, and expecting different results, is insane.

    Coin coin = new Coin("heads", "tails");

    Why do we even talk about this? The universe is the hidden input parameter to this particular experiment, and this particular parameter is always different, even if classic mechanics (Isaac Newton sans Butterflies) applied to it.

Leave a comment on “Knowing is Half the Battle”

Log In or post as a guest

Replying to comment #:

« Return to Article