5 ms·
Imagine if we had a metric of "how easy is the code to understand and work with" rather than "can we do it with less lines of code".
by deeviant 5y ago
Imagine if we had a metric of "how easy is the code to understand and work with" rather than "can we do it with less lines of code".
- watermelon0 5y agoThose two are not exclusive.
- all2 5y agoI've gotten to a place where I start with a sketch of how I think my code ought to be used and then work backward into the implementation. So far I've gotten a lot of pushback from others on my team. And, what starts as "oh, you should just have to ____" gets really messy as the implementation takes shape.
- pdimitar 5y agoSo test-driven development (where you write the user -- the test -- first, and then the implementation)?
- all2 5y agoI think so, yes. But I start "before" the test? I write a use-case. Almost a user story, but in code. Sometimes I add comments inline with the code to try and sort out what abstractions are useful.
- pdimitar 5y agoStill TDD, this could fall under the use of Cucumber where the integration test DSL reads almost like English. So kudos to you for using good practices.
- hinkley 5y agoI think that's where people swing back to DAMP, or at least the rule of 3. I'm not trying to fractally compress my code. I'm trying to make it succinct. Those two things are very different. Now if I could only convince a particular coworker of that...
- pdimitar 5y agoI think every good programmer has these rules of thumb, from most important to less important: 1. Make it so you'll understand it in 2 minutes after being away for a year. Positive side effect: it's very readable for your colleagues. 2. Make it brief. 3. Make it fast. 4. Make it pretty (although often times readable + brief code is pretty but obviously it's subjective).