Mitch Wheat - Treat the cause, not the symptoms!

Here are just a few of the principles espoused in the “Elements of Style” (see my previous post) which I have taken liberty with and made a few OO analogies:

Choose a suitable design and adhere to it. This pretty much stands alone as good advice in the context of writing or coding. Spend time on the design before you start coding. Don’t hastily start coding to one design, then change it, and then change it again.

Make the paragraph the unit of composition. As a general rule, start each paragraph either with a sentence that suggests the topic or with a sentence that provides a transition. This is similar to grouping like behavior into classes. A class should contain a well-defined set of related methods, not just a random collection of unrelated functionality.

Keep related words together. The principle means of showing the relationship of words to one another is their position. The intent is to give clear meaning, and not to confuse the reader by making sentences ambiguous. The analogy I tenuously liken this to is name your methods accurately, preferably with verb-noun pairing.

Use the active voice. The analogy here is objects being asked to perform a particular behaviour rather than being used in functional coordinated approach.

Put statements in positive form. This is akin to avoiding the double negative in poorly named methods.

Use definite, specific, concrete language. Put truly common behaviour into abstract base classes, place specific behaviour in concrete classes.

Omit needless words. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences. This could be restated as: A class should contain no unnecessary methods, a method no unnecessary lines of code.

Avoid a succession of loose sentences. Do not place inappropriate behaviour in classes. If things get too complicated, make more types.