Code Reviews in general (not specifically at Code Review Stack Exchange) will often review the design. The people doing the review also have influence on the design too, so it is natural.

The design itself though, is a very broad, and unsubstantial concept. On Code Review (and Stack Exchange in general), it would be too broad to ask:

> I have this design in mind to implement FeatureABC. Is it a good design? Can it be improved?

The reason it is too broad is because ideas are intangible, there are too many right answers, and too many opinions, possibilities, and considerations.

So, on the one hand, pure design reviews are off-topic on Code Review, even though they are often reviewed in real-life code reviews.

This particular meta question asks, though: *When, and why, is "reviewing design" on-topic on Code Review and when is it off-topic?*

#Off-Topic

- **It is off-topic when the only thing wanted/demanded in the review is a 'design review'.**

Further, the actual implemented code is heavily dependent on the actual design. You cannot change the design without heavily impacting the code. It follows that:

 - if the design changes, the code changes
 - if the design is not 'fixed', then the code is not 'fixed'.

Now, if a question provides a design description, and matching code, then requests: *This is my design, is the design OK?*, it will be **off topic**. This is because:

 - if the design is still to be reviewed, it is logical that the design is not stable.
 - if the design is not stable, then the code is not stable.
 - additionally, if the design is not stable, then the code is off-topic because one of the on-topic questions is: ***To the best of my knowledge, does the code work?***
 - If you don't know the design, then you don't know what the code is supposed to do.
 - If you don't know what the code is supposed to do, how can you possibly know that it works?
 - the code is not ready for review if the design is not agreed.

Thus:

- **Any question requesting a design review is off-topic, either because the code is not there, or because, even if there is code, the code is just an example of what one particular design would/could look like. If the design changes, then the code is irrelevant**

So, any question requesting a design review is off-topic.

#On-Topic

So, when is reviewing the design on-topic?

When there is real code (which implies a real & stable design), and the code is sub-optimal **because** of the design!

If the code is having to do awkward, inefficient, or otherwise broken things to make the design work, then it would be on topic to say:

> This code would be better if you could restructure the design and do it *this* way instead.

- **design reviews are only on-topic when the question does not ask for one!**

(yes, exactly, only when the design review is not requested, is the design review on-topic.... and that is why we are Code Review, and not Design Review).

#Using Examples

Let me try to describe what I mean by way of examples:

----

### Design Only Question:

> I want to build an HTML Parser in LangX. I will use an IO class, an HTML entity class, and a Document class. The IO class will do X, the Entity class will do Y, and the Document class will do Z. Is this design OK?

***This is off topic*** - design questions are too broad, too many answers, and in this case, no code to review.

----

### Implementation Only Question:

> I have these three classes which together will parse and store an HTML document. The IO class manages getting data from the disk or a URL, the Entity class represents tags and other items in the HTML, and the Document class allows the entities to be contained and related. This is the code for each class: ....

***This is on topic*** - the code is ready for review, and further, if the code could perform or be structured better, then *challenging* the design, suggesting an improvement (like *You should have a parsing class instead of doing the parsing in the document class!*), or even recommending a radical restructuring would be positive outcomes from the review.

----

### Design First Question

This is the controversial one - the question requests a design review, and also presents code:

> I have these three classes which together will parse and store an HTML document. The IO class manages getting data from the disk or a URL, the Entity class represents tags and other items in the HTML, and the Document class allows the entities to be contained and related. This is the code for each class: ....
>
> I don't know the design is good, can the design be improved?
> ....

**My opinion - OFF TOPIC** - This question is asking for a code review on code that the asker knows is badly designed. Further, the code will be radically changed if the design changes.

There are two ways this code can be reviewed:

1. assume the design is good, and review the code as if the design is right
2. perform a design review first, and either confirm or challenge the design:
    - confirm - proceed on and do a code review to confirm that the code meets the design
    - challenge - say the design is bad, and thus the code is bad

In case 1, assuming the design is OK, well, that adds no value to the asker because their priority can only be to confirm the design. A code review on a design they don't trust (or want to keep) is useless. Saying *"I don't know if your code is doing the right thing, but, whatever it is doing, it is doing it very neatly and performs well!"* is also wrong.

In case 2, the question/answer should be split in to two stages. The first question should be: Is my design OK? The Second question should be: "Does this code implement the given design?"

Since part 1 is off topic on Code Review, and part 2 is meaningless until part 1 is decided, then the whole question is off-topic.

---

#Conclusion

- Code Review is not the right place to perform "design only" reviews.
- If the system is still at the stage of design review, then any code is not yet ready for a code review (you have to know what the code is supposed to do before you can tell if it is doing it right).
- when the design is 'finalized' then the code that implements that design is ready for review
- if the code could be improved by changing the design, then that should/could be brought to the attention of the asker.