Hacker News Reader

Comment by wvenable | Hacker News Reader

DRY is not about reducing code -- in fact, it's right in the definition the author provided:

> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

It says "knowledge" not "code". This is an important distinction. Removing duplicate code might not be removing duplicate knowledge and having duplicate/similar code doesn't necessarily mean you're duplicating knowledge.

A toy example: if you happen to have 2 products that are the same price you still wouldn't want to combine them into one constant value.

Some code might be similar by happenstance and combining that will cause problems when that happenstance stops being the case.

View on HN

Yes, a better description of DRY might be "one place to change a fact".

It's a specific example of my general rule in designing my projects: things that tend to change together should be closer together.

I really like that explanation and I’m probably going to steal it. :)

Perfect! It implies that there is something you have to think about before you think about DRY. This "something" is representation of facts and data. The universal idea of pulling data out of code seems to be as old as programming itself and is proposed by Unix/C programmers and Lispers alike.

After pulling out the data, the code becomes simpler, more general and more composable. The data structure then often reveals repetition that is not redundancy: If you look at a configuration file, a SQL table or a REST response that has repetition, it becomes clear that it represents different facts (to use your term) that happen to have the same values (Alice and Bob have the same age). This form or repetition is fine, correct and often interesting!

So by the practice of pulling out data from code we get DRY (by the definition of the authors) code.

However there is also also another form of repetition that is a bit more subtle: boilerplate. There, the representation of an algorithm (as code) is drowned in noise that does not convey the intent and the flow of what is happening.

To increase the signal to noise ratio in code that is already(!) DRY but clouded by boilerplate, one needs a way to reduce syntax itself, which can be achieved by meta-programming and DSLs.

Interesting point. We could say then that it's a special case of the principle that illegal states should be unrepresentable. [0]

[0] https://fsharpforfunandprofit.com/posts/designing-with-types...

You talking politics in a coding thread?!

I see this all the time in well-intentioned "agile" projects. They fail to fully understand the domain and then micro optimisations like this lead to features breaking in interesting and unexpected ways.

I get a kick out of the OO languages that factor everything to such a fine granularity that there seems to be one line of executable code per class.

The exception traces go on for a couple of screens, so I guess the coders feel like their CompSci degrees are justified.

On a related note, I've seen people taking this too far in functional/procedural code. Not every concept needs its explicit name, not every function needs to be 5 lines of code or less. All that jumping around between function definitions is a serious impediment to readability.

(EDIT: this is mentioned in the article as "localization complexity")

> Not every concept needs its explicit name

There is a special subgenre of functional programming, where the style is to explicitly not have names

https://en.wikipedia.org/wiki/Tacit_programming (also known as point-free)

I've been thinking about it lately. Esp. since I've taken another look at the refactoring chapters of Clean Code, but instead of being enlightened I felt disgusted. Like, for-loops are ok, if-statements are ok, those are the basic constructs of code, you can see the shapes visually and it's easy to follow the code path. This is what you find in low level C/C++ code, lots of switches, loops and conditionals. Those programmers just get used to the verbosity and look at shapes instead of reading line by line. Maybe it's easier for subtle mistakes to pass unnoticed, but refactoring out everything into layers of abstraction brings jumping around and context switching between these different pieces and trying to make a mental picture of how it all fits together.

There are ways to flatten those trees and leave the code a bit more readable. Bertrand Meyer hit on it 30 years ago:

   if (weShouldDoThis()) {
       return doIt();
   }

Structurally, this seems very similar to having twenty methods with one conditional block and a delegation to some other method. But the stack trace is half as high, and the testing surface area is greatly improved, because the code in the 'if' clause is pure, or close to it, while the 'doIt()' method might alter shared state.

There's a big difference from a robustness standpoint between having half of your functions pure, and half of each function pure.

That stuff drives me insane. Can't cope with it at all.

I'm working in audio DSP as a rule, so I already have to maintain state of 'what the audio is doing related to this set of sample data', and often some things about how controls must move and feed information into the program to relate to a desired change in the audio which itself can be somewhat indirect. Maybe I am just stupid, but when I have to track DRY code I just blow a gasket immediately and can't parse it at all.

