HOW to document business logic in code?

background:

I'm a frontend dev for admin system of our company. Often times I code things like: if user choose this product type and that settings then I show some other input field to input. I deal with mostly forms and show/hide UI for user. And after some time nor did user/PM/test or myself remember the logic of what should show or why something do not show.

So I want something to be able to let me write code and business logic along the way.(I'm not asking for API docs or function docs like JSDoc)

Great Thanks

Related topics:

And In terms of this, I would also like to build something to centralize PM's business DOC with developers API/dev Doc and also things like how to test for our test team and etc... basically a unified place to document everything, I think scenarios like these inside companies should exists so I would like to know how other company do this.

Flowcharts and a fileserver..?

@jonii Well, I think it's too general and not work well with code and testing, may good for PM tho.

Btw, I think I want something like a wiki like wiki.js or something. I just want to know how others do this.

Rant: StackOverflow mark this as Off-Topic :sad:

I just don't document anything in code.

good typing system, proper naming, short non-void functions with 1-2 param each top, and thousands of unit tests with self-explanatory names.

i hate docs/comments in code so much that i set our CI to refuse to build if it spots comments (with very few exceptions like some crappy obscure algorithms that one day we'll refactor).

i believe way more in wikis rather than blocks of green lines in the way

@thatsnotnice Thanks, you seems to be a little bit extreme on it. Yeah, I also believes I need some wiki for my project, so how do you implement your wikis? Any suggestions?

@thatsnotnice I'm really curios how that looks, because I do flowcharts for more complicated stuff, but along comments in the code and I wouldn't know what to write in a Wiki. I find it complicated to explain something without the code.

Notion.so is pretty neat for a wiki.

back from holidays.. :D

@devOc , eheh yeah indeed. joking aside, i truly try to enforce that approach whenever is -reasonably-possible. especially in projects where me, or my team, have full control. tech stack is of course important too, because if it's true that this approach is painless on most stateless frontends, the story can be kind of different when working with legacy .net o java for example (another reason why i like writing functional typescript for node.js on backend).

after years, i find easier to reason code thru unit tests rather than comments.

wikis are another story, i use them mostly to help to dive into a project quickly with a precise list of step to follow in order to bootstrap the whole thing, to remember some tricky monkey code parts that may have happened during in the past (this is the only thing that could be an inline TODO in code actually), to document DBs and architecture-level stuff rather than single functions/methods.

@jonii yeah i understand. my opinion is that is a lot about the mindset of the developer. i mean, i like to document such kind of stuff in a very abstract way on a wiki, eventually mentioning some entry points for key parts, and that's it. but that's me, as long as your approach works for you/your team i think it's good anyway.

this is kind of an area where we hardly can say A better than B and viceversa, it involves individual dev attitudes, programming language, framework, tech stack, individual background, code style etc.

these stuff have to work, ofc, but also have to fit