this post was submitted on 19 Feb 2024
39 points (95.3% liked)
Programming
17378 readers
414 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yea, probably not every language has a concept of unittests, but basically test code.
Like if you have a calculator, there would be a test (outside of the real project) of like
If Calculator.Calculate(2 + 2) then assert outcome = 4
That way - if lets say the calculator only does
+
operations - you could still copy that test line, and create a new test ofIf Calculator.Calculate(5 * 5) then assert outcome = 25
Your test will fail initially, but you can just run through it in a debugger, step into the code, figure out where it's most appropriate to add a
*
operator function, and then implement it, and see your test success.Other benefit of that is that if you submit your change as PR, with the test the repo maintainer doesn't have to determine whether your code actually works just by looks, or actually running the calculator, your test proves you've added something useful that works (and you didn't break the existing tests)
If you're just programming for yourself without the intent to submit it for a PR, you can just throw away the linter file. But I mentioned it was good to have in a project, because if there were multiple people working on it, all with their own style, the code can become a mess quite fast
Well, I mean, that's basically all the things right? You start completely unqualified, mess around for a while, and after a while you're them more-qualified next time...
Just messing around with stuff you like is a good way to learn - though in my experience doing anything with hardware is way more difficult than just plain software. If you have to interface with hardware its very often pretty obscure stuff, like sending the correct hardware instructions to a driver, or to just "hardware pins" even... Like trying to start modifying a driver as a kind of starter project doesn't sound like something I'd recommend