Welcome to Part 2 of this review of the Pluralsight course Clean Code: Writing Code for Humans by Cory House.
Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker. He believes in clean code, pragmatic development, and responsive native UIs.
Here are the links to each part in this series:
Part 1 – Writing Code For Humans
Part 2 – Clean Code Principles
Part 4 – Clean Code Conditionals
In this episode, we review the Principles of Clean Code.
Principles
Three Core Principles
Cory describes the three core principles of clean code. The first one is…
The Right Tool for The Job
All developers have their favorite tools, but a common mistake is for developers to get carried away and use their new toy in situations that aren’t appropriate.
Here Cory illustrates this with a time that he “creatively” used the wrong tool for the job.
Boundaries Matter: Stay Native
Cory discusses the boundaries between HTML, CSS, JS, server side languages (Ruby/C#/Python) and SQL. It explains the need to stay within them, and the price that you pay if you don’t.
I know that Cory has since slightly revised his opinion on the boundary between JS and HTML, a hell of a lot has happened on the client in the past 3 years.
But the key points here remain. Stay within your boundaries, understand where they are and respect them.
Cory gives 7 advantages for staying native.
Potential Evil
Here Cory gives three examples of useful technologies that turn evil when they are used beyond the area where they were originally designed to be used for.
There are many more examples that you should be able to think of. Be aware of the area where any particular technology is strong and stay within it. I think that this is an extremely important point.
Signal to Noise Ratio
Cory explains TED as an acronym for signal (good) and tells us that there are many bad practices that contribute to noise.
DRY Principle
Don’t Repeat Yourself. The point that I most strongly agree with here is that copy and paste is often a design problem.
Cory discusses some issues that duplication creates.
Self-documenting Code
A study that was done way back in 1979 but remains true today found:
“Understanding the original programmers intent is the most difficult problem” Fjelstad & Hamlen
Cory describes four core things that self-documenting code strives for.
