Eclipse //TODO in generated coding – Is this useful?

I just returned from Devoxx, a really nice conference. I had a lot of fun and learned a lot.

I also had the oppertunity to talk one influential developer, who shall remain unnamed.

He told me why he prefers IntelliJ over Eclipse. Very interesting and I will open Bugreports for most of his points in the future.

One thing he mentioned was that the //TODOS in the generated code are annoying. I personally agree. I have configured my Eclipse code templates to have no comments included.

Which makes me wonder, does anyone likes these //TODO comments in the generated code? If the majority thinks they are not useful I think we should open a bug report to JDT and ask them to change the templates.

Please let me know via comments what you think.

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, He is the primary author of vogella.com. With more than one million visitors per month this website is one of the central sources for Java, Eclipse and Android programming information.
This entry was posted in Eclipse. Bookmark the permalink.

25 Responses to Eclipse //TODO in generated coding – Is this useful?

  1. mogilka says:

    I often use TODO while coding Java and PHP, think it’s useful.

  2. Dominik says:

    I think that TODOs in generating code is great idea. I work in team and sometimes I need some methods that my friend could or should write. It is easy to find a TODO in code in Eclipse and he could see all TODOs for him immediately after his svn update.
    Only one problem with generating TODOs is that it should not have any comment.

  3. Deepak Azad says:

    I think they are useful. While trying to get something to work I do not always pay attention to code beautification (it happens in a second pass after the bug is fixed). For example I often use ‘Surround with try/catch block’ quick fix to get rid of a compile error and worry about what to do with the exception later. The auto generated TODO in the catch block, reminds me to do this in case I forget :)

  4. ohad says:

    I prefer to throw UnsupportedOpetaionException, this way I will definetly not forget it if needed. but they are cases where empty block is better.

  5. dan zen says:

    I suppose that the TODOS should not appear in the code templates because when I see it in my code,it always give me some extra burden to check anything pending tasks left

  6. Janusz says:

    I always thought they were useful for coders with less experience in the framework to be remembered which methods to overwrite. But after reading code from other coders for a while I have seen to many methods like this one:

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    // TODO Auto-generated method stub//
    setContentView(R.layout.main);

    It seems to me that the programmers that would find the reminder helpful just see the comment as something that the IDE generates and is there all the time and overlook it.

    If the auto generated block would be empty I would get a warning and I would find all the places were somebody forget to implement something as easy as with the TODO tag, without cluttering the Task list.

  7. throw new UnsupportedOperationException("unimplemented") should do the trick instead. :)

  8. Claes Rosell says:

    I think that the TODOs included in code templates are pretty useless.
    I have nothing against the actual comments included in the templates, e.g “Auto-generated catch block”. It is the fact that they are prefixed with TODO that I dislike.

  9. Alex Moldovan says:

    Yes, I find them useful.

  10. Ed Merks says:

    I think it’s useful because most often the stubs need to do something useful and might be overlooked without a reminder. Throwing an exception is also useful because that way you find out at runtime what you didn’t notice at development time.

    In EMF, when you define an EOperation, the generated method in the implementation class for that will look like this:

    // TODO: implement this method
    // Ensure that you remove @generated or mark it @generated NOT
    throw new UnsupportedOperationException();

    We do that because it’s generally necessary to implement the methods, it’s important to mark then so they don’t get overwritten, and it’s good for them to fail at runtime as a reminder.

    Another thing to keep in mind is that there’s just no pleasing everyone. Of course you know that and are recommending to please most people the most, but those who didn’t like it could have acted to tailor things to there wishes while those who like it will probably be annoyed when they need to take action that wasn’t previously required…

  11. chrisse says:

    I think they’re useful, when I place them by myself to keep track of what I have to do.
    When I auto generate some methods and there is a Todo in it I will delete it most of the times because I know there is some work to be done. So Todos in auto generated methods are kinda useless for people who know what they do.

  12. Wolfgang says:

    I like the TODOs, as they show me where I’m supposed to do stuff. Throwing an UnsupportedOperationException or similar is a bit too harsh, as not all methods need to be implemented.
    For those who don’t like them, an option in the prefs would be nice, so the TODOs can stay in the templates, but would be automatically removed after generating code. To make this easier, some additional tag like GENERATED might be helpful.

  13. Henning says:

    I use the TODOs and have the Tasks view configured to show me TODOs on the current element and its children. That way I can see which methods are still to implement in the current file, package, project … whatever I selected in the tree.

    What I don’t like is that unimplemented methods fail silently at runtime. In contrast, NetBeans default method template throws an UnsupportedOperationException – that definitely won’t go unnoticed!

    So I think one should do both: TODO-Comments for discoverability in IDEs at development time, throw an Exception at Runtime.

  14. Mathieu says:

    I use TODOs (and FIXMEs) in the code but I don’t necessarily like the TODOs in the generated codes.

  15. Markus says:

    I’d like to suggest using a different tag (maybe AUTO-TODO ?) that is added to the set of default task tags.

    Beside that, I’d like to support adding UnsupportedOperationException.

    I’m tempted to suggest adding @generated, but Janusz’ comment makes me wary that this will lead to lots of hand-written methods marked so.

  16. Out of everything proposed, outright having an empty block would be my ideal. That being said, hating a program for something that can be found in the preferences is not an excuse.

    Perhaps the problem here for new users is that once they install Eclipse, they’re left pretty much to fend for themselves. The welcome screen does not convey that there’s a lot of knowledge behind the buttons, and in fact I don’t think the information I want to expose to users are in those buttons. I think two buttons that should be up there are Tips and Tricks and Import Settings.

  17. Markus Merzinger says:

    I believe sth. like a generated return value (eg. return null) is more harmful.
    If the generated code won’t compile the developer must become active and leave an appropriate implementation.

  18. Ian Bull says:

    They also provide a ‘learning step’ for developers new to Eclipse. As tool developers, we get very few changes to demonstrate new features or ‘teach’ users about our product. With the auto generated TODOs, Eclipse has provided a very easy way to demonstrate this feature (linking TODOs in code to the Task View).

    As tool developers, one of the hardest lines we need to walk is ‘building a tool for advanced users while still making it accessible and learnable for novice users’.

  19. Chauncey says:

    TODOs are fine but the message “Auto-generated Method Stub” is really dummy.

  20. arzki says:

    I would prefer the templates not to have TODO’s in them. I would prefer a clean, and ordered skeleton for my code. That doesn’t mean I don’t like TODO’s, but I want to put them myself, where I deem necessary.

  21. msangel says:

    it good
    if its is present – it recoment me what I can do
    if I have another work – I will ignore its
    it is not oppose to my work if i have one

  22. Let me tell you an anecdote from work. We are working together with a lot of unexperienced programmers (mostly students) and one template really made me go crazy:

    try {

    } catch (Exception e) {
    e.printStackTrace(); //<— this is what made me crazy
    }

    People were just using this template without ever thinking about what they were actually doing. Luckily we're using Gerrit and so we were able to avoid having e.printStackTrace() sneak into our master branch. However, after some time we thought it would be a good idea to change the template to something like this:

    try {

    } catch {
    TODO implement this!
    }

    Note that the TODO is not a comment! It's actually a compile error. So, people are now forced to fix that error and to think about what they are doing.

    Guess what? Since we introduced this template we did not have to reject bad catch blocks in Gerrit anymore. :-)

  23. Ralf Zahn says:

    I guess the TODO comments are very helpful. They tell you that you should do anything within the generated code.

    IMHO the other solutions are not better.

    1. Developers, who leave the comment after implementing a generated method stub, are not a valid reason for not using the comments. You could then remove exception handling or inheritance because developers are not able to use them in a correct way.
    2. throw new UnssupportedOperationException() only tells a missing implementation at runtime. If you have this within a catch block, it will only occur in case of an error. Instead, developers and tools should be able analyze tasks by static code analysis.
    3. e.printStackTrace() is not a good way for productive code, but for prototyping issues. And for unexperienced developers. Invoking this method is not a fault, but a solution that is very restricted.
    4. Removing the trailing // to cause compiler errors is bad. Templates should always generate correct code. Think about unexperiences developers or architects that want to generate stubs that a developer should implement. Causing compiler errors will cause failing builds. There are also conventions that do not allow check-in of code that contains compiler errors.

    So these comments are correct and should not be removed.

  24. Lars Vogel says:

    Thanks to all for the feedback. Its obvious that the general consense is that the //TODO comments are in general make sense and should not be remove in the default.

  25. Russ Heaton says:

    As a newbie, I find it helpful. I can see where it might seem unnecessary or redundant for a more experienced individual.

Comments are closed.