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

Programming

17435 readers
232 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 1 year 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 1 year 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
[–] ericjmorey 38 points 1 year ago* (last edited 1 year ago) (9 children)

Tutorials

Tutorials are lessons that take the reader by the hand through a series of steps to complete a project of some kind. They are what your project needs in order to show a beginner that they can achieve something with it.

They are wholly learning-oriented, and specifically, they are oriented towards learning how rather than learning that.

How-to guides

How-to guides take the reader through the steps required to solve a real-world problem.

They are recipes, directions to achieve a specific end - for example: how to create a web form; how to plot a three-dimensional data-set; how to enable LDAP authentication.

They are wholly goal-oriented.

Reference guides

Reference guides are technical descriptions of the machinery and how to operate it.

Reference guides have one job only: to describe. They are code-determined, because ultimately that’s what they describe: key classes, functions, APIs, and so they should list things like functions, fields, attributes and methods, and set out how to use them.

Reference material is information-oriented.

Explanation

Explanation, or discussions, clarify and illuminate a particular topic. They broaden the documentation’s coverage of a topic.

They are understanding-oriented.

  • tutorials and how-to guides are both concerned with describing practical steps

  • how-to guides and technical reference are both what we need when we are at work, coding

  • reference guides and explanation are both concerned with theoretical knowledge

  • tutorials and explanation are both most useful when we are studying, rather than actually working

[–] jpfreely 8 points 1 year ago* (last edited 1 year ago) (4 children)

I've had that article saved for years, it's still the best way to break down documentation imo.

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. The book "A philosophy of software design" has a section on it.

[–] ericjmorey 4 points 1 year ago (2 children)

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.

What does this mean?

[–] [email protected] 4 points 1 year ago

I assume with "close" they meant that documentation should be located right there at the code it is documenting. Think Java doc comments (heredoc) or how in Golang you put comments above a function definition which is then automatically turned into documentation.

If documentation is located in an entirely different file, it's easy to modify code and forget to update the corresponding documentation.

load more comments (1 replies)
load more comments (2 replies)
load more comments (6 replies)