Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
by Mathias 27. May 2009 13:36

The iterative nature of writing code inevitably involves adding code which is good enough for now, but should be refactored later. The problem is that unless you have some system in place, later, you will just forget about it. Personally, I have been trying 3 approaches to address this: bug-tracking systems, the good old-fashion text to-do list, and its variant, the task list built in Visual Studio, and finally, comments embedded in the code.

Each have their pros and cons. Bug tracking systems are great for systematically managing work items in a team (prioritization, assignment to various members...), but work best for items at the level of a feature: in my experience, smaller code changes don't fit well. I am a big fan of the bare-bones text file to-do list; I tried, but never took to the Visual Studio to-do list (no clear reason there). I hardly embed comments in code anymore (like 'To-do: change this later'): on the plus side, the comment is literally tacked to the code that needs changing, but the comments cannot be displayed all as one list, which makes them too easy to forget.

Today I found a cool alternative via Donn Felker’s blog: #warning. You use it essentially like a comment, but preface it with #warning, like this:

#warning The tag name should not be hardcoded
XmlNodeList atBatNodes = document.GetElementsByTagName("atbat");

Now, when you build, you will see something like this in Visual Studio:

warning

It has all the benefits of the embedded comment – it’s close to the code that needs to be changed - but will also show up as a list which will be in-your-face every time you build. I’ll try that out, and see how that goes, and what stays in the todo.txt!

Comments

12/30/2010 8:50:25 AM #

Jerry McGahan

I've used Visual Studio 2008 for programing in Visual Basic.  Its a pretty good environment in that it give you a lot of support.  In terms of getting yourself to go back and fix the code you wrote for me the low tech paper calendar works best.  The way I've worked successfully in the past was Monday program, Tuesday review commented code and revise.  And I even post on my paper calendar that shows someone skiing down the mountain approximate time for example 7am to 9:30am.  For me it helps if I have a calendar with a fun looking picture because of the promise that after I finish there is the possiblity of something fun to do.  Now obviously I'm not a professional programer because if was I wouldn't be able to just take off and schedual my day as I liked.  However, you can get a lot more done in a short time if you remember to give yourself a start and finish time and then a plan for something fun.  No amount of technology is going to get to you look at that code if its all work and no play.  

Jerry McGahan United States | Reply

Add comment




  Country flag

biuquote
  • Comment
  • Preview
Loading



Comments

Comment RSS