• (cs)

    // TODO: update SUBSTITUTE_CODE

  • JW (unregistered)

    The real WTF is that SUBSTITUTE is misspelled ;)

  • Jimmy (unregistered)

    Ok a bad choice declaring a variable that is never used but there are many places in code used in different companies that is marked in different ways for updating, deletion and changing.

    If the change is of a minor importance or is scheduled to be made after some other change this isn't the worst way to remember it by.

  • Dave (unregistered)

    // TODO: Mispel SUBSTITUTE

  • (cs)

    What if you set compiler options to ignore warnings (at least like that)? So much for the to-do.

  • diaphanein (unregistered)

    Best lingering comment I ever left behind:

    // was drunk...will fix later

    Ironically, the code worked, so the code, and comment, remained unchanged.

  • (cs)

    The thing is, "//TODO: blah blah blah" will show up in the Visual Studio Task List window. "int SUSBSTITUTE_CODE" and the comments following it will not.

    "I came across a rather unique way of noting what code needed to fix."
    Was code able to fix it?
  • jim (unregistered)

    I think what you were looking for is #warning

  • SUBSTITUTE_NAME (unregistered)

    SUBSTITUTE_COMMENT

  • me (unregistered)

    int SUSBSTITUTE_CODE; // We NEED to figure out what to do with variables // that are declared but never used.

  • fko (unregistered) in reply to me

    Why not, i'm using from time to time:

    #warning //TODO: blablabla

    this way I can see on every compilation what's todo. Because //TODO is only shown in open document's as far I know.

  • ThreeIfByAir (unregistered)
    <quote> SourceSafe </quote>

    TRWTF.

  • (cs) in reply to JW
    JW:
    The real WTF is that SUBSTITUTE is misspelled ;)

    No, see, that's part of the beauty of it. He INTENTIONALLY misspelled substitute to make it even MORE noticeable.

  • (cs)

    If I were the team lead, my response would have been something on the order of, "We tried // TODO:, but that didn't work. I tried this, in the hopes that it would get someone to fix it - but it hasn't worked either. If you can come up with a suggestion that works, I'll recommend to our manager you get a bonus for it - and I'll at least take you and (if you have one) your SO out to dinner." But then, this is one of those things I care about.

    Now, that having been said, I've also tried the method of having someone have the primary job of cleaning up old code. (It has thus far failed, because management has never bought into it enough to even give lip service to the idea.)

  • trwtf (unregistered)

    TRWTFs:

    • they never heard of bug trackers, it sounds like
    • the idiot that insists on having TODO items as compiler warnings didn't hear about #warning
    • last but not least, SOURCESAFE, for Christ's sake!
  • (cs)

    So: TODO didn't work, because nobody in the team searches for TODOs.

    SUBSTITUTE_CODE didn't work, because whoever is in charge of resolving the overnight build goes MEGO whenever they see it flash past.

    Bashing "managers" over the head doesn't work, because ... well, OK, it does. But only because casual brutality can make six months' worth of Hell seem worth it, somehow.

    Zero errors, one warning. I'd say this is pretty agile, really. If the OP insists on LOL, may I suggest either Barney or the Tellytubbies?

  • (cs) in reply to trwtf
    trwtf:
    TRWTFs:
    • they never heard of bug trackers, it sounds like
    • the idiot that insists on having TODO items as compiler warnings didn't hear about #warning
    • last but not least, SOURCESAFE, for Christ's sake!
    Not that I wish to go on record as calling you a clod, but:
    • Good guess. No evidence for it whatsoever, but good guess. Your guess is as good as any other.
    • There's a teeny, tiny little semantic difference between "TODO" and a compiler warning via #warning. Clue: one of them pertains to the application domain, and one pertains to the implementation (platform) domain.
    • I believe we are as one regarding SOURCESAFE. Pertinent to flame wars, however; not to this post.

    You don't really have a clue, do you?

  • Asiago Chow (unregistered)

    How does this qualify as a WTF?

    I've seen //CHANGEME, //TODO, //REDO, /REVISE/ #UGLY, ;NOGOOD, and probably a few others.

    They are mostly intended as "this works but isn't as general as it seems" notes. E.g. when a generic sounding function has a non-generic implimentation, or when some code that looks multi-use is written in such a way that it will only work in specific circumstances.

    There is nothing saying that those need to be changed in 1 month or 6... it's a matter of priority. If the code is ugly but works, and something else doesn't work, the proper priorization is to fix what doesn't work before redoing code that does what it needs to do.

    Yeah, the method outlined in this story wasn't the best... but it was a hell of a lot better than unmarked potential trouble spots left in the code for people to trip over.

    This:

    int fileFlag = 7;

    or:

    int fileFlag = 7;   //CHANGEME: 7 is correct for now but the code shouldn't be written this way

    Neither is right. Which is worse?

  • Robert (unregistered)

    Ah, this is C-Hash isn't it?

    Isn't there a piece of inappropriate XML that's the correct way of doing this.

  • (cs) in reply to jdpalmer

    // TODO: IRISH_GIRL

  • Spectere (unregistered) in reply to Asiago Chow

    "How does this qualify as a WTF?"

    As people have stated, #warning would have done the same thing without looking completely hackish.

    Additionally, //TODO, //HACK, and //UNDONE comments are automatically marked in the task list in Visual Studio to make them a bit less daunting to keep track of.

  • David Betz (unregistered)

    No one cares for TODO? Yeah it's not like VS automatically lists those for you in a convenient menu for you for anything.

  • (cs) in reply to real_aardvark
    real_aardvark:
    So: TODO didn't work, because nobody in the team searches for TODOs.
    No one has to search for them. As I said before, they show up automatically in the Visual Studio Task List.

    Of course, even that isn't going to force anyone to fix the items mentioned, or even read the task list. We have some //TODOs in our code that date from about 2002.

    [image]
  • d000hg (unregistered)

    In Java, isn't TODO a recognised word - certainly in Eclipse it is highlighted like an annotation (perhaps an IDE-specific feature). Does Visual Studio do this for TODO or HACK or similar?

  • d000hg (unregistered) in reply to d000hg
    d000hg:
    In Java, isn't TODO a recognised word - certainly in Eclipse it is highlighted like an annotation (perhaps an IDE-specific feature). Does Visual Studio do this for TODO or HACK or similar?
    Oh. I should have read the previous post :)
  • d000hg (unregistered) in reply to jim
    jim:
    I think what you were looking for is #warning
    Does C# support the preprocessor? Isn't that a C++ thing?
  • John (unregistered)

    I fail to see how this warning:

    [code] E:\ProdSrc\ProductSettingsDALC.cs(82,8): warning CS0168: The variable 'SUSBSTITUTE_CODE' is declared but never used

    [code]

    Leads to this kind of response:

    "WTF?! I thought to myself."

    Submitter must have never worked on a large team project before.

    Warning CS0168's proper response should be "oh, someone accidentally left some unused code in again, I'll send a helpful reminder to him to remove it." There's no way CS0168 should elicit "WTF?".

  • ChiefCrazyTalk (unregistered) in reply to Robert
    Robert:
    Ah, this is C-Hash isn't it?

    Isn't there a piece of inappropriate XML that's the correct way of doing this.

    Nope, it's C-pound.

  • barf 4eva (unregistered) in reply to real_aardvark

    The problem is not that he doesn't have a clue, but that he was an ass about it.

    Hell, I didn't have a clue or see this as much of a WTF. But now I learned, wooooopie. Time to go to work and deal with real WTFs and with people who realize WTFery is a part of life some times. peace

  • (cs) in reply to Code Dependent
    Code Dependent:
    real_aardvark:
    So: TODO didn't work, because nobody in the team searches for TODOs.
    No one has to search for them. As I said before, they show up automatically in the Visual Studio Task List.

    Of course, even that isn't going to force anyone to fix the items mentioned, or even read the task list. We have some //TODOs in our code that date from about 2002.

    [image]

    No fair -- wrong context. I was tempted to refer to "TODOs" as a time-honoured, Unix-cum-RCS, way of pointing out a problem. It works just as well in a Windows environment, as well -- with or without Visual (eccch) Studio.

    I'm reasonably sure that you're aware of this, but I'm not so sure with n00b "Bugzilla and Process will Save the World!" types.

    Fact is, they don't.

    "TODOs" are old-fashioned "waterfall" (whatever that is) methodology. They kind of depend upon things like (a) the coder reviewing what he/she wrote (b) code review and (c) unit testing.

    Very little of this has to do with nasssty, nasssty, GUI interfaces. Or, indeed, enterprisey "bug" reporting systems.

    It's at a lower level.

    It's worked for about twenty years, and doesn't get in the way of GUIs, Process, or even nastily sliced cheese with out-of-date pickles.

    Get used to it. It just works. "TODO" works. Breaking the overnight build with a manufactured warning works.

    What doesn't work is a bunch of management morons who leave something like this in the system for six months; but, let's face it -- #warning would't work. //TODO wouldn't work. SUBSTITUTE_CODE wouldn't work.

    We're all fucked at this point. As far as I'm concerned, SUBSTITUTE_CODE is perfectly adequate. GO_POSTAL is an equally valid compiler directive, but it tends to have unfortunate consequences in real life.

  • Matt S (unregistered)

    Am I a bad coder for thinking that actually makes sense?

  • Mark (unregistered) in reply to real_aardvark
    real_aardvark:
    Zero errors, one warning. I'd say this is pretty agile, really. If the OP insists on LOL, may I suggest either Barney or the Tellytubbies?

    Agreed. As I was reading the article and saw his reaction to the minor compiler warning of "ZOMG WTF!!?!?!?! one one one !!!" I thought it was a little silly. Unused variables are not a WTF. As others have mentioned, they can be used as placeholders for soon-to-be-added code or for any other number of reasons.

    Sometimes the brats on this site tend to have knee-jerk reactions just because they want the excitement of having found and pointed out a WTF. rolls eyes

  • (cs) in reply to real_aardvark
    real_aardvark:
    "TODOs" are old-fashioned "waterfall" (whatever that is) methodology. They kind of depend upon things like (a) the coder reviewing what he/she wrote (b) code review and (c) unit testing.
    Well, bless you for the thought, sir.
    real_aardvark:
    It's worked for about twenty years, and doesn't get in the way of GUIs, Process, or even nastily sliced cheese with out-of-date pickles... What doesn't work is a bunch of management morons who leave something like this in the system for six months; but, let's face it -- #warning would't work. //TODO wouldn't work. SUBSTITUTE_CODE wouldn't work.
    Management never even looks at our code. They go to meetings, as one of them explained it to us, "so that you don't have to." In theory we're supposed to be a self-policing team through code reviews; but only one of such has happened in the past five years, and thereby hangs a very ugly tale which I might cough up someday when I'm in a foul mood and ready to vent.

    The way we got our collection of up-to-six-year-old TODOs is, we had developers and contractors who wrote applications, put TODOs in their code, had it tested and published to Production, and then left for other pastures. The code's published; no one's complaining; therefore, no reason mess with it.

    Here's an example quoted from one of our applications: "// TODO: (CT) Find out why we display the time only when we can't see any data."

    Frankly, no one here cares why we display the time only when we can't see any data. But none of us have felt moved to delete the comment, either. And so it remains, aging gracefully.

  • (cs)

    // WTF?

  • (cs) in reply to Mark
    Mark:
    real_aardvark:
    Zero errors, one warning. I'd say this is pretty agile, really. If the OP insists on LOL, may I suggest either Barney or the Tellytubbies?

    Agreed. As I was reading the article and saw his reaction to the minor compiler warning of "ZOMG WTF!!?!?!?! one one one !!!" I thought it was a little silly. Unused variables are not a WTF. As others have mentioned, they can be used as placeholders for soon-to-be-added code or for any other number of reasons.

    Sometimes the brats on this site tend to have knee-jerk reactions just because they want the excitement of having found and pointed out a WTF. rolls eyes

    I think you might be missing the point. Everyone leaves in unused variables or methods from time to time. This guy purposefully added this thing in just so he could get the compiler to remind him to fix it later. It's probably the most original WTF on this site in a long while.

    If there is something like this in the code, you can be damn sure that it doesn't compile with exactly 0 errors, 1 warning. There are probably thousands of warnings, in which case something like this would get lost in the crowd.

  • Asiago Chow (unregistered)
    As people have stated, #warning would have done the same thing without looking completely hackish.

    Additionally, //TODO, //HACK, and //UNDONE comments are automatically marked in the task list in Visual Studio to make them a bit less daunting to keep track of.

    Agreed regarding the unused variable... that smacks of someone who learned using tools that didn't support some of the fancier features and hasn't bothered to keep up with the changes. Sort of like some of the "force a divide by zero to cause the program to crash at a certain point and cause a debugger to start because the problem can't be started from the debugger" techniques that used to be commonplace.

    However...it really isn't much of a WTF. So they used an obsolete or poor method to do the right thing. Wouldn't it be much more WTFish if they didn't do the right thing at all?

    From the comment it looks like the code way deployable but not very flexible... some settings are shared in the wrong way. The product will be better if it is made more generic but so long as nobody does anything fancy in the configuration it's OK. When does it need to be fixed? Perhaps never. It may be that nobody will ever use one of those fancy configurations. In that case it really isn't a TODO, doesn't merit a #warning... so what's the WTF?

  • Top Cod3r (unregistered)

    If you are just starting out in programming, you should not do this approach because warnings will not be noticed. It is too easy to ignore TODO: comments, so the best way that I came up with was to insert a divide by zero error. So for example, I would make a variable called intTodo, like this...

    Dim intToDo as Integer = 1 / 0

    This way you can be sure to get the attention of the developers. The nice thing about this approach is you can use different numbers to refer to lines in a spreadsheet,

    Dim intToDo as Integer = 1 / 0 Dim intToDo as Integer = 2 / 0 Dim intToDo as Integer = 3 / 0

    for example would refer to lines 1, 2, and 3 in the master work list spreadsheet.

    Anyways, I thought I would share my team lead best practices with you in case you are a junior developer and looking for ways to improve your style. I like to use this forum as an opportunity to teach and educate others in the developer community.

  • (cs) in reply to Top Cod3r
    Top Cod3r:
    If you are just starting out in programming, you should not do this approach because warnings will not be noticed. It is too easy to ignore TODO: comments, so the best way that I came up with was to insert a divide by zero error. So for example, I would make a variable called intTodo, like this...

    Dim intToDo as Integer = 1 / 0

    This way you can be sure to get the attention of the developers. The nice thing about this approach is you can use different numbers to refer to lines in a spreadsheet,

    Dim intToDo as Integer = 1 / 0 Dim intToDo as Integer = 2 / 0 Dim intToDo as Integer = 3 / 0

    for example would refer to lines 1, 2, and 3 in the master work list spreadsheet.

    Anyways, I thought I would share my team lead best practices with you in case you are a junior developer and looking for ways to improve your style. I like to use this forum as an opportunity to teach and educate others in the developer community.

    By FAR the best joke post I've seen on this site!

  • Bot (unregistered) in reply to Top Cod3r
    Top Cod3r:
    If you are just starting out in programming, you should not do this approach because warnings will not be noticed. It is too easy to ignore TODO: comments, so the best way that I came up with was to insert a divide by zero error. So for example, I would make a variable called intTodo, like this...

    Dim intToDo as Integer = 1 / 0

    This way you can be sure to get the attention of the developers. The nice thing about this approach is you can use different numbers to refer to lines in a spreadsheet,

    Dim intToDo as Integer = 1 / 0 Dim intToDo as Integer = 2 / 0 Dim intToDo as Integer = 3 / 0

    for example would refer to lines 1, 2, and 3 in the master work list spreadsheet.

    Anyways, I thought I would share my team lead best practices with you in case you are a junior developer and looking for ways to improve your style. I like to use this forum as an opportunity to teach and educate others in the developer community.

    I really hope you just forgot the <sarcasm> tag.

  • Brian (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    By FAR the best joke post I've seen on this site!

    I'm not sure if that is an insult or what. But I'm used to being mis-understood, it happens even on my own development team sometimes, especially when we hire a new developer.

  • TopCod3r (unregistered) in reply to Brian

    Lol, sorry that was supposed to be posted by TopCod3r ;)

  • Bot (unregistered)

    In general TODOs should be used for things that need to be cleaned up or changed in the future, not as a way to document bugs. A unit test to reproduce the bug is usually the best way to document a bug until it is fixed.

  • TopCod3r (unregistered) in reply to Bot
    Bot:
    In general TODOs should be used for things that need to be cleaned up or changed in the future, not as a way to document bugs. A unit test to reproduce the bug is usually the best way to document a bug until it is fixed.

    I didn't think bugs were possible if you used TDD?

  • TopCod3r (unregistered) in reply to Bot
    Bot:
    I really hope you just forgot the <sarcasm> tag.

    People often accuse me of being sarcastic, but I think it is just a misunderstanding. Probably because I just have some much training in the field that I forget sometimes that other people may not know what I know.

  • skin256 (unregistered)

    Not the worlds greatest but I like to comment my code with

    'Fix over a beer or 'Reminder, do not create arrays while drunk

    On the serious side, I too have also been guilty of trying to point out something I found in code to my senior developers, in hopes of a pat on the back. Sometimes keeping my mouth shut works better, but again I'm a newb at this :\

  • (cs) in reply to David Betz
    David Betz:
    No one cares for TODO? Yeah it's not like VS automatically lists those for you in a convenient menu for you for anything.

    So? The point is that nobody looks at those, so they don't get fixed. This was a plan to put the TODO somewhere people would be watching. I doubt people are going to be scrolling up through the build log looking for warnings, though. (Unless they set to treat warnings as errors, but then this wouldn't compile at all)

  • CynicalTyler (unregistered) in reply to SUBSTITUTE_NAME
    SUBSTITUTE_NAME:
    SUBSTITUTE_COMMENT
    SUBSTITUTE_JOKE
  • Kyle K. (unregistered)

    IF I was the team lead, my response would be

    "Well, congrats, you passed test #1. You had the initiative and curiosity to both notice and ask about SUBSTITUTE_CODE. Test #2 is to see whether you have the same initiative to step up and do something about it."

    Sounds like an opportunity to me!

  • john (unregistered)

    #warn FIXME: You really, really need to read this code, it's broken

    #ifdef FIX_IT_OR_DIE #error FIXME: I'm not kidding. #endif

  • (cs)

    The problem with this method is that using it in this manner instead of a TODO: is like surrounding it with a SEP field. Even the obvious misspelling doesn't help.

Leave a comment on “SUSBSTITUTE_CODE”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article