4 ms·

I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, b

I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable. If your code is correct but unreadable or disorganized, it will be hard to extend. If your code is incorrect, but organized and readable, it will be easy to fix. If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable. If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. And code is always incorrect.

dataflow 4y ago
> If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state. > And code is always incorrect. This makes a strawman of my argument.
- mtVessel 4y ago
  > 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

> If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state. > And code is always incorrect. This makes a strawman of my argument.

mtVessel 4y ago
> 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.