Commenting every line or block of code change with the task number of the change.



  • Opinions?

    I don't want to sound crazy when I say I don't like this.



  • Stupid idea... unless it's some hack or WTF you want to justify... and continuing with the eval topic:

    // Because of TICKET-14 and stupid shit
    var ret = eval(input);


  • I feel that way.

    // ticket5030
    code line 1
    // ticket5040
    code line 2 // ticket5050
    // end ticket 5030
    code line 3
    ...
    code line 10
    //end ticket 5040
    


  • But, I need a reason for why it's stupid.

    Like, a concrete reason.

    I'm thinking it's clutter.

    But I'm told it's for quickly finding out what feature the new lines are introducing.



  • Well, because comments are usually hard to maintain:

    // Because of TICKET-14 and stupid shit
    var ret = eval(input);
    

    On next sprint

    // Because of TICKET-14 and stupid shit
    try{
        // Fix TICKET-27
        var ret = eval(input);
    }catch(err){
        // w00t!
    }
    

    And on next sprint

    // Because of TICKET-14 and stupid shit
    try{
        // Fix TICKET-27
        var ret = eval(input);
    }catch(err){
        // Fix Ticket-29 handle errors
        handleError(err);
    }

  • I survived the hour long Uno hand

    Sane people put the ticket numbers in the commit message, so you can find them when doing a blame but they don't clutter up the code.



  • It makes sense to me IF the ticket tracking software is suitably easy to navigate and your fellow developers actually use the support tickets to track and discuss the bug and fix, instead of using email chains



  • I've wondered the same thing.

    It's in the source control, that's what that's for.

    We put the ticket/task in the source control commits too.



  • They're stupid because any decent developer uses a source control system to keep track of changes, and any decent source control system offers a "Blame" feature to highlight who changed what line of code at a given moment. In the change, just mention the ticket number. In TFS you can also link a work item (such as a Task or Bug) so that all specifics about why the change was made is within a few clicks reach.

    Ticket numbers in code is just useless clutter that nobody reads (let alone understands) and that is maintained even less, as explained above.



  • @mrguyorama said:

    It makes sense to me IF the ticket tracking software is suitably easy to navigate and your fellow developers actually use the support tickets to track and discuss the bug and fix, instead of using email chains

    Sufficiently advanced WTFery is indistinguishable from sabotage.



  • svn/git blame/annotate might work. Avoids the hassle of adding it in comments, and can retrieve it for every line.



  • Going back to iInesat, I used put details of changes in the "commit" message. I was told to stop doing that (for some obscure reason that escapes me now but had something to do with not being necessary because "...if you type git -umpteen [stupid/switches], it will list all the changed code, besides you can use bugzilla..."). Oh, god! don't get me started on that - ALL "on the fly / ad hoc" documentation was it's own seperate incarnation of bugzilla.

    Getting back on topic: When I bugfix / feature enhance old spaghetti code I like to leave something like a ticket or reference number - mostly because a single simple fix would often involve several changes in and across several "scripts". Also, after "decoding" something that turned out not to be the issue, I would leave a note or reference for use when it did become the issue. Or I was (eventually) given a refactoring shotgun license.

    Sometimes I leave the old code there, just in case...

    When I am refactoring, I use self-documenting code 🤣, or rather code that has meaningful names and appropriate comments etc.



  • The source control merges should have the task numbers.

    There's no need for the source code itself to have them.

    If you want to know the number, view the file's history and yank it from source control.

    THUS IS MY OPINION.


  • Winner of the 2016 Presidential Election

    IMO it depends on a few things:

    Did that already happen to the rest of the code? If so: Not crazy (at least not more crazy than the other people who thought the exact same thing)
    Do you really mean EVERY LINE? If so: crazy (IMO, see point 1)
    Do you think it would create too many comments? If so: crazy because of the reasons other people have pointed out here.
    Do you lose your job if you don't comment every line? If so: crazy, but you should probably still go job hunting!

    Filed Under: Just my two cents as a guy who never had to face this problem



  • @Kuro said:

    Did that already happen to the rest of the code?

    Non consistently, but now that it is in the review document there is more pressure to see it done.



  • @xaade said:

    But, I need a reason for why it's stupid.

    Like, a concrete reason.

    Because your VCS should be doing that for you. If you use TFS, you can actually hook tickets to changesets - don't know if any other system provides that level of integration, but there's always commit messages.

    No need to comment each line, and a year from now, who gives a shit which ancient ticket was resolved by that line?

    Also what do you do when you change the code?

    //resolves ticket 57
    //now resolves ticket 95 - Dave
    //actually it resolves both, and also 215 - Joe
    


  • @Yamikuronue said:

    Sane people put the ticket numbers in the commit message, so you can find them when doing a blame but they don't clutter up the code.

    This. The only reason to put a ticket number in a comment is if you're doing something particularly non-obvious, and linking to the ticket for background saves at least 5-10 lines of comment.



  • We are using TFS....

    @Maciejasjmj said:

    //resolves ticket 57
    //now resolves ticket 95 - Dave
    //actually it resolves both, and also 215 - Joe

    yep.


  • I survived the hour long Uno hand

    @Maciejasjmj said:

    If you use TFS, you can actually hook tickets to changesets

    JIRA and Github both display relevant commits on the ticket if you put the ticket number in the commit message.



  • @xaade said:

    Non consistently, but now that it is in the review document there is more pressure to see it done.

    So some moron decided to enforce this and leave their stupidity in printed text? HA!

    @Yamikuronue said:

    JIRA and Github both display relevant commits on the ticket if you put the ticket number in the commit message.

    Yep, and are smart enough to know that this:

    Fix TICKET-17

    Means that the ticket is fixed and reset its status.

    And if you use pull requests you also get this:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.