Best Practices

I do mostly C++ and stick to the portable side. So while you can go to non-portable things like Microsoft APIs or .Net, I avoid those. I'll give a runthrough of my opinion as to things that should be in modern C++ applications of reasonable size.

When programming C++, there's books by Scott Meyers, Herb Sutter and Andrei Alexandruscu which teach you many of the best practices in the language. As far as I'm concerned, it's no longer acceptable to simply have a working program. You have to make it flexible, code for reusability and use best practices. It does show in aspects of the end product. Use of the Boost library is also very helpful for a C++ program nowadays, as it fills in many of the holes that the standard has not gotten to. Knowledge of good object-oriented techniques as well as good template metaprogramming skills make code much more maintainable when done correctly.

Gang of Four Design Patterns is still not known by 9 out of 10 developers. That's insane to me. The book has been out over 10 years. Generally the very good programmers make use of design patterns. Head First Design Patterns is great to learn it. I see the Gang of Four book as more of a reference. I consider the grasp patterns just as important. These are described in one of Craig Larman's books.

Use of UML for modeling and describing behavior. Most developers on my team don't know UML. Another insane thing. UML is a great tool for describing a system and designing it out. Especially sequence diagrams. If there's one thing that should be used more, it's sequence diagrams.

Test-Driven Development is great for making more flexible code and actually having tests for individual pieces of a system. What I like is in order to write the test you have to decouple things. There's a few books on this which are great.

Refactoring techniques are another area not understood by many software developers. Moreso you have to understand what you eventually want the code to look like, and I think most developers see mush, see that it works and then are happy. Refactoring techniques and TDD play in very nicely together, because if you have the initial test, you can make "safer" refactorings, and keep running quick tests each time you make changes.

Separation of GUI and logic has always been a great idea. You never know if someday you might run the GUI separately or want to swap out the GUI entirely and not change other code. That's the basis of all good object-oriented design, minimizing impact to the entire system, localizing impact to specific areas. Finally, as far as separation of logic, separating it further into a scripting engine with external scripts, gives a nice mix of flexibility and speed. You can then write scripts which control specific parts of a system without rewriting the engine and waiting for recompilation all day long. Furthermore, non-developers can write scripts too. Huge advantage to a development team.

Some of these have been known as good practices for many years. They're even more publicized today as good practices. Why there is so much resistance to known good practices is beyond me. Those are my feelings anyway. There's certainly other good practices that I haven't mentioned here.