I've wondered whether some of that stuff is about taking trivial problems and making them hard to follow for the uninitiated, to protect employment. WHY not repeat yourself, when the problem is repeated tasks? Or more relevantly, why not write a complicated and long sentence, rather than mangle the sentence into a series of more abbreviated footnotes? DRY reads to me like that chain of footnotes. You lose the plot.

Well, I do :)

The Sahara-loving sort of people can justify both definitions of DRY for the same code change.

Often they've gone into removing idiomatic code as if idiomatic code isn't a presumed piece of knowledge the entire team shares, and seeing that code indicates "everything is normal" while seeing a function indicates "something odd may be happening, spend cycles looking at me".

The other definition is requirements, rather than knowledge or duplication. If two pieces of code are driven by separate requirements, eg, the price of two items is typically based on very different business situations, unless the two items are flavors of the same beverage perhaps, then the fact they share a price is an accident of the current state of the business, not dictated by a common requirement that they both be $1.50.

If both have to calculate sales tax because of the same statute, then don't implement the calculation twice. If a new statute changes that situation, for instance due to a sugar tax, split the code when the new requirement comes in.

when that happens it's called coincidental coupling, when two things get coupled together for the wrong reason. It often is done when people are trying to be too "dry" and trying to remove as much duplication as possible. But duplication is just an "indicator" that something might have bad modularity. However code should have good design principles guiding it and must drive modularity decisions like ensuring modular parts have good cohesion, it's not simply just because there is duplication.

"A toy example: if you happen to have 2 products that are the same price you still wouldn't want to combine them into one constant value."

A more common example, take an online clothes store. They only sell shirts and trousers (pants - :]). It's a really simple app. Obviously, I'm skimming a great deal here, but each product category is described by the following properties:

- Shirts -- Price -- Size -- Colour

- Trousers (Pants - :]) -- Price -- Size -- Colour -- Length

What the DRY principle generally addresses, is this basic idea. My instinct would be to create an abstract class called Clothing:

- Clothing -- Price -- Size -- Colour

Trousers (Pants - :]), for me, would definitely be an extension of Clothing. But until my suppliers can furnish me with Dresses, T-shirts, Scarves, etc, I would not be too concerned about even creating a separate Shirt class, but probably would.

What I've since found through experience however, is that not everyone thinks this way. For some people, each product category would have absolutely have to have it's own wholly encapsulated class in this situation. I can see the problem such an approach attempts to head off, but until the problem actually exists, I believe this pattern makes the development process painfully inefficient, and harder to maintain.

It's interesting to me, because while it seems like 'one of those' arguments, it's somewhat more impactful than 'tabs vs spaces'.

Classification systems ("ontologies") often represent a particular path through a graph, rather than an absolute tree.

In your example, the store adds "Shoes". Then later, it adds "Sale Items". Now you want some shoes, trousers, and shirts to be on sale.

So each item now has two edges, its "primary_category", and "sale_items". A little bit later, the store turns into a Sale Items at Massive Discounts! Store, and the primary ontology becomes price tiers.

etc

Even here, I feel we're overcomplicating things. For example, possibly ignoring what 'Shoes' are comprised of, were Clothing now to contain:

- Clothing -- Price -- Size -- Colour -- Discount

Then does your scenario really become as big a problem as you suggest? For one, some ontological relationships needn't be described in the same layer, or can simply be implied.

A Red Fox, a Red Ant and a Red Snapper are definitely related in some way, but I wouldn't use the same class to program a representation of all three.

A Red Shirt, and a Red Pair of Trousers/Pants though, probably share enough for a rough outline for online shopping app though.

Actually I would not create any Clothing class or abstract thing, but instead probably create a structure, which is named something like "product" and then let it have a flexible attributes container. For example it could have: id, categories, price, product-attributes. Where product-attributes is a key-value thing. categories would be either a hierarchy or tags, but probably tags, as they avoid issues with inventing artificial hierarchies later.

