Divide
Divide: Divide your problem into the multiple, conceptual [sub]units and give them simple, but meaningful names (CRUCIBLE 1). If you don't have a meaningful division (maybe it's a "hello world" program), then you've found your first function ("main" if you're at the top of a C program). Each of your subunits is now like a mini-program and has its own I/O needs. Parameters act as inputs, and return statements act as outputs, with the code inside doing the processing. So, for example, if you're making a function to return the nth factorial, don't gather the input from the user inside the factorial function which would make it less generalizable, but in your main loop. Similarly with output. Then you have a function to add to your library for re-use (CRUCIBLE 3: SeparabilityOfDomains);i.e., you now have a little domain (computing the factorial of a number) that you've conquered and can re-use.
Divide downwards when you need to conquer closer to the machine, to get the greater detail needed in order to make a compilable program. Divide your program when you need to synthesize.
ClotheYourData and LeaveItNaked. Working together, these produce a virtuous and powerful tension with each another that can perfect your mastery as a programmer.
This rule applies from variable names, to object names, to file names holding your source.
Modular programming is about "clothing your data": putting a name or conceptual unit around your otherwise naked data and code, naming your code and storing it in a file, etc. 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 you're probably working on the wrong problem--look up "folksonomy"). So it has a companion rule: LeaveItNaked (a.k.a DontContainTheUnknown).
The first example of this tension comes when naming index variables. What should you call it? Well, if you know nothing about it, LeaveItNaked 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: "key"). If you know it's going to be a number or a character, call it "n" or "c" unless your audience are beginners (in which case "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 LeaveItNaked rule will help you not to put too much clothes on your data.
When you have a meaningful unit of data, put it in a struct or other linguistic force to group data and give it a NAME. When you have this AND methods or operators to go with it, you have an object. Make it a class.
Without a meaningful category or uniting force for some data, a grouping will only confuse everyone else and prematurely constrain your data.
At it`s most abstract, computation is a combination of dataflow and transformation functions (think binary gates, for example, 2 binary inputs into an AND gate produces one output). For general-purpose computation, you also need memory, allowing multiple levels of computation towards greater abstraction. The only requirement for a valid transformation function is simply a consistency of mapping input to output--it need not be mathematical. Boolean Algebra is one set of these, as is Arithmetic. They aren't identical, although they have useful correlations. But XOR, for example, does not map onto boolean/arithmetic, nor does the SWAP function.