New Series: Patterns

Officially confirmed: starting tomorrow, we'll be looking at patterns and behaviors that allow us to produce better, more reliable code at a higher rate.

Patterns: The 3-10 rule

Most programmers are, at least to some degree, familiar with Top-Down design principles. The 3-10 rule applies human nature to the top-down design rules, creating a substantially improved method for project generation.

Patterns: Document as you go

Ask any programmer what the most irritating part of programming is, and they'll either say debugging or documentation. Admittedly, I am one of the rare exceptions (I dislike the coding part most, because it's less about solving a problem than it is translating the solution), but I have a standard which removes the most

Patterns: Code Completion using VI

Generally, I don't much care for IDEs. In my experience, IDEs add increasingly specific features to maintain their relevance, resulting in bloated software which takes too many resources to accomplish a relatively simple task. However, as functions get more complex, it becomes increasingly difficult to make your code match the original prototypes. This is where

Patterns: The Documentation Contract

When you commit to a set of documentation, you are telling all the users how your code will work and how they should use it. This has a trickle-down effect, such that any changes to the documented features can destroy entire suites of programs. Violation of the Rule Suppose you provide documentation for an early-release form

Patterns: “Classes” in C

Encapsulation is a key aspect of the Object Oriented Programming model, and for good reason. We have an easier time grasping units which do one thing than hundreds of independent operations and objects that can do a number of things. While C does not contain the class descriptor found in C++ or Java, we

Patterns: Object Oriented C Code

Most modern languages are designed around the object oriented design principles. They contain syntactic elements that codify and require these principles for code implementation. Unfortunately, as is common with modern minds, we leave everything up to the computer. This results in a gigantic block of generalities, the result of which is slow code that is

Patterns: Protect the Iterators!

Some patterns are more obvious than others. This is one of the more obvious patterns, but it's violated often enough to deserve enunciation. Iterator Abuse Just about every program out there uses an iterator for one reason or another. Without them, we can't build for loops, and more than a few while loops require iterators as