// TODO: fix
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
Sometimes in my code I'll put // Finish and if I don't do it within a short time and go back I sometimes wonder what it was I was supposed to finish. Especially when I did finish and didn't remove the comment.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
Or //Hack: Needs refactoring And when you go back to fix it, it looks fine. :doh:
Wrong is evil and must be defeated. - Jeff Ello
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
Or just // TODO
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
just looked at my code, there's about 50 TODO, half of them are auto generated MFC code, half are probably at least 10 years old each. Too lazy to create a ticket and branch and Pull-Request to take them out.
CI/CD = Continuous Impediment/Continuous Despair
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
I am usually a lot harder on myself with the fix it todo comments. Lots of f words and referring to myself as a mentally challenged crayon eater. :laugh: The icing on the cake is that I forget to remove some of these wonderful comments prior to code reviews. the other devs get a kick out of it. :doh:
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
-
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
That's also how I keep track of enhancements. But a non-trivial bug calls for a comment in the code to notify others who may be looking at it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
That's also how I keep track of enhancements. But a non-trivial bug calls for a comment in the code to notify others who may be looking at it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
[Use the Task List - Visual Studio (Windows) | Microsoft Docs](https://docs.microsoft.com/en-us/visualstudio/ide/using-the-task-list?view=vs-2022)
-
That's also how I keep track of enhancements. But a non-trivial bug calls for a comment in the code to notify others who may be looking at it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
[Use the Task List - Visual Studio (Windows) | Microsoft Docs](https://docs.microsoft.com/en-us/visualstudio/ide/using-the-task-list?view=vs-2022)
Thanks, I'll look into this. What I currently do is tag some comments with special characters:
//* Something to be implemented before commit.
//x Something to delete before commit.
//c Enhancement to code analysis software.And so on.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
you can search for all TODO's in a solution. that's what I do. it works perfectly for me. I do feel that TODOs can get out of hand a lot of times, and so, I try to use them sparingly. There is also a window that is for using and managing TODOs, etc.
-
Even worse: I've actually made some notes about the problem, but they still don't help!
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I do that all the time. :doh:
cheers Chris Maunder
-
just looked at my code, there's about 50 TODO, half of them are auto generated MFC code, half are probably at least 10 years old each. Too lazy to create a ticket and branch and Pull-Request to take them out.
CI/CD = Continuous Impediment/Continuous Despair
-
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
I do the same, luckily I developed this way of working very early in my career so now I am quite efficient with it.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
[Use the Task List - Visual Studio (Windows) | Microsoft Docs](https://docs.microsoft.com/en-us/visualstudio/ide/using-the-task-list?view=vs-2022)
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
The very last thing I do before adding to a commit is to git diff, going line by line getting rid of spare spaces and comments like these, as well as taking notes on lines changed. I do, however, find old notes from past coders very like this, but with dates and initials added. Some are 5 years old - might not be important to fix that, eh? :wtf:
-
Don't you just love it when you leave yourself a note like this in the code, but without an explanation of what's wrong / needs to be fixed? Especially if it's not something obvious :doh:
#pragma message
Paul Sanders http://www.alpinesoft.co.uk
-
I never liked 'TODO' comments in the code. I rather keep a plain text file in the project directory listing all the things that should be remembered and considered. Then I can be sure that I don't overlook a fix because I didn't open that source file. I can more easily sort out a group of related fixes and do them in one cleanup. And I can put in a reminder about planned/desired functionality that doesn't yet have any definite place in the source code of already implemented functionality. In my text files, the entries are not necessarily limited to strict coding actions. They may e.g. state the defined order of method parameters for this project, or identify the standards to be followed. Sometimes it grows to require a splitting into sections. Some of that information later goes into the system documentation.
Visual Studio has a Task List view which brings them all together which I think is better than having a separate file which may or may not get updated when then 'TODO' is done.
