67
Software Engineering Documentation Best Practice?
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Sep 2024
67 points (100.0% liked)
Programming
17314 readers
64 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 !webdev@programming.dev
founded 1 year ago
MODERATORS
The Code is my Bible.
Yeah seems about right... off the top of my head:
Writings self documenting code is so important.
Comments get stale and over time transition from: accurate to outdated, to eventually flat-out lies.
Go hard in the paint when choosing method or variable names. If it's hard to give them coherent names, that's a code smell.
Sounds like some people aren’t doing their work enough then. Code comments are part of the work that a programmer should do, not an afterthought. Who else is gonna update that code if not the programmer? And if a programmer isn’t supposed to update their code and we can just all write clean code that would somehow make us all be better engineers (yeah, I use this title differently from programmers), then why are code comments even a thing?
Self-documenting code is good and all, but so should there be good comments.
I agree that would be ideal.
I flat out do not trust each of the 500 devs operating on our codebase to maintain comments.
Tests are documentation, code can be documentation. Those run through CI.
If you can keep comments updated at scale, do it. If you can't don't pray for a miracle and find something that you actually can enforce
That’s why reviewers should also watch out for comments to ensure their quality. Hence why I said it’s part of a programmer’s job, not some afterthought.
the output of tools like sphinx, javadoc and so forth is a good starting point, especially if you feed them properly commented code.
the rule "garbage in, garbage out" definitely applirs here.
If it's closed source then it's a losing battle to try and document code. I mean, do it when you feel it's 100% necessary (e.g. complex code that you really can't dumb down, "magic numbers" with a complicated backstory, test cases -- it feels like that's a different part of your brain so the transition is hard). Otherwise write code that almost reads like a sentence and don't add complexity until you need it.
You mean COBOL?
Hehe. COBOL doesn't look too bad. Reads a bit like a person that's never talked to another human being before.