Venkat joined a new team in the middle of a big refactoring effort. The code was quite a mess, glued together by long Python scripts with main functions longer than a Tolstoy novel. It was this effort to clean up the code into neat modules that highlighted some logical issues with their implementation.

 def generate_random_number():
 """ Generate a 5 digit random number.
 """
    return "".join(map(str, random.sample(range(0,10),5)))

We were just discussing TODO comments recently, and that motivated Bernard to send us this representative comment..

  // TODO: This method should ideally be in tax frame work but due to
  // the time constraint I am duplicating the code here.
  // Needs to be refactored. Oct 28, 03.

Foreign keys are an important part of making sure the entities in our relational database can be connected back together and queried correctly. It's part of proper data normalization. This isn't shocking, of course: the order line table has a foreign key over to the products table, so that every line item points to a product we sell. That's database 101. Database 201, you'd also think about the times where you have a hierarchy of records, where say, every Employee has a ManagerId, which is a foreign key back to the Employee table itself (and in database 301, you'll understand why having a ManagerId field is a terrible choice, but that's neither here nor there).

The important thing here is that foreign keys are very common, and foreign keys pointing back to the same table are also very common.

When writing Perl, it's not unusual to want to die. The die function ends your Perl program with an error string, and you'll often see code like: die "My error" unless $i > 5 or die "Other error" if check(), because Perl just loves the backwards conditionals. What's even more fun with die is how it behaves with eval blocks, so it doesn't always kill your program, sometimes it is how you pass error strings back out of sections of your program.

And poor Bobby has inherited some Perl that just really loves to die.

"TODO" comments are an inescapable part of our work. Yes, yes, you should just do it right the first time, everything should probably have a ticket in whatever your ticket system is for visibility, but at some point, you're just going to leave a "TODO" behind.

But hopefully, the TODO gets TODONE, which is not what happened in Sam C's codebase.