From SelfDocumentingCode:

'''''Place related information closely together.'''''

Typically when you want one thing, you want a whole lot of things. If you're looking for a method signature, you'll soon want to know six more method signatures. When you want to know one bitmask, you'll want to know the rest.

'''Therefore,''' GroupRelatedInformation together. That way, you can provide entire context descriptions in one place. You can then quickly find information when you need it, especially after you get a feel for how the information in the system is organized. Moreover, this is simply applying abstraction to information instead of code. Abstraction is good.

Indeed, information by itself isn't remotely as powerful as information with links to other bits of information. The structure contains information. (see LinksAreContentDiscussion)

For example, see EmphasizeImportantInformation and SeparateInterfaceFromImplementation to see how method signatures are grouped together.

----

A good design should make sure that the more frequent a kind of changes there are, the closer related the group should be. The '''close''' here can mean physically collocated, for example, being in a same directory, in a same source file, in a same class, a same method, a same line and etc.
''From another direction, codes that reflect different kind/frequency of changes, should be separated.''

----

'''Computers can transcend physical locations'''

In practice this is not always easy because things are often related for different reasons under different circumstances. As a thought experiment, think about how to group people. EverythingIsRelative. If you draw a line between each related concept, you end up with a graph. With a graph, it is '''impossible to pull all related nodes "together" at the same time''' (and still have usable resolution). Usually a compromise decision is made to group related items; certain factors are chosen as the most important, and the distance is refactored based on that. However, the decision about what is the most important is often arbitrary or changes per need. A common battle in programming code is to group by nouns or by verbs; you just can't do both at the same time, at least not on a 2D sheet of paper.

To assist with this, I often try to factor as much to a database as I can, so that I can create virtual, as-needed grouping based on whatever factor is important in a given situation or request. Call me a RelationalWeenie if you must, but I find relational the most dynamic Group-A-Tron out there right now. What is "together" is whatever you want to be together (assuming we have all the attributes we need). "Together" is based on a query which you build yourself. Thus, if everything is in a database, what does "together" mean? Sure maybe tables are groups of things "together", but one can do PredicateDispatching on a union of multiple tables, and tableness can be removed from the result if needed. And, under dynamic relational (see MultiParadigmDatabase), the concept of "table" is perhaps optional also. See SeparationAndGroupingAreArchaicConcepts. --top

----
CategoryInformation, CategoryInfoPackaging