Talk:Divide

The first ally on the path has two parts ClotheYourData and DontContainTheUnknown.

The first example of this is the transition from binary (or hex) machine code into assembly instructions. Poof, readability. Do this now on the data side and you have structs, then objects, clothing your data and your functions.

Modular and object-oriented programming is about "clothing your data": putting a name or conceptual unit around your otherwise naked code or data bundles. This maxim applies to variable names, object names, and the file names holding your source. Besides proper formatting, this is the step that allows your code to be readable "from the inside".

However, when your problem isn't broken-down well, it can lead to bulky, poorly-fitting structures that no one wants to re-use (and can often indicate that you're working on the wrong problem--see "folksonomy"), so it has a companion rule: DontContainTheUnknown.

The first example of this tension, in high-level code, comes when naming index variables. What should you call it? Well, if you know nothing about it, DontContainTheUnknown would say to make it as generic as possible, like "i". But unless it's coming from the void, tie the variable name to where it originates (from the mouse: "click", keyb: "keypress"). If you know it's going to be a number or a character, call it "n" or "c" unless you're writing for beginners (in which case, you can use "num" or "ch" ;^).

Keeping your variable name as *small* and as *meaningful* as possible (another tension to optimize!) will prevent annoying variable re-naming later. The DontContainTheUnknown rule will help you not to put too much clothes on your data.

So, when you have a meaningful collection of data, put it in a struct or other linguistic force to group data and give it a name. It now becomes a unit. When you have this AND methods or operators to go with it, you have an object: make it so. Else, without a meaningful category or uniting force for some data, a grouping will only confuse everyone else and prematurely constrain your data.

Your programming environment, to make it enormously easier for you, has created keywords and variables: keywords are like machine instructions, variables are names to associate with data. To make things simple for everybody, you're not going to name any of your variables with a name from the list of keywords, ok? And, remember at some point, code is data, too.

These little programmatic things provided by your language and computing environment allow your concepts to be flattened out into individual working expressions or *sentences* and composed together in way that is grammatically correct according to your programming language. A symbol (+,?,|,^, etc.), by the way, should be seen as an extra-short keyword.

Working together, the two directives for this crucible produce a virtuous and powerful tension with each other. End result: your code becomes beautiful.