Thursday, July 30, 2009

TODO or not TODO

In the spirit of continuous improvement and XP's recommendation to always keep the code pristine clean (Refactor Mercilessly), I often perform a lot of refactorings to simplify the code as much as possible as the accumulated debts over the many months of a project can otherwise make working with the code intolerable a few years down the road.

The way I look at refactoring is it's like maintaining your car or cleaning your room. Do it continuously and you'll enjoy driving around or relaxing in your room. Ignore it, and a year later your car is not working as it should anymore and your room is completely intolerable except for running in to sleep and then run out again.

Unfortunately though, while I get insights for many refactorings that can make a significant dent on code simplicity, I often don't seem to find time to perform all of them when approaching a deadline. Should I ignore them and hope for the best? What if I ignore them, and after the deadline, I don't remember them anymore?

The best solution I personally found is to add a TODO in the place where the pending refactoring is useful.

But some developers from the agile community would immediately flinch and say: If you put off refactorings by adding TODO statements, you'll never get to do them and your code will be littered with them.

I used to have that fear myself till I gave that approach a try a few years ago.

Turned out that since continuous merciless refactoring is in my blood, I never find myself ignoring refactorings and letting the code rot. Quite the opposite, I sometimes almost miss deadlines to ensure that the code is in pristine condition.

Nonetheless, given that I have to let go of some refactorings to meet deadlines, I often forget them afterwards. One approach I tried to remedy that is to add reminder tasks about the refactorings in my task management app. Unfortunately, these often get ignored when the list grows too big.

So, I finally resorted to adding TODOs within the code, and I found a number of benefits as a result:
  • Refactoring ideas are preserved next to the code that needs them, thus maintaining context
  • Other developers see them and get an opportunity to perform the refactorings in the process of fixing a bug or adding a new feature
  • Developers are constantly reminded about them whenever they see the code that can benefit from refactoring
Therefore, TODOs are not used as a crutch to avoid performing refactorings when working in the code, they are used instead as reminders for refactorings that there was absolutely no time to perform before some deadline. They are placed right next to the code that needs them, thus constantly reminding developers of them and becoming available for all developers on the team to see as opposed to only the original developer who spotted their need.

I'd be curious to hear the opinions and experiences of other developers on the matter. Feel free to post a comment about it.

p.s. if you're using the Eclipse IDE, there is a view you can bring up called the Tasks view, which aggregates all TODO tasks from your project files (or a selected subset). That can help keep TODOs at the back of your mind at all times. Of course, if you're a command line zealot, you can simply grep or rak the TODOs instead.

Monday, July 27, 2009

Mouse-less Eclipse

Last updated on July 29, 2009

A fellow blog reader commented on a post I made last month titled The IDE vs Editor War in the Ruby World, asking how I actually use Eclipse in a mouse-less way. So, I decided to post a list of all Eclipse shortcuts that I find practical enough to use in my day-to-day work. Note that my focus will be mostly on text editing shortcuts as opposed to language specific shortcuts.

Mouse-less Eclipse Keyboard Shortcuts:

  • CTRL+SHIFT+L: lists all available shortcuts (useful for learning)
  • CTRL+SHIFT+R: lookup up a resource (e.g. html, xml, rb, erb, properties, etc...)
  • CTRL+SHIFT+T: lookup a class name (e.g. String or Customer)
  • CTRL+F6: quickly jump between open files
  • CTRL+E: jump between open files using a filename filter or navigation keys
  • ALT+LEFT and ALT+RIGHT: navigate back and forth in the history of the files I opened. I rely on this one a lot to avoid using the mouse when navigating back and forth between different classes that collaborate to get a user interaction handled.
  • CTRL+O: lookup a method (thanks Kristian for reminding me)
  • F3: jump to method, class, or variable declaration.
  • CTRL+J keyword: instant search of a keyword within a file
  • CTRL+F keyword then ENTER: regular search.
  • CTRL+K and CTRL+SHIFT+K: find next and find previous repeating search for the last keyword
  • Highlight text to find other occurrances of a keyword and then CTRL+K: lets you find a keyword without even typing it if you see one occurrence already in the file (for example, you see a use of the slow performing method "reindex" and you wonder where else it's used in the file)
  • CTRL+H: project-wide search for a keyword. You can also specify file patterns. Make sure to tab into fields or use mnemonics and hit ENTER instead of using the mouse. Once the search completes, pick the result you want using the up/down arrows and then hit enter to open the file.
  • HOME/END/PGUP/PGDN: for navigation of course. I've been surprised many times by how very few developers rely on these buttons to navigate a file efficiently without using the mouse.
  • CTRL+LEFT and CTRL+RIGHT: jump between words for quicker navigation in a line without taking hand off keyboard to use the mouse.
  • CTRL+SHIFT+LEFT and CTRL+SHIFT+RIGHT: quick highlighting of words without taking hand off keyboard to use the mouse.
  • CTRL+L: jump to a particular line number. I keep line numbers visible to quickly locate stack trace errors. This one is invaluable in saving me from paging through a file or using the mouse.
  • CTRL+ALT+DOWN (or UP): clones a line downwards. It's like copy/paste without using the clipboard, which I use often to avoid emptying the clipboard from something I've copied that I'd like to paste somewhere. This is most useful with the CTRL+UP/DOWN shortcuts.
  • CTRL+UP and CTRL+DOWN: moves a line up or down quickly. I often start by cloning a line, and then I move the cloned line down or up to the place I want it to be at.
  • CTRL+SHIFT+F: format content (makes sure everything is indented nicely)
  • ALT+SHIFT+UP: highlights an entire variable name even if it had underscores and multiple words
  • ALT+W P: access preferences via ALT+character mnemonics
  • ALT+character mnemonics in general: useful to do all upper menu navigation instantly without a mouse if you're on Linux or Windows (sorry Mac people). Over time, your nervous system ends up memorizing a lot of the character sequences, saving you from having to even read the menu items, let alone pointing at them with a mouse and clicking them.
Additionally, there are many shortcuts for refactoring and source generation, which I will leave for the readers to discover on their own through the menus of Eclipse.

If I remember more shortcuts over the next few days, I will make sure to update the list above. Although anyone can look up shortcuts in the Eclipse keys preferences page, not all shortcuts are practical, so I am only highlighting the ones that I consistently use to increase productivity and flow. Of course, there may be shortcuts that I have not learned to appreciate yet, so feel free to contribute in the comments the shortcuts you normally like to use.

How do I know about all these shortcuts? Did I learn them all from a reference? How can I keep learning more shortcuts in my day-to-day job? I'll leave the answers to these questions to a future blog post.