this post was submitted on 21 Jun 2023
110 points (100.0% liked)

Programming

17659 readers
129 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago
MODERATORS
snowe
Ategon
[email protected]
110
The Grand Unified Theory of Documentation (AKA: Your project needs all 4 types or you have bad documentation) (documentation.divio.com)
submitted 2 years ago by spartanatreyu to c/programming
17 comments fedilink hide all child comments
 

The mistake most devs make when trying to document their project is that they only make one (maybe two) types of documentation based on a readme template and/or what their mental model of a newcomer needs.

Devs need to be actively taught that:

  1. Good documentation isn't one thing, it's four. To have good documentation, you need all four distinct types of documentation.
  2. What the four types of documentation are (this is discussed in the link)

If you don't have all four types of documentation, you have bad documentation.

you are viewing a single comment's thread
view the rest of the comments
[–] Insanity 2 points 2 years ago

Another key point for code documentation is that the closer it is to the code it's describing, the more likely it is to be read and maintained.

I agree with this point and it's one I've always had problems with as a lot of developers seem to dislike code comments. I agree that comments shouldn't become a crutch of bad code but good, well formatted documentation on a class or group of functions which explains their usage in relation to the product or feature they support are extremely useful and much more likely to be read by engineers than some documentation written on a notion page somewhere.