100 tips to write clean code:

I gathered how to write clean code in programming

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:

15. Function names should be verb or verb-phrase

16. Keep a function small and concise

17. Avoid too many function arguments

18. Max number of lines of a function should be 8-10

Clean Functions part 2:

19. Avoid passing boolean as a function parameter

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, then refactor it

Clean Classes:

24. Should have only one main responsibility

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

26. Strive for one public function per class

27. Create small private functions to do single tasks

28. Order your functions based on execution

Clean Comments:

29. Avoid comments as much as possible

30. Don't state the obvious

31. Don't use them extensively because nobody will read them

32. Replace them with good namings of your software elements

Clean Comments:

33. Use comments only for explaining the why

34. Use comments for revealing implicit behavior

35. Use comments for API doc generation

Clean tests:

36. Use descriptive tests names describing the test scenario

37. Use GivenWhenThen or ShouldWhen naming templates

38. Use Arrange/Act/Assert pattern to structure tests

39. Avoid logic (if, for, and while loops) in test code

40. Couple a test with one behavior

Clean tests part 2:

41. Use meaningful test data

42. Hide irrelevant test data

43. Use clean assertions, describing the domain behaviors

44. Create deterministic tests

45. Remove duplication with parameterized tests

46. Prefer fakes for mocking out 3rd party code

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

47. should be fast

48. should be independent of other tests

49. should be repeatable

50. should be self-validating

51. should be thorough cover covering all happy paths, edge cases, negative cases, security, and illegal issues

Git commits:

52. Commit early & push often

53. Make your commit messages meaningful, explaining the reason for the change. 54. Use the imperative mood in the commit message

55. Use present tense in the commit message

56. Add link reference to the actual user 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 list

Code smells part 2:

62. Don't be obsessed with primitives. Model your domain with complex types.

63. Avoid deeply nested logic

64. Reduce cyclomatic complexity

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

Formatting:

66. Set up team standards

67. Use automated code formatters

68. Set max width for horizontal formatting

69. Don’t use horizontal alignment.

70. Don't break indentation

71. Variables should be declared close to their usage

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.

84. Use a solid IDE with refactoring functionalities

85. Master your IDE hot keys

86. Use feature based folder structure

87. Work with pair programming, it makes writing clean code easier

88. Delete non used code - code is a liability, not an asset

89. Write code humans to read, and not just for machines to execute

90. Readability > cleverness

91. Favor readability over efficiency

92. Always leave the code a better place behind

93. Test early, test often 94. Refactor early, refactor often

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

96. Use the rule of three to remove duplications

97. Avoid using NULL, it is a code smell

98. Working code != clean code

99. You can't have clean code without tests

100. Write code that reads like a well-written prose