Finally some sense in an article and comment thread filled with anti-sense.
You don't "abstract" to avoid duplicating code, you abstract to give names to bits of code so you can think about them easier; for example you don't make functions to reuse them, you make functions to give a name to that operations so you'll think about "create_basket" instead of whatever the basket code does, and work with that abstraction. You don't even need to have that function called twice, once is enough.
Reusing inapropriately code previously abstracted in an object or function might be bad, but "don't abstract unless you write it twice or three times" is worse.
This is true, but you have to be willing to spend some time making sure you came up with the right name. Which is of course one of the hardest things in programming ;).
True, but many behaviours cannot be boiled down to a three word function name without causing even more confusion and indirection. Sometimes the raw code itself tells the story best. You don't want to force the reader to jump around between different files or parts of the code to figure out how the code accomplishes a certain simple task.
Maybe if the author of the function knew how to find the perfect words to express the exact behavior of the function in a way that everyone could intuitively understand, that would be great, but this is not reality. Human psychology is not so simple - There will always be people who will intuitively misunderstand no matter how careful and precise you are in your choice of terminology; and in these cases, your abstraction will cause indirection and confusion.
Very often, the author uses the wrong sequence of words which have multiple interpretations and this only serves to confuse and misdirect the reader. Writing the correct abstraction requires familiarity with the sub-problem and this familiarity can only be achieved through being exposed to the same sub-problem multiple times, more than 2 times, sometimes even more times.
Also, with a sample size of 2, you cannot always know what kind of abstraction you'll end up needing... Maybe as your system evolves, these 2 currently similar behaviors will diverge rather than converge and sharing an abstraction between them won't make sense; it will mislead the next developer down the wrong path.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just wanted to leave this here for people who are interested.
"DRY is about Knowledge, Code duplication is not the issue."
verraes.net/2014/08/dry-is-about-k...
This is a great link! Thanks so much for sharing. Gonna update the post to add it!
Finally some sense in an article and comment thread filled with anti-sense.
You don't "abstract" to avoid duplicating code, you abstract to give names to bits of code so you can think about them easier; for example you don't make functions to reuse them, you make functions to give a name to that operations so you'll think about "create_basket" instead of whatever the basket code does, and work with that abstraction. You don't even need to have that function called twice, once is enough.
Reusing inapropriately code previously abstracted in an object or function might be bad, but "don't abstract unless you write it twice or three times" is worse.
This is true, but you have to be willing to spend some time making sure you came up with the right name. Which is of course one of the hardest things in programming ;).
True, but many behaviours cannot be boiled down to a three word function name without causing even more confusion and indirection. Sometimes the raw code itself tells the story best. You don't want to force the reader to jump around between different files or parts of the code to figure out how the code accomplishes a certain simple task.
Maybe if the author of the function knew how to find the perfect words to express the exact behavior of the function in a way that everyone could intuitively understand, that would be great, but this is not reality. Human psychology is not so simple - There will always be people who will intuitively misunderstand no matter how careful and precise you are in your choice of terminology; and in these cases, your abstraction will cause indirection and confusion.
Very often, the author uses the wrong sequence of words which have multiple interpretations and this only serves to confuse and misdirect the reader. Writing the correct abstraction requires familiarity with the sub-problem and this familiarity can only be achieved through being exposed to the same sub-problem multiple times, more than 2 times, sometimes even more times.
Also, with a sample size of 2, you cannot always know what kind of abstraction you'll end up needing... Maybe as your system evolves, these 2 currently similar behaviors will diverge rather than converge and sharing an abstraction between them won't make sense; it will mislead the next developer down the wrong path.