User talk:Average/Encapsulate
This is another ally on the way of How to Code and has two parts SeparabilityOfDomains and ZeroSuperfluousNames.
Unless you're well-along your path already, this one is probably the toughest one crack, but once you do it your code will become technical masterpieces. This rule is the "abstract upwards and winnow the chaff rule", and is opposite of the first crucible. By walking this path, you're separating and chiseling out domains. At the end of the path, you have re-usable, tight code with little to no redundancy (i.e. ZeroSuperfluousNames).
You want to maximize lexical separability of program function so that they make the most meaningful units of modular code (i.e. you don't want everything lumped under one main function). BUT you also don't want a lot of excessive names polluting your namespace without good reason. What's the good reason? If there are more than two legitimate uses for your code (even if you don't use it yet), separate it into it`s own module/object/function with it's own name. Done right, there should be little to no code duplication NOR function harnesses or Objects that only get used once.
Apart from LISP machines, all computers use variables (names on data). Names for one purpose should be distinct from names of a different purpose (SeparabilityOfDomains). Constants, for example, shouldn't look like variables, nor should types look like variables. Syntax highlighting can't do this for you, so you have to perform this in the source text itself. Names act as an anchor. They are the gravitational attractors for other eyeballs which may be circulating around your code, so make them count. In some ways, languages are defined by how well they allow you to do this (having classes for objects, for example).
Besides careful name-choice, you have three techniques available for making names (which is to say: your domains) distinct and more meaningful: capitalization, parts of speech, and using special characters. These seem minor, compared to how well your language assists you in separating out different domains, but are included here for completeness.
1. Capitalization. Ideally, you'd use case to indicate "Parent", but this isn't practical in a real data ecosystem where objects are being examined and re-used, so use it in your source text to indicate something you intend to be passed around. That communicates something valuable to anyone who reads your code also -- it's like saying "ready for work". It's like the act of giving birth for your object (or module) to the outside world. And rather than ALLCAPS on a constant, use _underscores_ which also makes constants easier to find -- keeping them lowercase if they're for "internal use only".
2. Use verb-words for methods/functions, nouns for classes/variables (unless they're a pointer *to* a function, in which case call it a "pointerToX" or "pFunction"). This is a general rule, but for Objects that are designed to recede to the background and act as a go-between (like a network socket, for example), a verb might be more appropriate. Of course, all this is prior to satori. After enlightenment, you know that you only need << (in), >> (out), ? (query-name), % (clone) operators and that TightCoupling and ObjectComposition will do the rest. The clone operation may even be provided by the interpreter environment.
3. If your language allows it, "?" and "!" characters at the end of function names can signify that they're a boolean query or will write-in-place, respectively.
These maxims will allow your code to be readable from the outside (the above view); which is to say: re-usable.
