this post was submitted on 14 May 2024
35 points (90.7% liked)
Programming
17534 readers
105 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 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't really get the code point. Like your own code written for personal projects is probably gonna be pretty high quality I'd hope? Sometimes we just write trash to get something finished but soon as I've had to change it... hell yeah I'm unfucking that mess, no way do I want to figure out what it does a second time.
Does every experiment have to be formatted by a code-formatter, linted, 100% code coverage, unit, integration, and e2e tests, have full CICD, an expansive README, documentation, a project board, milestones, be published on package repositories, and a homepage? Does every post you make on the internet have references, perfect grammar, a well thought out point, and can be ready to be published in your field of work?
Anti Commercial-AI license
Um what? I didn't like hide extra meaning in what I said. High quality code doesn't imply all that extra shit you added. It's code that's easy to read and modify. Typically this just means you name stuff well and document things that aren't obvious. Usually my docs explain why something exists since thinking it's unnecessary cause you don't remember what the original problem was a common occurrence before I started doing so.
Is high quality code ran through a formatter? I'd hope so yeah. There should be a consistent code style across the entire project. Doesn't matter what it it long as it's consistent.
100% code coverage is meaningless and as such a pointless metric. Also 100% coverage is explicitly tied to the implimentaion as all code paths have to be reached which is obviously not a good idea (tests have to change when the implimentaion changes as you're testing the implimentaion not the api).
Really a lot of this is just meaningless buzz words as an attempt at some sort of gotcha. Really don't understand how you even interpreted a statement so simple in this way.