4 ms·

> The state you want to reach is "fixed", not merely "fixable". And my argument is that readable code is the most direct route to that state. > > And code is

> The state you want to reach is "fixed", not merely "fixable". And my argument is that readable code is the most direct route to that state. > > And code is always incorrect. > This makes a strawman of my argument. It would if it was actually part of my argument, and not a cheeky parting shot. Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.

dataflow 4y ago
> And my argument is that readable code is the most direct route to that state. Which has absolutely nothing to do with my point. Nobody is arguing whether you should keep your codebase readable. The question is whether that should be prioritized over correctness. The situation is: your codebase is already as readable as possible, but you've now discovered a problem for which you're failing to come up with a readable solutions. [1] I'm saying, when that happens, you need to be willing to just bite the darn bullet and go with the ugly-but-correct solution so that your customers actually get their problems addressed. Don't just leave it as a dangling "known issue" or leave some silly hack in there just to "keep the code readable". Your customers/users won't applaud you for keeping your buggy codebase readable. Of course you can feel free to make a ticket or leave a TODO in case you're hitting a blind spot or someone better comes along in the future. But for now, solve the dang problem first, because your customer isn't paying you for source code, but for the end product. (Well, unless your customer is paying you to ship source code to them, in which case you should ignore me.) [1] To be crystal clear (and hopefully avoid more strawmen...), I'm saying you (and your team/company/etc. as applicable) need to actually do your best to implement a readable solution first, and THEN fall back to an unreadable one if you fail to do that despite your bona-fide attempts. For some reason (maybe it makes it easier to argue over the internet? maybe it's just more convenient?) people love to strawman "you should prioritize correctness over readability" as "you should go with the first solution you like whether or not it's ugly; feel free to leave a TODO for some poor soul to polish it later". Which has emphatically never been what I've been saying, but that's what people appear to respond to.
- mtVessel 4y ago
  It feels like your argument is a bit of a strawman itself. I'm hard-pressed to come up with a situation where the code is broken but readable, and the quickest way to fix it is to make it less so. Sure, there are times when I don't know or don't have the time to come up with the best structured solution, but have to put something out there that just works. I would argue that's where you should strive to make it even more readable, because the uncertainty means the odds of having to revisit it later are even greater.

dataflow 4y ago

> And my argument is that readable code is the most direct route to that state. Which has absolutely nothing to do with my point. Nobody is arguing whether you should keep your codebase readable. The question is whether that should be prioritized over correctness. The situation is: your codebase is already as readable as possible, but you've now discovered a problem for which you're failing to come up with a readable solutions. [1] I'm saying, when that happens, you need to be willing to just bite the darn bullet and go with the ugly-but-correct solution so that your customers actually get their problems addressed. Don't just leave it as a dangling "known issue" or leave some silly hack in there just to "keep the code readable". Your customers/users won't applaud you for keeping your buggy codebase readable. Of course you can feel free to make a ticket or leave a TODO in case you're hitting a blind spot or someone better comes along in the future. But for now, solve the dang problem first, because your customer isn't paying you for source code, but for the end product. (Well, unless your customer is paying you to ship source code to them, in which case you should ignore me.) [1] To be crystal clear (and hopefully avoid more strawmen...), I'm saying you (and your team/company/etc. as applicable) need to actually do your best to implement a readable solution first, and THEN fall back to an unreadable one if you fail to do that despite your bona-fide attempts. For some reason (maybe it makes it easier to argue over the internet? maybe it's just more convenient?) people love to strawman "you should prioritize correctness over readability" as "you should go with the first solution you like whether or not it's ugly; feel free to leave a TODO for some poor soul to polish it later". Which has emphatically never been what I've been saying, but that's what people appear to respond to.

mtVessel 4y ago
It feels like your argument is a bit of a strawman itself. I'm hard-pressed to come up with a situation where the code is broken but readable, and the quickest way to fix it is to make it less so. Sure, there are times when I don't know or don't have the time to come up with the best structured solution, but have to put something out there that just works. I would argue that's where you should strive to make it even more readable, because the uncertainty means the odds of having to revisit it later are even greater.