3 ms·

I'm a regular at leaving "TODO" in the code. It's a reminder that the implementation wasn't great and requires another look at some point. If something breaks i

by bArray 10y ago

I'm a regular at leaving "TODO" in the code. It's a reminder that the implementation wasn't great and requires another look at some point. If something breaks it's the first thing I fix in that related code. It's okay to simply not have time to write every piece of code to perfection - it's important to capture that fact though. Another regular thing I use is "NOTE" for code that really is not obvious at all. If my code doesn't read easily, other programmers (or my future self) know to check it for in depth information. If at the time of writing code you recognise it's difficult to understand or not completely correct then I think it's the perfect time to capture that information into the code.

YZF 10y ago
What's going to happen is that TODO is going to: a) stay in the code forever. b) seen 5 years later where it doesn't even make sense any more and by a different person. If it's difficult to understand or not correct don't commit it. Just fix it. It's a false economy. Friends don't let friends TODO ...
- btym 10y ago
  Yes, do everything all at once. And never be able to release anything.
  - YZF 10y ago
    That's not what I said. Do what needs to be done at a given point in time to release. Just don't soothe your conscience by putting a TODO in the code. 99% that TODO will never get done, it's just clutter and code smell. If your code is broken you're releasing something that's broken which is probably going to end badly. If the code is adequate then it's adequate. Often it's just perception that doing it wrong is faster than doing it right. Prefer doing it right. (EDIT- doing it right is often faster)
    - bArray 10y ago
      I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often useful to write some bad display driver for example so that the hardware team knows what needs to be changed and that process is not blocked. The code may drive a very dirty clock signal that tells them: 1. Circuit works in the basic sense 2. Some part of the circuit doesn't work 3. Some other part of the circuit can now be added now that the basic circuit has been confirmed It's okay saying "build the entire thing perfectly", but spending the difference between one and two weeks validating that something at least has the chance of working is massive. You can't afford to block every team that needs to know whether the part you are writing is even a valid concept. This may come back down to design, but sometimes - especially with hardware, the manufacturer/API doesn't tell you the whole story and you need to know that as soon as possible to start compensating for it. I think building a rough implementation and re-factoring it is way more agile than trying to build the correct version first time, possibly leaving some unknown problem to remain undiscovered for longer. It seems backwards to me when we're talking about anything that has an element of risk.
- jquast 10y ago
  TODO messages are a terrible taxation on comprehension of code. Most TODO items should be written "TODIDNT", what would we guess, 99% of TODO items never happen? What is the thinking here, "I knew I should have written the code more correctly, but I didn't -- commenting about what I failed to do here gives me a pass"? Either do it, or don't. Don't tell everybody about what you didn't do, it reduces comprehension of the code at hand. I'm a fan of a DESIGN.txt or other document that everyone can bitch and moan about shortcomings into. It's centralized and threaded by contributions, something like a wikimedia Talk page.
  - bArray 10y ago
    How do you reference a particular bit of code? For example, when you're writing the code you are aware that a number of lines could definitely do with improving but will get you out of the clear for the moment and past the milestone/deliverable. How do you specifically reference the code that you know is bad in this system?
    - jquast 10y ago
      By naming the file, class, method, or function name, or even variables or values discussed.
      - bArray 10y ago
        Don't you find they get updated, moved or renamed? I personally have to deal with scope creep in my projects, so things often change from a strict design. But I imagine a longer project doing the same?
- atjoslin 10y ago
  The reason most people tell me they use todos is, "you can't do everything up front." I agree, but I hate TODOs. They're the worst form of keeping track of technical debt. Just open a ticket! I like to have a tag/label called "debt" that I put these "TODO, bad implementation" type of problems under. That way at least it's tracked.
  - aiiane 10y ago
    A preferred method for doing this at Google is to open a bug, and then leave the TODO in the code with a reference to the bug number. This has the advantage that if someone comes by to refactor the code later, they'll have the chance to go look at the bug (possibly taking it and working on it, possibly resolving it as obsolete if the original issue no longer applies, etc). Having the two-directional link between the bug and the code is quite useful, especially for what is probably the most frequent use I've seen for TODOs: "We could do this better, but the better way is blocked on circumstances beyond our control. Once those change, revisit this."
    - bArray 10y ago
      I actually like that - perhaps that allows you to implement blocking as well, for example: "TODO: X cannot be improved until Z & Y is complete.". The projects I work on tend to have a very quick life cycle, so there isn't even a ticketing system in place other than the occasional post it note. There just isn't the time and the team is tight.
  - flukus 10y ago
    This is my preferred method, but if there is any sort of bureaucracy in place around creating a ticket then it's not a solution that gets used.
