🏁
Best Practices
  • Introduction
  • The Big Picture
    • Principles
      • Software engineers solve business problems
      • Programming is a social activity
      • Attention is the most precious resource in a project
      • Simplicity is the best ally in the long run
      • The only problem to solve is the one we have today
    • Architecture
      • Domain
      • Services
      • Persistence
      • HTTP
      • UI
    • Naming
  • Constraints
    • TypeScript
    • Monorepo
    • Monolith
    • Versioning
  • Source code
    • Declarative programming
    • The README
    • Modules
    • Folder structure
    • Code formatting
    • Code comments
  • The Outside World
    • Runtime configuration
    • Logging
  • Testing
    • The purpose of testing
      • End-to-end tests
      • Integration tests
      • Unit tests
  • Tools
    • Git
  • Resources
    • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Source code

Code comments

PreviousCode formattingNextRuntime configuration

Last updated 5 years ago

Was this helpful?

You don't need comments in the code.

Shapes, classes, call signatures are . Clear names explain what is what. is easy to read and reveal the flow of control and data without the prose.

There is always a better way, then adding comments. Comments rarely solve problems.

The only exception to this rule is to add comments to a piece of code that is unexpected or misleading but not fixable for technical reasons (for example it's 3rd party API). If it's your code, fix it.

Not writing comments doesn't mean you don't share in its appropriate place.

self-documenting in TypeScript
Declarative code
helpful information