3 ms·

I think the point of DRY is to avoid side effects. For eg. If you repeat same code 10 places and in one instance you decide to change the logic, now you have 9

I think the point of DRY is to avoid side effects. For eg. If you repeat same code 10 places and in one instance you decide to change the logic, now you have 9 places with old logic and 1 place with different logic. Removing duplicate code for readability and making code clean is second order affect in my opinion. Times have changed since pragmatic programmer [1] was written. Lot of the code we write today does not have the longevity nor it needs the resilience that was required in past decades. It is purely because things move very fast, engineers iterate very fast these days. Lot of principles still hold true but we have to pick and choose what's right for a given problem or situation. [1] https://en.m.wikipedia.org/wiki/The_Pragmatic_Programmer https://en.m.wikipedia.org/wiki/The_Pragmatic_Programmer

JonChesterfield 3y ago
That pragmatic book is very keen on code generators. Distill the information to some variant on ASCII tables and then derive all the redundant forms from it as a compilation step. I think that's the right approach. I'm totally up for generating C++ from JSON if that's the available data representation. So far, essentially everyone I've worked with has hated code generation in all forms. In language mechanisms may or may not be acceptable (C++ templates more likely to be OK than C macros). Outside language mechanisms - python writing source code during the build and similar - very hard to get past review. I'm curious whether that aligns with other people's experience.
magicalhippo 3y ago
We duplicate code to avoid bugs. We have a lot of customer integrations, and often the source system is one we've integrated with before. So we usually copy the whole integration and make some tweaks. Invariably our customers want some data massaging and custom logic, and by duplicating we can't screw up another customer's integration when we make changes. Of course we do have some code in shared libraries, like parsing dates and numbers, cleaning mixed utf-8/latin1 input and such. Of course, that does mean we might have to change many integrations if something fundamental changes. But overall it has worked very well for us.

JonChesterfield 3y ago

That pragmatic book is very keen on code generators. Distill the information to some variant on ASCII tables and then derive all the redundant forms from it as a compilation step. I think that's the right approach. I'm totally up for generating C++ from JSON if that's the available data representation. So far, essentially everyone I've worked with has hated code generation in all forms. In language mechanisms may or may not be acceptable (C++ templates more likely to be OK than C macros). Outside language mechanisms - python writing source code during the build and similar - very hard to get past review. I'm curious whether that aligns with other people's experience.

magicalhippo 3y ago

We duplicate code to avoid bugs. We have a lot of customer integrations, and often the source system is one we've integrated with before. So we usually copy the whole integration and make some tweaks. Invariably our customers want some data massaging and custom logic, and by duplicating we can't screw up another customer's integration when we make changes. Of course we do have some code in shared libraries, like parsing dates and numbers, cleaning mixed utf-8/latin1 input and such. Of course, that does mean we might have to change many integrations if something fundamental changes. But overall it has worked very well for us.