Clean Code
0 likes19 views
The document outlines principles of clean code, emphasizing the importance of meaningful naming, method structure, error handling, and the use of tests. Key practices include avoiding magic numbers, keeping methods small and focused, ensuring clear documentation, and maintaining proper abstraction. It highlights the significance of code formatting and separation of concerns for efficient code maintenance.
![NO MAGIC NUMBERS
public List<int[]> getList(List<int[]> inputList) {
List<int[]> tempList = new ArrayList<>();
for (int[] x : inputList)
if (x[0] == 4) tempList.add(x);
return tempList;
}
6](https://image.slidesharecdn.com/5-161116070218/85/Clean-Code-6-320.jpg?cb=1726174006)
![NO MAGIC NUMBERS CONTD
public List<int[]> getFlaggedCells(List<int[]> gameBoard) {
List<int[]> flaggedCells = new ArrayList<>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
7](https://image.slidesharecdn.com/5-161116070218/85/Clean-Code-7-320.jpg?cb=1726174006)
Clean Code
- 2. WHAT IS CLEAN CODE I like my code to be elegant and efficient, The logic should be straightforward to make it hard for bugs to hide, The dependencies minimal to ease maintenance, Error handling is complete, Clean code does one thing well. Bjarne Stroustrup 2
- 3. MEANINGFUL NAMES int i; What is i? int elapsedTime; Now we know it is an integer indicating elapsed time. But what time? Seconds, years what? int elapsedTimeInDays Better? int elapsedTimeInDaysSinceRestart 3
- 4. MEANINGFUL NAMES controllerForEfficientHandlingOfStrings controllerForEfficientStorageOfStrings Frightfully similar int a = l; if ( O == 0 ){ a = O; } Not very clear? 4
- 5. MEANINGFUL NAMES Names with similar meaning accountData vs account customerInfo vs customer Variable names should be pronounceable dtValFmtddmmyy dateValueFormattedAsddmmyy Use searchable names If you have to search a variable named a 5
- 6. NO MAGIC NUMBERS public List<int[]> getList(List<int[]> inputList) { List<int[]> tempList = new ArrayList<>(); for (int[] x : inputList) if (x[0] == 4) tempList.add(x); return tempList; } 6
- 7. NO MAGIC NUMBERS CONTD public List<int[]> getFlaggedCells(List<int[]> gameBoard) { List<int[]> flaggedCells = new ArrayList<>(); for (int[] cell : gameBoard) if (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell); return flaggedCells; } 7
- 8. METHODS Method name must be verb One name per concept Fetch, retrieve, get Do not add too much context Prefixing everything with application name Must always return value Should not have side effects 8
- 9. METHODS CONTD Keep methods small Make sure it does one thing Niladic, monadic and dyadic Triadic is so evil, try enclosing in a class if really required So are flag arguments, It means method does more than one thing 9
- 10. FUNCTIONS CONTD Command query separation Method should do something or answer something but not both Prefer exceptions to returning error codes Violate the command query separation The error codes class is dependency magnet 10
- 11. WORDS OF WISDOM Every function, and every block within a function, should have one entry and one exit. Means that there should only be one return statement in a function, no break or continue statements in a loop, and never, ever, any goto statements. Dijkstra 11
- 12. COMMENTS What would you prefer? // Check if employee is eligible for full benefits if (employee.flag && employee.age > 65) Or if (employee.isEligibleForFullBenefits()) 12
- 13. COMMENTS Do not comment bad code, rewrite it, refactor it Kernighan If your code can not reveal its intention then the comments shall neither. The comments are seldom maintained Comments clutter the code TODO comments 13
- 14. FORMATTING Is as important as the code itself Should be standardized for a project The old Hollerith limit of 80 is a bit old 14
- 15. ABSTRACTION Do not blindly create getters and setters Understand when to use Procedural Object oriented DTOs do nothing more than to duplicate code 15
- 16. ERROR HANDLING Use informative error messages Do not catch and re-throw Use exceptions rather than error codes Write try-catch-finally in separate function? Checked vs Unchecked exceptions? Violates open closed principle 16
- 17. TESTS F.I.R.S.T. principle Tests must be uniquely named Given-When-Then One assert per test Okay to make a function protected to test Generally not required if the functions are small 17
- 18. CLASSES Single Responsibility Principle Too many classes Look for cohesion Dependency Inversion Principle Enums vs constants Do not inherit constants 18
- 19. SYSTEM Object creation should be separated from business logic Dependency Injection, Factories Cross cutting concerns Business logic should be separate from framework related code 19
- 20. SYSTEM Always delete commented code And dead code Building and deploying a system should be one step Should be able to run all tests on local Do not override safeties Maintain separation between layers 20
- 21. QUESTIONS? 21