4 ms·

> 4. It significantly reduced time spent refactoring later. The subtleties in some of the points make a re-read valuable as well. One of the better examples of

by barbs 8y ago

> 4. It significantly reduced time spent refactoring later. The subtleties in some of the points make a re-read valuable as well. One of the better examples of this, was "Make code just a little generic"- often, we attempt to code things as generic as possible, and end up making what is effectively code soup that doesn't help accomplish the problem. Instead, building specifically for this problem, but trying to spot places it can be made just a little bit more generic, has altogether eliminated times I know I would've had to refactor again later if I hadn't been thinking of it. Wow, I've often felt this during my time coding. Unnecessary abstractions often just make things more convoluted and increases boilerplate when adding new things. Great to see this being addressed.

MaxBarraclough 8y ago
This principle is well known: 'YAGNI'.
- gitgud 8y ago
  You Ain't Gonna Need It is a great principle, but I think this is slightly different, as it implies it's useful to abstract it a little... So maybe JAIL? Just Abstract It a Little
  - TeMPOraL 8y ago
    Agreed. JAIL is YAGNI/KISS with a little bit of sanity sprinkled on top of it. You generally want to keep code simple and straightforward, but that doesn't mean avoiding the most obvious and most probably useful generalizations.
jsight 8y ago
Yeah, I've had this discussion with a lot of developers over the years with regards to DRY as well. I've seen people refactor code to fix "DRY" problems and the code ended up increasing in size due to the "deduplication" and increasing in complexity. When asked, "well do not repeat yourself isn't about reducing LoC". That is technically correct, but is it then about increasing code size and complexity? Sometimes
- barbs 8y ago
  Yes, exactly! I think people follow the principle blindly and try and pull out code that happens to be the same in two places. But if you anticipate that they might change in the future it's sort of a meaningless abstraction that doesn't give much benefit and just complicates the code. I think it's important to realise that these principles are good in general, but you can have too much of a good thing, and there are trade-offs involved as you take them more and more to the extreme. I can't say I'm an expert so I may be wrong about this, but it seems like you really need to get a sense of what's needed in each scenario - how should this bit of code work and is this communicated effectively? I find this takes practise to gain a "feel" for, but then that feels less teachable than simple principles.

by barbs 8y ago

MaxBarraclough 8y ago

This principle is well known: 'YAGNI'.

gitgud 8y ago
You Ain't Gonna Need It is a great principle, but I think this is slightly different, as it implies it's useful to abstract it a little... So maybe JAIL? Just Abstract It a Little
- TeMPOraL 8y ago
  Agreed. JAIL is YAGNI/KISS with a little bit of sanity sprinkled on top of it. You generally want to keep code simple and straightforward, but that doesn't mean avoiding the most obvious and most probably useful generalizations.

jsight 8y ago

Yeah, I've had this discussion with a lot of developers over the years with regards to DRY as well. I've seen people refactor code to fix "DRY" problems and the code ended up increasing in size due to the "deduplication" and increasing in complexity. When asked, "well do not repeat yourself isn't about reducing LoC". That is technically correct, but is it then about increasing code size and complexity? Sometimes

barbs 8y ago
Yes, exactly! I think people follow the principle blindly and try and pull out code that happens to be the same in two places. But if you anticipate that they might change in the future it's sort of a meaningless abstraction that doesn't give much benefit and just complicates the code. I think it's important to realise that these principles are good in general, but you can have too much of a good thing, and there are trade-offs involved as you take them more and more to the extreme. I can't say I'm an expert so I may be wrong about this, but it seems like you really need to get a sense of what's needed in each scenario - how should this bit of code work and is this communicated effectively? I find this takes practise to gain a "feel" for, but then that feels less teachable than simple principles.