5 ms·

For what it's worth, such a feature is baked into IntelliJ IDEA now. It will yell at you for repeating blocks of code.

aitchnyu 5y ago
Is there something I could integrate in CI for Python code? It should pick up adversaries who change variable names and grandfather old copy paste code.
carschno 5y ago
Mind that the free community edition does not have the "Discover Duplication" feature: https://www.jetbrains.com/idea/features/editions_comparison_matrix.html https://www.jetbrains.com/idea/features/editions_comparison_...
vincnetas 5y ago
But not for multiple code bases. Or?
- caffeine 5y ago
  If they’re in the same “project” it will detect them. This is also a good way to use IntelliJ because it makes it easier to do large changes that span many code bases / repos.
- emodendroket 5y ago
  I've actually warmed up a bit to a bit of repetition in multiple repositories. There's overhead to packaging which is just not really worth it for fifty lines of code.
laputan_machine 5y ago
IMHO DRY is one of the worse things we teach new programmers, and is an anti-pattern for 80% of use-cases. Creating an abstraction that makes no sense is worse than just having code being there twice (e.g. different codebases). I worked with a guy who would apply DRY to literally everything like it was a panacea. It was an awful time.
- karatinversion 5y ago
  On the other hand, it’s also pretty bad to have a code base with a few iterations of “copy function; edit lightly; leave now stale comments untouched; replace some, possibly all, calls to old function with new ; do not delete old function ever.”
  - gonzo41 5y ago
    ctrl + alt + h on most ide's will list the callers of a function. It's pretty safe to repeat things and delete things, version control is a safety net. I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes. Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case. Most dev's aren't that lucky.
    - y4mi 5y ago
      > ctrl + alt + h on most ide's will list the callers of a function that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.
- chakkepolja 5y ago
  80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.
  - laputan_machine 5y ago
    Read my post fully. > Creating an abstraction that makes no sense is worse than just having code being there twice The key point being 'that makes no sense'. If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases. This typically makes the original intent of the fn difficult to understand Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them. 80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.

Is there something I could integrate in CI for Python code? It should pick up adversaries who change variable names and grandfather old copy paste code.

carschno 5y ago

Mind that the free community edition does not have the "Discover Duplication" feature: https://www.jetbrains.com/idea/features/editions_comparison_matrix.html https://www.jetbrains.com/idea/features/editions_comparison_...

vincnetas 5y ago

But not for multiple code bases. Or?

caffeine 5y ago
If they’re in the same “project” it will detect them. This is also a good way to use IntelliJ because it makes it easier to do large changes that span many code bases / repos.
emodendroket 5y ago
I've actually warmed up a bit to a bit of repetition in multiple repositories. There's overhead to packaging which is just not really worth it for fifty lines of code.

laputan_machine 5y ago

IMHO DRY is one of the worse things we teach new programmers, and is an anti-pattern for 80% of use-cases. Creating an abstraction that makes no sense is worse than just having code being there twice (e.g. different codebases). I worked with a guy who would apply DRY to literally everything like it was a panacea. It was an awful time.

karatinversion 5y ago
On the other hand, it’s also pretty bad to have a code base with a few iterations of “copy function; edit lightly; leave now stale comments untouched; replace some, possibly all, calls to old function with new ; do not delete old function ever.”
- gonzo41 5y ago
  ctrl + alt + h on most ide's will list the callers of a function. It's pretty safe to repeat things and delete things, version control is a safety net. I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes. Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case. Most dev's aren't that lucky.
  - y4mi 5y ago
    > ctrl + alt + h on most ide's will list the callers of a function that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.
chakkepolja 5y ago
80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.
- laputan_machine 5y ago
  Read my post fully. > Creating an abstraction that makes no sense is worse than just having code being there twice The key point being 'that makes no sense'. If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases. This typically makes the original intent of the fn difficult to understand Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them. 80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.