3 ms·

- Which problem will be solved by the software - What is the system's context - How to Build - How to Run The rest is in the code. And 80% of all »projects« la

• jnxx 7y ago
  > The rest is in the code. I know that philosophy well, but I do not really agree with it - not at all. For example in concurrent code written in C, the way things are synchronized is normally implicit. You can understand it if you read all of the code, but not by looking at single functions. If you add accesses without proper synchronization, you will get quickly undefined behaviour which can cause extremely nasty concurrency bugs. I also agree with the several comments made that it is often more helpful "why" something is done, than "how". This is, of course, valid for in-code comments as well, but IMO equally important in overview documentation. > And 80% of all »projects« lack at least one of the points above. Yeah, I know. In fact, I have rarely seen good technical documentation.