100 Tips to Write Clean Code

Clean Functions, Classes, Comments, Commits and everything you need to write Clean Code

CodeRabbit: Free AI Code Reviews in CLI (Sponsor)

Get Started Today

CodeRabbit CLI is an AI code review tool that runs directly in your terminal. It provides intelligent code analysis, catches issues early, and integrates seamlessly with AI coding agents like Claude Code, Codex CLI, Cursor CLI, and Gemini to ensure your code is production-ready before it ships.

• Enables pre-commit reviews of both staged and unstaged changes, creating a multi-layered review process.

• Fits into existing Git workflows. Review uncommitted changes, staged files, specific commits, or entire branches without disrupting your current development process.

• Reviews specific files, directories, uncommitted changes, staged changes, or entire commits based on your needs.

• Supports programming languages including JavaScript, TypeScript, Python, Java, C#, C++, Ruby, Rust, Go, PHP, and more.

• Offers free AI code reviews with rate limits so developers can experience senior-level reviews at no cost.

• Flags hallucinations, code smells, security issues, and performance problems.

Supports guidelines for other AI generators, AST Grep rules, and path-based instructions.

Get Started Today

Motivation

Every developer can write working code.
But not every developer can write clean code.

Clean code is code that:

• tells the story of the business,

• can be read like prose,

• and can be changed with confidence.

Over the years, I’ve collected 100 practical tips that help you craft better software that doesn’t just work today, but stays readable, testable, and maintainable for years.

Here’s the full list 👇

✨ Clean Namings

1. Use intention-revealing names

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 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 names should be adjectives

14. Class names should be nouns or noun-phrases

    

⚡ Clean Functions

15. Function names should be verbs or verb-phrases

16. Keep functions small and concise

17. Avoid too many function arguments

18. Max number of lines in a function: 8–10

19. Avoid passing booleans as parameters

20. Strive for no side effects

21. Use enums as flags

22. Use empty lines to separate logic

23. If it takes more than 3 seconds to figure out what a function does, refactor it

🏗 Clean Classes

24. A class should have only one main responsibility

25. Avoid large classes (~100+ lines can be a smell)

26. Strive for one public function per class

27. Create small private functions for single tasks

28. Order functions based on execution flow

💬 Clean Comments

29. Avoid comments as much as possible

30. Don’t state the obvious

31. Don’t use them extensively (nobody will read them)

32. Replace comments with good naming

33. Use comments only for explaining why

34. Use comments for revealing implicit behavior

35. Use comments for API doc generation\

✅ Clean Tests

36. Use descriptive test names (scenario-based)

37. Use Given/When/Then or Should/When templates

38. Structure tests with Arrange / Act / Assert

39. Avoid logic (if, for, while) in tests

40. Couple a test with one behavior

41. Use meaningful test data

42. Hide irrelevant test data

43. Write clean assertions that describe domain behaviors

44. Create deterministic tests

45. Remove duplication with parameterized tests

46. Prefer fakes for mocking out 3rd party code

🔑 F.I.R.S.T Principle for Tests

47. Tests should be fast

48. Tests should be independent

49. Tests should be repeatable

50. Tests should be self-validating

51. Tests should be thorough (happy paths, edge cases, negative cases, security, illegal input)

🔀 Git Commits

52. Commit early & push often

53. Write meaningful commit messages explaining the reason

54. Use the imperative mood in commit messages

55. Use present tense

56. Add a link reference to the related story, task, or bug

🕳 Code Smells

57. Avoid magic numbers

58. Avoid magic strings

59. Avoid long conditions

60. Avoid global variables

61. Avoid long parameter lists

62. Don’t overuse primitives — model your domain with rich types

63. Avoid deeply nested logic

64. Reduce cyclomatic complexity

65. Hard-to-test logic is a smell to fix

🎨 Formatting

66. Set up team standards

67. Use automated formatters

68. Set a max width for lines

69. Don’t use horizontal alignment

70. Don’t break indentation

71. Declare variables close to their usage

📐 Core Principles

72. Don't repeat yourself (DRY): remove knowledge duplication

73. Keep it simple (KISS): simple code beats both complex and clever code

74. You ain't gonna need it (YAGNI): don't produce code that is not needed in your current context

75. Tell, don't ask: bundle data and functions together

76. Single Responsibility Principle (SRP): organize logic into modules with one reason to change

77. Liskov Substitution Principle (LSP): a subtype should be able to replace its base type without altering the program

78. Interface Segregation Principle (ISP): split large interfaces into small and more specific ones

79. Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules. Both should depend on abstractions.

80. Favor composition over inheritance: inheritance leads to tight coupling, composition gives more flexibility

81. Divide and Conquer: break down a problem into smaller sizes to manage complexity

82. High cohesion: group related code together. It helps you to find logic easier and makes your code easy to maintain

83. 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

84. Use a solid IDE with refactoring tools

85. Master your IDE hotkeys

86. Use feature-based folder structure

87. Pair programming helps keep code clean

88. Delete unused code — it’s a liability

89. Write code for humans, not just machines

90. Readability > cleverness

91. Favor readability over efficiency

92. Always leave the code cleaner than you found it

93. Test early, test often

94. Refactor early, refactor often

95. Do real-time code reviews instead of just PR reviews

96. Use the “rule of three” to remove duplication

97. Avoid using NULL — it’s a code smell

98. Working code ≠ clean code

99. You can’t have clean code without tests

100. Write code that reads like well-written prose

Conclusion

Clean code is not a checklist. It’s a mindset.

It’s the discipline of choosing clarity over cleverness.
It’s the habit of leaving the codebase better than you found it.
It’s the commitment to future teammates, and to your future self.

Because in the end:

Working code delivers features.

Clean Code builds lasting software.