- bArray 10y ago
  Background: I work mostly with projects that have <1 year delivery date. It's always better to fix the code I completely agree - in reality there simply isn't always the time. In an idealistic world products aren't released until they are ready and bugs are never produced. But... There's deadlines and there's certainly not time allocated to fixing code unless a bug appears there. Once a milestone or deliverable is met, as far as a manager is concerned it's case closed. Whilst I agree with you from an idealistic stand point, for myself and my line of work I need to leave TODOs to fix the code if the time permits before the release time. Corners get cut and you need some way of knowing where those corners are.

by bArray 10y ago

YZF 10y ago

What's going to happen is that TODO is going to: a) stay in the code forever. b) seen 5 years later where it doesn't even make sense any more and by a different person. If it's difficult to understand or not correct don't commit it. Just fix it. It's a false economy. Friends don't let friends TODO ...

btym 10y ago
Yes, do everything all at once. And never be able to release anything.
- YZF 10y ago
  That's not what I said. Do what needs to be done at a given point in time to release. Just don't soothe your conscience by putting a TODO in the code. 99% that TODO will never get done, it's just clutter and code smell. If your code is broken you're releasing something that's broken which is probably going to end badly. If the code is adequate then it's adequate. Often it's just perception that doing it wrong is faster than doing it right. Prefer doing it right. (EDIT- doing it right is often faster)
  - bArray 10y ago
    I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often useful to write some bad display driver for example so that the hardware team knows what needs to be changed and that process is not blocked. The code may drive a very dirty clock signal that tells them: 1. Circuit works in the basic sense 2. Some part of the circuit doesn't work 3. Some other part of the circuit can now be added now that the basic circuit has been confirmed It's okay saying "build the entire thing perfectly", but spending the difference between one and two weeks validating that something at least has the chance of working is massive. You can't afford to block every team that needs to know whether the part you are writing is even a valid concept. This may come back down to design, but sometimes - especially with hardware, the manufacturer/API doesn't tell you the whole story and you need to know that as soon as possible to start compensating for it. I think building a rough implementation and re-factoring it is way more agile than trying to build the correct version first time, possibly leaving some unknown problem to remain undiscovered for longer. It seems backwards to me when we're talking about anything that has an element of risk.
jquast 10y ago
TODO messages are a terrible taxation on comprehension of code. Most TODO items should be written "TODIDNT", what would we guess, 99% of TODO items never happen? What is the thinking here, "I knew I should have written the code more correctly, but I didn't -- commenting about what I failed to do here gives me a pass"? Either do it, or don't. Don't tell everybody about what you didn't do, it reduces comprehension of the code at hand. I'm a fan of a DESIGN.txt or other document that everyone can bitch and moan about shortcomings into. It's centralized and threaded by contributions, something like a wikimedia Talk page.
- bArray 10y ago
  How do you reference a particular bit of code? For example, when you're writing the code you are aware that a number of lines could definitely do with improving but will get you out of the clear for the moment and past the milestone/deliverable. How do you specifically reference the code that you know is bad in this system?
  - jquast 10y ago
    By naming the file, class, method, or function name, or even variables or values discussed.
    - bArray 10y ago
      Don't you find they get updated, moved or renamed? I personally have to deal with scope creep in my projects, so things often change from a strict design. But I imagine a longer project doing the same?
atjoslin 10y ago
The reason most people tell me they use todos is, "you can't do everything up front." I agree, but I hate TODOs. They're the worst form of keeping track of technical debt. Just open a ticket! I like to have a tag/label called "debt" that I put these "TODO, bad implementation" type of problems under. That way at least it's tracked.
- aiiane 10y ago
  A preferred method for doing this at Google is to open a bug, and then leave the TODO in the code with a reference to the bug number. This has the advantage that if someone comes by to refactor the code later, they'll have the chance to go look at the bug (possibly taking it and working on it, possibly resolving it as obsolete if the original issue no longer applies, etc). Having the two-directional link between the bug and the code is quite useful, especially for what is probably the most frequent use I've seen for TODOs: "We could do this better, but the better way is blocked on circumstances beyond our control. Once those change, revisit this."
  - bArray 10y ago
    I actually like that - perhaps that allows you to implement blocking as well, for example: "TODO: X cannot be improved until Z & Y is complete.". The projects I work on tend to have a very quick life cycle, so there isn't even a ticketing system in place other than the occasional post it note. There just isn't the time and the team is tight.
- flukus 10y ago
  This is my preferred method, but if there is any sort of bureaucracy in place around creating a ticket then it's not a solution that gets used.
bArray 10y ago
Background: I work mostly with projects that have <1 year delivery date. It's always better to fix the code I completely agree - in reality there simply isn't always the time. In an idealistic world products aren't released until they are ready and bugs are never produced. But... There's deadlines and there's certainly not time allocated to fixing code unless a bug appears there. Once a milestone or deliverable is met, as far as a manager is concerned it's case closed. Whilst I agree with you from an idealistic stand point, for myself and my line of work I need to leave TODOs to fix the code if the time permits before the release time. Corners get cut and you need some way of knowing where those corners are.