3 ms·

> It is silly example because in such scenario there is no way you can even start writing abstraction to handle that. You start writing the abstraction the fir

> It is silly example because in such scenario there is no way you can even start writing abstraction to handle that. You start writing the abstraction the first time you duplicate, so that you don’t end up with this mess down the road.

kiitos 3y ago
Better rule is the first time you duplicate, just copy/paste the code. But once you duplicate a third time, that's a pretty good signal that you have something that is common enough to be abstracted, and you can write the abstraction then.
- laserlight 3y ago
  In my experience, one is unlikely to remember how many times a piece of code is being copy-pasted, unless they are doing it in the same coding session. Everyone copy-pastes, thinking that they'll DRY the next time and the codebase turns into a mess.
  - kiitos 3y ago
    Well, when you make a new abstraction, that same PR will presumably also include changes to some N call sites to make use of that abstraction, right? The important thing is that N>=3. Anything less than that is, more often than not, premature. And in my experience, premature and/or leaky abstractions are far (far) more harmful to codebases than copy-pasted code.
    - laserlight 3y ago
      I abstract, i.e, put code into its own function, even when N=1, to make surrounding code more readable and simpler. At N=2, I definitely abstract. Abstracting doesn't mean building class hierarchies, when they are not needed. I abstract at the required level. Premature abstraction, in my book, means abstracting in expectation of future needs. It is different than abstracting small and often. My abstractions are not premature, because they address existing needs. I view copy-pasted code as cancer of a codebase. It is very difficult to tell if two similar looking code function the same way, therefore making it practically impossible to DRY away, whereas calling the same function leaves no room for guess. Copy-pasted code reduces readability, understandability, makes code longer. It never happens under my supervision.
      - kiitos 3y ago
        Given fn a foo a foo b foo c bar d bar e baz f baz g baz h and fn b foo bar baz fn foo a b c fn bar d e fn baz f g h which of a or b is more readable and simpler? (Spoiler: it's almost always a.) DRY isn't about repetition of text in a source file, it's about repetition of authority in your domain model. You evaluate it at an architectual level, not in PR diffs or whatever.
        laserlight 3y ago
        Of course fn a is simpler and more readable, simply because it's not 200-lines long and there are no indentations and there are no states to keep track of, etc. This example is not at all like a real code and is just a straw man of my argument. DRY at any architectural level corresponds naturally to repetition of text in source files.
        kiitos 3y ago
        > DRY at any architectural level corresponds naturally to repetition of text in source files. The "repeat" in "don't repeat yourself" refers to semantics (data and sources of truth) and not syntax (text in source files). This is a common misunderstanding, which is one of the things that tends to separate junior and senior engineers.
        laserlight 3y ago
        Agreed.

kiitos 3y ago

Better rule is the first time you duplicate, just copy/paste the code. But once you duplicate a third time, that's a pretty good signal that you have something that is common enough to be abstracted, and you can write the abstraction then.

laserlight 3y ago
In my experience, one is unlikely to remember how many times a piece of code is being copy-pasted, unless they are doing it in the same coding session. Everyone copy-pastes, thinking that they'll DRY the next time and the codebase turns into a mess.
- kiitos 3y ago
  Well, when you make a new abstraction, that same PR will presumably also include changes to some N call sites to make use of that abstraction, right? The important thing is that N>=3. Anything less than that is, more often than not, premature. And in my experience, premature and/or leaky abstractions are far (far) more harmful to codebases than copy-pasted code.
  - laserlight 3y ago
    I abstract, i.e, put code into its own function, even when N=1, to make surrounding code more readable and simpler. At N=2, I definitely abstract. Abstracting doesn't mean building class hierarchies, when they are not needed. I abstract at the required level. Premature abstraction, in my book, means abstracting in expectation of future needs. It is different than abstracting small and often. My abstractions are not premature, because they address existing needs. I view copy-pasted code as cancer of a codebase. It is very difficult to tell if two similar looking code function the same way, therefore making it practically impossible to DRY away, whereas calling the same function leaves no room for guess. Copy-pasted code reduces readability, understandability, makes code longer. It never happens under my supervision.
    - kiitos 3y ago
      Given fn a foo a foo b foo c bar d bar e baz f baz g baz h and fn b foo bar baz fn foo a b c fn bar d e fn baz f g h which of a or b is more readable and simpler? (Spoiler: it's almost always a.) DRY isn't about repetition of text in a source file, it's about repetition of authority in your domain model. You evaluate it at an architectual level, not in PR diffs or whatever.
      - laserlight 3y ago
        Of course fn a is simpler and more readable, simply because it's not 200-lines long and there are no indentations and there are no states to keep track of, etc. This example is not at all like a real code and is just a straw man of my argument. DRY at any architectural level corresponds naturally to repetition of text in source files.
        kiitos 3y ago
        > DRY at any architectural level corresponds naturally to repetition of text in source files. The "repeat" in "don't repeat yourself" refers to semantics (data and sources of truth) and not syntax (text in source files). This is a common misunderstanding, which is one of the things that tends to separate junior and senior engineers.
        laserlight 3y ago
        Agreed.