Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My team of about 70 programmers is developing C and C++ code for embedded, multiprocessor, image-processing project. We have a coding standard, and hold design and code reviews. The problem is that we don't have solid design review checklist.

Currently we have scattered design checklists, but most of them are vague. For example, you might find statements like these:

  • Component design should be extendable.
  • Coupling should be reduced between modules.

The problem of these statements is that they are totally subjective and not measurable. Extendable design for me might means something else for another one.

Is there some kind of widely accepted or proven checklist or design rules that can serve as a basis for our design reviews, especially for our object-oriented C++ code base?

share|improve this question
up vote 3 down vote accepted

First off, you should gather the scattered design checklists and associated pieces so that they are in a single place for reference.

Second, the leads of your various teams need to review the components that have been pulled together. Note what looks:

  • good and universal (for your organization)
  • needing work but still universal
  • good, but specific to particular teams
  • needing work, and not clear if anyone can use

Third, start using the first category with everyone in their reviews. Next, start revising the middle two categories so they can be used and it's clearly understood who they apply to. Finally, ditch the ones in the last category.

Congratulations, you have the basis for your organizations guidelines.

That's probably not going to be sufficient for everything you need. Start taking a look into external resources like:

share|improve this answer
+1 for "use someone else". It's amazing how many religious arguments can be stopped with "Google/Microsoft/Acme Corp thinks this, are they wrong?" – mattnz Feb 4 '13 at 2:02

I don't think it is possible to create one set of definitive rules that tell you if your design is good or not. There is just too much variability in what is considered a good design.

However, bad designs do have some level of commonality. These common elements are described in a similar fashion as design patterns and called anti-patterns. You can use then to avoid bad designs from becoming reality.

That said, I don't think you should use a design review to rubber-stamp a design as good or bad. In my opinion, a design review should be more like a brainstorm session where one designer presents his initial ideas on how to tackle a particular feature and his co-workers ask critical questions and give their views on the issue, so that you identify the trouble-spots in the design.

share|improve this answer
Although anti patterns (and patterns) are a valuable concept when used wisely, like many software engineering concepts, the idea is not the silver bullet many people hold them out to be. – mattnz Feb 4 '13 at 1:59

You can always refer to standard texts on good and bad software design patterns to decide with more certainty as to what is good or bad design. Basically referencing a standard text might help your team identify shortcomings that could cause problems in the future, in terms of for e.g. extensibility, scalability etc. Basically this way you can leverage others' experience.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.