Know Your Falsehoods
| | class NameTag { |
| | |
| | final String name; |
| | |
| | NameTag(String fullName) { |
| » | this.name = parse(fullName).toUpperCase(); |
| | } |
| | |
| | String parse(String fullName) { |
| | String[] components = fullName.split("[,| ]"); |
| | if (components == null || components.length < 2) { |
| | return fullName; |
| | } |
| | if (fullName.contains(",")) { |
| | return components[0]; |
| | } else { |
| | return components[components.length - 1]; |
| | } |
| | } |
| | } |
We’d like to end the book with a peculiar comparison. No matter what domain you’re in, your code’s just as good as your understanding of the real world and no better. And the real world is complex. That’s why you shouldn’t assume too much and make your code flexible to cope with being proven wrong.
The code above shows a NameTag class that takes the full name of a person and transforms it into a specific format for name tags. For example, “Neil Alden Armstrong” gets the name tag “ARMSTRONG.” We’re assuming that full names are provided in a regular format, separated by either a whitespace or a comma. That’s either with first and second names before the last name, or the inverse, the last name before the first separated with a comma.
A lot of the assumptions in this format will break easily. The name of the second man on the moon is “Edwin Eugene Aldrin, Jr.” Here, our algorithm returns “EDWIN,” which is his first name. Names are complicated, and there are many more things that can go wrong. Take a look at this table:
Name | Computed Tag | Expected Tag | Correct? |
|---|---|---|---|
Neil Alden Armstrong | ARMSTRONG | ARMSTRONG | ✓ |
Edwin Eugene Aldrin, Jr. | EDWIN | ALDRIN | ✗ |
費俊龍 | 費俊龍 | 費 | ✗ |
So what should we do when our assumptions are proven to be false?
| | class NameTag { |
| | |
| | final String name; |
| | |
| | NameTag(String name) { |
| » | Objects.requireNonNull(name); |
| » | this.name = name; |
| | } |
| | } |
Starting out with the table, we can build unit tests and code a solution for those names. But this is just a small sample of a few ways to spell out or format names, and it might well be incomplete. In a realistic setting, you’ll have many more combinations and many that haven’t been spelled out.
There’s a simpler and better solution to all of this. You shouldn’t assume too much in your code and just pass that task to the user of the class. Let her set the name tag directly and accept any valid non-null String as a tag name. After all, if you don’t know too much about a format, it’s best to assume as little as possible.
That might seem strange. But have a look at the overview of personal names around the world by the W3C.[70] Names can be complicated indeed. Every culture has its own ways (yes, multiple ones!) of writing names. Without any context, it’s impossible to determine which part of a name is the last name.
Some names, even simple ones, are special in other ways, and that can cause problems. Look at the case of Christopher Null[71] whose last name is, well, “Null”—something that prevents him from submitting a lot of forms in the web. Some frameworks and programs interpret his name as a null reference—and prevent this poor guy from entering his name into forms.
But the list of falsehoods[72] doesn’t stop here. Email addresses, postal codes, CSV files, and our favorite: time zones. It’s an incredibly challenging task to correctly calculate the difference in minutes between two localized daytimes.
The point is to make you aware that you should be careful with assumptions when you program. In theory, they may seem fine. But they often break in practice. Always think twice before you let your code be guided by sheer assumptions to make your code ready for the real world!