This way I would never need to make a class "shirt" or "pant" or whatever. I would simply add categories for them. Way simpler than encoding this stuff in some class hierarchy. There is that word again, hierarchy. The problem with those is always, that sometimes you will have an item, which fits into 2 sibling categoies or into 2 parts of the tree, which are not on the same path. With classes you will need multi inheritance or you will need to come up with a new parent of both of the classes.

> Where product-attributes is a key-value thing

The problem with this approach (and I've done it) is that product-attributes is now this black hole that's difficult to query, difficult to modify, a huge potential for errors that could even be caused by a typo. It's also incredibly difficult to version.

I regret going with this approach even though it results in far fewer tables and classes. It's short term gain for long term pain. Everything is trade off -- it might well be more than worth it for something not expected to live long or have a lot of changes.

Although I agree with your point that not everything needs to be hierarchy. You can be explicit with your data without having everything inherit from everything else.

Fair point. I guess you would still have to have your conventions (and actually follow them) about what you put in the attributes for which kind of product. I am thinking though, that if you need to implement any new functionality for a specific product, you would discuss it with other developers (or yourself, if you are alone) and find a good convention of what to store and then on another part of the program make use of it. If you wanted to encode the convention into your code, you can create product type specific constructors, which you have to use (another convention!) when creating such a product. Still lighter weight than creating a class for everything and avoids coupling behavior with state.

I guess the approach stands or falls with developer discipline. If you one is not disciplined enough about the conventions and carefully choosing them, one could end up with a mess of a mass of unknown keys in products, which no one knows why or how they got there.

What I'm saying is that trees represent a single path through a graph. As requirements or nodes change, the path can change, or multiple trees can coexist.

Think tags on items represented on a tree, where clicking the tag reorients the category around what you clicked on.

While I largely agree with you about what the right kind of takeaway you should get from DRY, it seems like a no-true-Scotsman argument to me.

DRY stands for “don’t repeat yourself”. that’s its de facto definition, unfortunately... whether it’s useful or not.

Just like REST and OOP and a host of other things that “everyone gets wrong”, you have to consider that if everyone gets it wrong, maybe the messaging isn’t very good in the first place.

> Just like REST and OOP and a host of other things that “everyone gets wrong”, you have to consider that if everyone gets it wrong, maybe the messaging isn’t very good in the first place.

In my experience, it just means that an army of ignorant middlemen grabbed hold of a concept and ran too far with it.

OOP / UML / XML / etc. etc. They all actually solve problems very well. But the people who taught those concepts were mostly selling snake-oil under the guise of XML or whatever.

If any particular paradigm becomes useful: the parasite class of marketers / con-men come out and sell fake versions of the strategy. Eventually, the con-men completely corrupt the concept and we just have to move on to the new concepts that haven't been corrupted yet.

I'm working in an older codebase (not THAT old, but it feels old because it's so bad), lots of database interactions. There's three data models (or sets thereof) that are mostly the same - MOSTLY.

I could make the tables flexible (add columns to fit all data models). I could make the queries dynamic (make the table part flexible). But I'm duplicating code instead.

As the proverb goes, a little duplication is better than the wrong abstraction. There's bits of code in here where the author tried to be smart, but queries like "select id from $table where x = $y" really throw my editor (and brain) off.

On the other hand you could argue, that "how a computer does things" is also some kind of knowledge.

For example: How to render some part of a website for example or a calculation, which uses the same formula as is used in another part of the code to calculate a number.

So with that interpretation of knowledge, you would have to avoid duplicating code. And it makes sense, because, if one day you need to change the way the computer does something, you want to avoid changing it in multiple places, because that makes it easy to forget places. This way avoiding duplicated code increases maintainability.

> It says "knowledge" not "code". This is an important distinction.

Yep. Though the same pathologies exist even with this framing. By that I mean it's easy to misdiagnose what the "knowledge" actually is. Even totally identical types and behaviors can be distinct in the knowledge sense if they exist in different contexts.

Reply on news.ycombinator.com