>> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition wil

>> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition". DRY is just a different thing than composability. >> not mixing things of different abstraction level in the same block of code > Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection. >> avoiding circular dependencies > Probably a good principle, but not fundamental Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.