Code Clean Outcomes

Debuggable Code

• You should write your code with the idea that you might one day attach a debugger.
• You may use more temporary variables so that you don’t have to dig through a structure.

Loggable Code

• Your code may run somewhere else; it may be serverless, multithreaded, distributed, or run on a cloud somewhere.
• So, you’ll need a log, which means you need a logging framework.

Testable Code

• Testable software is broken down into readable functions that do simple, verifiable things.
• Testable software works better and is more resilient.

Fast-Failable Code

• The biggest warning sign for unreliable code is a line of code like **if (myvar == null) myvar ="";**.
  • The developer who wrote this line has led you down the path to intermittent behavior.
• If something “can’t happen,” then it should not happen.
  • The code should exit with a big fat error message when it does.
  • It is ugly, but it means the problem will be fixed and not cause any more problems downstream.

Idempotent Code

• It means “if you do this again it won’t matter”.
  • While not everything can be idempotent, anything that can be should be.
• If you refresh a commerce page, you shouldn’t end up with two orders.
• When you change a line in the debugger and see if that fixes the problem so the debugger returns to the beginning of the routine, it will all work out okay.

Immutable Code

• It means when you have a piece of data, it gets assigned once and then changes, resulting in a new data structure.
• Immutable code is more resilient and avoids all kinds of issues.