Practice 27:tr

Exercise 27: Tr

Translator: Flying Dragon

Protocol: CC BY-NC-SA 4.0

Proudly using Google Translate

This exercise is to continue learning the TDD (also known as “test first”) style of development. Knowing how to program this way is important because it is used in many places, but as mentioned earlier, it has its limitations. You’ll practice using TDD again when you implement tr. Make sure you rigorously write tests first, then code, and then audit two things.

In the last exercise, I had you build test cases and code step by step. This is usually the least error-prone development approach, but it doesn’t help you better analyze your own code. In this exercise, you’re going to do something slightly different, because I’m going to write a complete test case, audit it, then write the entire code, audit it, and verify the audit by running the tests.

This means that your flow in this exercise looks like this:

  • Try writing most OF the TDD test cases.
  • Audit the test case and verify that it was written correctly.
  • Run the tests to make sure they fail, but look for any syntax errors. You should have no syntax errors at this point.
  • Write code for test cases, but don’t run tests.
  • Audit your code and try to see how many defects there are before you run the tests.

You’ll use this process in the next exercise to track your auditing skills, measure your testing skills, and gain more control over the way you write code.

Challenge to practice

The TR tool is an effective way to translate streams of characters. Although very simple, it can do some very complicated things with characters. For example, you could use TR to get the frequency of words used in history in one line of code:

history | tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn

Seems cool, but Doug McIlroy once used this line to argue that a similar program written by Donald Knuth was too long. Knuth’s implementation is “10 pages”, building everything from scratch. Doug’s line just uses standard Unix tools to do the same thing. This demonstrates the power of Unix’s plumbing tools and tr’s ability to translate text.

Use the man page and anything else to figure out what TR does. There’s also a Python project with the same name, but I’ll tell you to avoid it until you’re done implementing it, so you can compare this project later. Don’t forget, too, that for this you need an overall project, which should be test-completed TDD style, as I described at the beginning.

45 minutes of criticism

I hope you continue to use 45 minutes, but there’s one big criticism of this way of working: you can’t get into the extended focus flow. Working in short bursts, like this, helps when you need to deal with a lot of work and have to pick up the pace. This happens when work is really boring and not fun. I’m asking you to use 45-minute blocks of time to speed yourself up, but we’ll also use them later to gather some indicators of how you’re working in time for subsequent analysis.

But I will remind you that the best programming is done in a state of concentration. This is when you focus so intensely for a few hours that you lose all sense of time until 5am, when you realize you’ve been through the night. This intense focus makes programming very enjoyable for me, but it’s really sustainable when you’re interested in what you’re doing. This usually doesn’t happen when you need to deal with someone else’s bad code base. In these cases, you need a different strategy to speed up your work and get you out of trouble without losing your fun. That’s what a 45-minute block of time does.

Finally, build your ability to get in the zone and focus for a few hours. One way is to start with short periods and slowly increase them until you can tolerate them for longer periods. Keep using 45 minutes fast, but if you just get carried away and finish the dark magic in the last few hours, have fun. No one will tell you that you did something wrong, which is actually normal.

Inquiry learning

  • How about this way of working? Do you like it? Try to clarify why, and then read some current articles on TDD, or its close cousin, behavior-Driven Development (BDD).

  • Do you think you found more or fewer bugs by auditing your code first rather than building it gradually? Guess it and write it down.