Writing Impervious Code: Proper Use of If‑Else, Error Handling, Null Safety, and Avoiding Over‑Engineering

In the first part the author advocates always writing if statements with both a true and a false branch to guarantee that every possible case is handled, showing a typical nested‑if example:

if (...) {
  if (...) {
    ...
    return false;
  } else {
    return true;
  }
} else if (...) {
  ...
  return false;
} else {
  return true;
}

He then demonstrates a common shortcut where developers omit some else branches, which leads to “spaghetti code” that is hard to reason about:

if (...) {
  if (...) {
    ...
    return false;
  }
} else if (...) {
  ...
  return false;
}
return true;

Using a concrete Java example, he shows the danger of relying on a default return value after a missing else and contrasts it with a clearer version that explicitly sets the variable in both branches:

String s;
if (x < 5) {
  s = "ok";
} else {
  s = "";
}

He also presents the ternary form for simple cases:

String s = x < 5 ? "ok" : "";

The second section moves to error handling, reminding readers to always check function return values (e.g., Unix read returns –1 on error) and to treat exceptions as part of a function’s “union type”. An example of a method that can throw is shown:

String foo() throws MyException {
  ...
}

He warns against catching the generic Exception and discarding it:

try {
  foo();
} catch (Exception e) {}

Instead, he recommends catching the specific exception type and keeping each try / catch block small and isolated:

try {
  foo();
} catch (A e) { ... }
try {
  bar();
} catch (A e) { ... }

The third part focuses on null‑pointer safety. He explains why many languages treat null as a design mistake and proposes principles such as never returning null for error cases, using exceptions or optional types instead, and avoiding putting null into collections.

public static
T requireNonNull(T obj) {
  if (obj == null) {
    throw new NullPointerException();
  } else {
    return obj;
  }
}

He illustrates the use of Java’s Optional and Swift’s optional binding to make null checks atomic:

let found = find()
if let content = found {
  print("found: " + content)
}

Optional
found = find();
found.ifPresent(content -> System.out.println("found: " + content));

He notes the limitations of Java’s Optional compared with Swift’s more ergonomic syntax.

The final section warns against over‑engineering, listing signals such as premature concern for future scalability, excessive reuse abstractions, and over‑testing, and provides three practical principles: solve the immediate problem first, write simple usable code before refactoring for reuse, and keep code simple and obviously bug‑free before adding extensive tests.