The Principles of Good Programming

By -

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

DRY - Don’t repeat yourself. - Probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction.

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal.

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it.

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design.

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend.

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else.
A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible.

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task.

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability”

Maximize Cohesion - Code that has similar functionality should be found within the same component.

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component.

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.)

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Knuth.

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time.

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code.

Published In
To post a comment please login or register
| 6 years ago
Hello Milo and Bogdan, I know very well that the 3ds Max SDK does not follow the guidelines I propose. It grew organically over many many years, and started with some naive ideas about how to use objects to create a plug-in architecture. Replacing the SDK would be virtually impossible, since it is too coupled to the core. So consider the 3ds Max SDK an anti-pattern. An example of what can go wrong when you don't follow the principles: it can become near impossible to undo the damage. That said, we have no choice but to work with it, if you want to write C++ plug-ins for 3ds Max. However, you can follow the best practices in your own code. You can even build wrappers (abstractions) around the parts of 3ds Max that cause you grief (sound familiar?). I would also suggest taking a look at the code library we released on Google code communities with the templates. In it is a folder cold "shared" ( where a number of utility classes were added to help provide easier to use and manage abstractions around various 3ds Max concepts. I think that these classes are an example of how one can apply good programming principles to manage chaos.
| 6 years ago
Ditto what Bogdan Coroi wrote. The 3ds Max SDK and its assorted factory code samples, much like the program to which they apply, are a confounding mess. It really is the height of irony to see a list of good programming principles (and this is a good list, admittedly) on a Max SDK site. (I once read somewhere that the Max SDK is a "deep, dark world." This was written in an actual Max SDK and scripting guidebook, and that's as accurate a description as any.) Also as Bogdan wrote, Maya's C++ SDK is infinitely more coherent and, like Maya in general, far more logically and intuitively structured, and shows that the engineers behind it generally adhered to the rules outlined above.
| 6 years ago
Print this out and stick it on your head/wall:
| 6 years ago
This is the most unusual (read retarded) place to see "The Principles of Good Programming". Is there no decency left in this world? Coming up with this list on a 3D Max SDK Blog is an insult to all Max programmers. None of this principles apply to 3D Max SDK. I mean, literally NONE. After years of slavering with this crap SDK, I feel the need to kill when I see someone (Christopher Diggins) from Autodesk that works in the Max SDK area telling people how to program. Christopher please read the Max SDK. Open some random sample files like blizzard.cpp or paramblock2.cpp and tell me you see your list of quoted applied there. Don't false advertise to Max newcomers that Max has some coding principles behind it and what's worse, this list has something to do with it. Please remove this list from here. Place it in Maya section, that's a SDK wrote by someone who understands programming.
| 6 years ago
Thanks for the links 'cause w/o them some of this principles c'd been interpreted incorrectly.
| 6 years ago
What about the SOLID principles?
| 6 years ago
I've just begun learning programming and this is a good list, thank you.