# Clean code checklist

Clean Code Checklist

Use this brief checklist when encountering unfamiliar code or while writing new code.

GENERAL

✓My code reads like a narrative. I write code for humans, not machines. ✓I document my code only when necessary. My code must speak for itself.

✓I provide clear instructions on how to compile and publish my code base. When appropriate, I provide working build scripts/makefiles or CI/CD configuration instructions.

✓I use native functionality rather than implementing my own libraries, unless it is for a very good reason.

✓My code is consistent in its design patterns, documentation, and naming conventions. I don't change things mid-development and go against established patterns.

✓ I have added logging to my application, so I or other developers can debug when things go wrong.

CLASSES

✓ My class has the strictest possible access modifier. ✓ My class is called precisely. ✓ My class performs operations on a single specific object and therefore adheres to the single responsibility principle. ✓ My class lives in the correct folder within my project. ✓ If I have trouble implementing my class, I step back and Propose a brief description of the class and its intended functionality. This refocus can help write cleaner code. If my class must do several things, split it up.

METHODS

✓ My method has the strictest possible access modifier. ✓ My method is named precisely and describes the internal logic correctly (leaving nothing out). ✓ My method performs only one general operation or collects information from other methods related to its operations. It adheres to the single responsibility principle. ✓If my method has a public access modifier, we do not perform any operations within the method. The public method calls other smaller methods and organizes the results. ✓ I have unit tests that support my method. Unit tests should cover the main logical branches of success and failure.

VARIABLES, FIELDS AND PROPERTIES (VFP).

✓ My VFP types are of the most abstract type possible. If you can use an interface instead of a concrete type, use the interface. This promotes polymorphism and the use of Liskov's substitution principle. ✓ I have no "magic number" assigned to a variable. ✓ Whenever possible, I restrict my VFPs to the strictest possible access modifier. If aVFP can be made read-only, I make it read-only. If aVFP can be made a constant, I make it a constant. ✓ I always validate my input arguments. This protects me against unwanted null pointer exceptions and operating on data in an invalid state. ✓I use enumerations and constants instead of string literals when appropriate.

TEST

✓ I always provide appropriate unit tests for my code. ✓ I follow test-driven development whenever possible. ✓ I am not focused on code coverage. My goal in testing is to protect against unexpected side effects and to validate my assumptions about requirements and existing code. ✓If one of my changes breaks a test, I fix it. ✓ I always write the least amount of code necessary to satisfy all tests. Any extraneous lines increase the amount of code to maintain.