Skip to content

A curated list for awesome tips for Clean Code

Notifications You must be signed in to change notification settings

amanpreet-dev/awesome-tips-for-clean-code

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

Awesome tips for Clean Code

Clean Namings:

  1. Use intention-revealing namings
  2. Capture business knowledge
  3. Avoid encoding and technical details
  4. Use pronounceable names
  5. Use searchable names
  6. Avoid noise and redundant words
  7. Use strong words
  8. Don't use abbreviations
  9. Be consistent with concepts and use the same vocabulary
  10. Use is/has/should/can prefix for booleans
  11. Avoid negative names for booleans
  12. Use naming conventions within your project
  13. Boolean name should be an adjective
  14. Class names should be noun or noun-phrases

Clean Functions:

  1. Function names should be verb or verb-phrase
  2. Keep a function small and concise
  3. Avoid too many function arguments
  4. Max number of lines of a function should be 8-10
  5. Avoid passing boolean as a function parameter
  6. Strive for no side effects.
  7. Use enums as flags
  8. Use empty lines to separate logic
  9. If it takes more than 3 seconds to figure out what a function does, then refactor it

Clean Classes:

  1. Should have only one main responsibility
  2. Avoid large classes (~100 lines of code can be a smell)
  3. Strive for one public function per class
  4. Create small private functions to do single tasks
  5. Order your functions based on execution

Clean Comments:

  1. Avoid comments as much as possible
  2. Don't state the obvious
  3. Don't use them extensively because nobody will read them
  4. Replace them with good namings of your software elements
  5. Use comments only for explaining the why
  6. Use comments for revealing implicit behavior
  7. Use comments for API doc generation

Clean Tests:

  1. Use descriptive tests names describing the test scenario
  2. Use GivenWhenThen or ShouldWhen naming templates
  3. Use Arrange/Act/Assert pattern to structure tests
  4. Avoid logic (if, for, and while loops) in test code
  5. Couple a test with one behavior
  6. Use meaningful test data
  7. Hide irrelevant test data
  8. Use clean assertions, describing the domain behaviors
  9. Create deterministic tests
  10. Remove duplication with parameterized tests
  11. Prefer fakes for mocking out 3rd party code

A test should follow the F.I.R.S.T principle:

  1. should be fast
  2. should be independent of other tests
  3. should be repeatable
  4. should be self-validating
  5. should be thorough cover covering all happy paths, edge cases, negative cases, security, and illegal issues

Git commits:

  1. Commit early & push often
  2. Make your commit messages meaningful, explaining the reason for the change.
  3. Use the imperative mood in the commit message
  4. Use present tense in the commit message
  5. Add link reference to the actual user story, task or bug

Code smells:

  1. Avoid magic numbers
  2. Avoid magic strings
  3. Avoid long conditions
  4. Avoid global variables
  5. Avoid long parameter list
  6. Don't be obsessed with primitives. Model your domain with complex types.
  7. Avoid deeply nested logic
  8. Reduce cyclomatic complexity
  9. Hard-to-test logic is a code smell to fix

Formatting:

  1. Set up team standards
  2. Use automated code formatters
  3. Set max width for horizontal formatting
  4. Don’t use horizontal alignment.
  5. Don't break indentation
  6. Variables should be declared close to their usage

Principles:

  1. Don't repeat yourself (DRY): remove knowledge duplication
  2. Keep it simple (KISS): simple code beats both complex and clever code
  3. You ain't gonna need it (YAGNI): don't produce code that is not needed in your current context
  4. Tell, don't ask: bundle data and functions together
  5. Single Responsibility Principle (SRP): organize logic into modules with one reason to change
  6. Liskov Substitution Principle (LSP): a subtype should be able to replace its base type without altering the program
  7. Interface Segregation Principle (ISP): split large interfaces into small and more specific ones
  8. Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules. Both should depend on abstractions.
  9. Favor composition over inheritance: inheritance leads to tight coupling, composition gives more flexibility
  10. Divide and Conquer: break down a problem into smaller sizes to manage complexity
  11. High cohesion: group related code together. It helps you to find logic easier and makes your code easy to maintain
  12. Low coupling: your modules should independent of other modules. By doing so, you can easier make changes to internals without breaking other modules

Extra tips:

  1. Use a solid IDE with refactoring functionalities
  2. Master your IDE hot keys
  3. Use feature based folder structure
  4. Work with pair programming, it makes writing clean code easier
  5. Delete non used code - code is a liability, not an asset
  6. Write code humans to read, and not just for machines to execute
  7. Readability > cleverness
  8. Favor readability over efficiency
  9. Always leave the code a better place behind
  10. Test early, test often
  11. Refactor early, refactor often
  12. Do code reviews in real-time instead of PR reviews
  13. Use the rule of three to remove duplications
  14. Avoid using NULL, it is a code smell
  15. Working code != clean code
  16. You can't have clean code without tests
  17. Write code that reads like a well-written prose

Source of Reference -

About

A curated list for awesome tips for Clean Code

Topics

Resources

Stars

Watchers

Forks