4 ms·

Overly long function names and lazy symbols, fair enough. Linter violations, Im not sure sure, standardised code style is most important when working in a team,

Overly long function names and lazy symbols, fair enough. Linter violations, Im not sure sure, standardised code style is most important when working in a team, working on your own it doesnt really matter as much, but fine. Lack of tests, theres no way I'm writing tests for a fun weekend project not meant for production. I'm not even sure I'd write tests for any project not meant for production or anyone elses uses (obviously what production is in that context differs, if your writing a library for dev tooling, their dev is your production). As for "reinventing the wheel", this overuse and overdependence on hundreds of libraries is how we as an industry keep running into the same old issues, so I'd quite happily reinvent the wheel for production. I'm not adverse to libraries, but they shouldnt be approached as a first resort. I'm just glad I don't have my github on my CV

mikepurvis 4y ago
> I'm not even sure I'd write tests for any project not meant for production or anyone else's use See that's interesting— I'm far from a testing-absolutist, and I agree with the basic premise here that there's no point having an elaborate "testing" strategy for a one-off script, stuff that isn't very branchy, etc. However, there's also some stuff that I basically always write a trivial unit test for, assuming the language is set up to allow me to do so cheaply. Obvious examples of this include any kind of string processing, parsing, or regex-type logic— I'm just like, this looks fragile, and I'd like to know for me that it does what I think it does and I'm not going to be tripped up later by some subtle bug that boiled down to an edge case in this particular piece of trivially-isolated and testable logic.
- bodge5000 4y ago
  Yeh, that makes sense, I just doubt I'd even think to add unit tests for a quick and done project. Even if it did cross my mind, I think I'd just add exceptions and print statements. Its dirty, but its also very quick and painless. Then again, I haven't used unit tests much at all in any language other than Python (maybe a few others, but not for some time certainly), maybe other languages make it much easier.

mikepurvis 4y ago

> I'm not even sure I'd write tests for any project not meant for production or anyone else's use See that's interesting— I'm far from a testing-absolutist, and I agree with the basic premise here that there's no point having an elaborate "testing" strategy for a one-off script, stuff that isn't very branchy, etc. However, there's also some stuff that I basically always write a trivial unit test for, assuming the language is set up to allow me to do so cheaply. Obvious examples of this include any kind of string processing, parsing, or regex-type logic— I'm just like, this looks fragile, and I'd like to know for me that it does what I think it does and I'm not going to be tripped up later by some subtle bug that boiled down to an edge case in this particular piece of trivially-isolated and testable logic.

bodge5000 4y ago
Yeh, that makes sense, I just doubt I'd even think to add unit tests for a quick and done project. Even if it did cross my mind, I think I'd just add exceptions and print statements. Its dirty, but its also very quick and painless. Then again, I haven't used unit tests much at all in any language other than Python (maybe a few others, but not for some time certainly), maybe other languages make it much easier.