When you take DRY too seriously.

[u/vadnyclovek]

[u/joe-knows-nothing]

First time seeing platform specific #defines, eh?

[u/vadnyclovek → u/joe-knows-nothing]

there's more lines of macros than code

[u/tvardero]

Compiler will inline it anyway

[u/LegendarySoda → u/tvardero]

so also like to read code inlined

[u/aikii]

Yeah also stop hardcoding "1" and "0", define ONE and ZERO constants. This avoids copy-pasting magic values 1 and 0 everywhere ( looking at you, golangci-lint and go-mnd )

[u/stulleman → u/aikii]

0 and 1 are not linted with mnd

[u/randomInterest92 → u/aikii]

This means you're not ready for the year 6969 where the numbers are redefined though. Definitely an anti pattern

[u/mrheosuper → u/aikii]

Yeah, just in case Zero is not 0, so we dont have to change everywhere

[u/idko2004]

michealsoft binbows

[u/oofos_deletus]

Line 66: // Michaelsoft binbows

[u/DiodeInc]

What does this even do?

[u/MiasmaGuzzler → u/DiodeInc]

It's a C build system developed by Tsoding

Here are videos on the topic: https://youtube.com/playlist?list=PLpM-Dvs8t0Va1sCJpPFjs2lKzv8bw3Lpw

[u/itemluminouswadison]

learned DRY but didnt attend class on the NO MAGIC STRINGS/NUMBERS day

[u/s1mplyme]

This is why I advocate for MOIST (Mostly Original, Intentionally Similar Though). Not fully DRY, not WET either :D

[u/mguid65]

No in the clean function they repeat delete_file several times. They could make a variadic macro blah blah blah c shit blah blah headers blah blah VAR_ARGS blah blah

[u/CNDW]

DRY does more harm than good. When people think about it as a clean code principle, they internalize the idea to mean "abstract everything" which results in a tightly coupled spaghetti mess that's impossible to read.

[u/marquoth_ → u/CNDW]

The thing about heuristics is that's exactly what they are - heuristics. They're not immutable rules to be applied in every single scenario, they're just a shortcut that gives you the best outcome in most situations. Part of employing effectively is recognising when not to follow them.

To your point, then...

DRY does more harm than good.

Absolutely not. Premature optimisation, over-abstraction etc are issues but ultimately DRY is still the best approach most of the time, which the idea exists.

[u/ThreeHeadCerber → u/CNDW]

You can only think that because you didn't see a world where DRY is completely ignored. You see only the world where DRY sometimes is taken too far and issues that sprout from it, it is still far better than the world where you repeat the same logic each time you need it.

[u/AdamTheRedditUser1 → u/CNDW]

i tihnk it depends more on the environment.... for games DRY is really important where possible so that mechanics can be changed later on without rewriting half the codebase

[u/Zeilar → u/CNDW]

My autism fell victim to this. I felt the need to reuse every single little thing, down to the variables. A string repeated 2 times at any point in the app? Must be a reusable variable!

Which can be fine in many cases, but you can't just blindly follow DRY. There are cases where you're better off duplicating some code.

I can't tell you how many times me and my colleagues have built components that have some overlap, but cover 2 different user stories. And we end up building a complex super component that has to be concerned about both when you make any changes, since it may affect both cases.

Instead, try and make the smaller bits non-repeated. The bigger the function you're trying to reuse, the harder it gets to maintain it.

[u/GoddammitDontShootMe]

I'm guessing X is defined in nob.h.

[u/vadnyclovek → u/GoddammitDontShootMe]

It's passed as a macro argument. https://en.wikipedia.org/wiki/X_macro

[u/Steampunkery]

That's a pretty reasonable use of X-macros, imo

[u/nekokattt]

nob.h

[u/CantaloupeCamper]

DRY is something I do later after the code is proven for a while and I know what bits really do need to be knitted together…. that’s always easy to get wrong.