Post

Avdi Grimm
@avdi.codes

The definition of DRY, from "The Pragmatic Programmer" > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. It has never been about whether you repeat lines of code. Never.

15 reposts56 likes

Singularity's Bounty e/CC
@catblanketflower.yuwakisa.com

Oh, that's nice A corollary of that is when I see people on my team embedding important business logic in a long run-on if...then statement Like yeah they captured the rule, but the single authoritative place is buried in some line in a 300-line method Break that knowledge out! Unit test it!

Alan Ridlehoover
@alan.codegardener.com

My preferred way to build applications is to TDD one class per use case. A to-do list, for example, has a `CreateTask` class. `CompleteTask`, `RankTask` and others make perfect sense as independent classes in that context. Then I add persistence and an interface. In Ruby that often means Rails.

Avdi Grimm
@avdi.codes

I mean I think it's a fact in retrospect that choosing a term that sounds self-explanatory seems to have a led to a lot of people deciding they know what it means without checking. There was certainly discussion of terminology; "Once and Only Once" was another popular phrasing.

Avdi Grimm
@avdi.codes

I don't know if OaOO would have been better. I suppose this is argument in favor of "inscrutable" names of principles, like "The Law of Demeter" - you kind of HAVE to look them up instead of assuming you know.

Alan Ridlehoover
@alan.codegardener.com

I think we're on to something here. So much of the code I see has been de-duplicated in a way that makes it harder to understand and harder to modify/test/extend. And, I do think it has to do with the acronym. I wonder what proposals we could make for a more expressive acronym?