DEV Community

Discussion on: To TS or not to TS, that is NOT the question. Is it?

 
brense profile image
Rense Bakker

Summary of 'Clean code' by Robert C. Martin:
gist.github.com/wojteklu/73c6914cc...
Comments rules:

  1. Always try to explain yourself in code.
  2. Don't be redundant.
  3. Don't add obvious noise.
  4. Don't use closing brace comments.
  5. Don't comment out code. Just remove.
  6. Use as explanation of intent.
  7. Use as clarification of code.
  8. Use as warning of consequences.

1 through 4 are not met by your JSDoc approach.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

That's clean code by Robert C. Martin, not Code best practices but well.
If you watched the videos from Robert C. Martin you'll notice that it was nice on a different era yet he repeated the same mantra for years.
Nowadays is somewhat utopic and unreallistic. We got devs that came from a 3 months code camp working together with people that completed an engineering plus a master. The amount of projects grow enough to get people working 50%-50% in two projects at once. You work on a project with Angular, then you jump to the next one in React, then the next uses Next Js and the other... as examples.

If you have a team full of senior devs with experience working together, aligned on a single styleguide, with a similar base-knowledge, focused on a single project, stack and environment and you are sure that they are not going to leave the project/company you can avoid comments and expect the code to be self-expanatory.

If one of those requirements is not met, you'll face issues sooner or later.