Shared publicly  - 
One of the thinking points when I consider code design, and as a positive feature, is locality of effect.  Which I don't think is a formal term (except in quantum mechanics), but it's the only one I got for the idea.  An extension of that that I've just been thinking about is locality of expectation.  How well does a piece of code express everything necessary to make the code successfully execute?  The finer the grain the better – at the largest scale this is stuff like what needs to be installed, what services need to be up, etc.  Then you can move down to libraries, modules, functions, methods, each to greater effect.

Unit testing helps here, but to go a bit further you might ask: how hard is it to write an invalid unit test?  But to look at it that way you have to split the unit test into two parts: action and confirmation.  You can easily write invalid confirmations, e.g., "assertEqual(3+4, 10)" – and you can think of exceptions and other failures as kinds of confirmations.  But ignoring confirmation, how certain can you be of the validity of actions?
Ken Stox's profile photoMichael R. Bernstein's profile photoIan Bicking's profile photoAaron Hamid's profile photo
Locality is a big issue in HPC. 
Making software (even if they are just the tests) provably correct isn't easy. Generally, languages that make provably correct software possible haven't caught on with developers.
I think of these more as smells than hard controls, though of course other people have tried to approach it other ways.
i agree, conceptual locality is a principal to strive for. it's all a balance - what can fit in the programmer's "working memory" and what is worth extracting to make the immediate concern simpler but forcing a level of indirection to form the complete picture.  i actually find a converse issue with test-driven development - while in most cases I believe code that is more testable is better factored, there are definitely annoying cases where code must be artificially modularized purely for the purposes of testing where such modularization destroys this conceptual locality.  the perfect example is having to artificially fabricate the concept of some pluggable interface for mocking/stubbing purposes when in reality there is only ever one implementation and the "pluggability" is an unused feature (this often results in ridiculous vague abstract interface names).
Add a comment...