3
\$\begingroup\$

I'm preparing to write a question for Code Review.

I've written a generic GNU makefile, with the idea that it can be applied to all kinds of C++ projects with different directory structures, etc.

My, hopefully different ;-) , question:

The makefile works. However due to...

(a) The makefile's inherent "genericness"

(b) My possible style errors.

For example, (different context but to illuminate the point) there's a right way to do OOP, some of my early code is a mixture of OOP and imperative, which would be considered 'wrong', but it still compiles and works.

(c) Actual errors (it still works, but this is a fluke)

...there are multiple types of questions I could ask about the same piece of code. For example,

  • Style questions
  • Functionality questions
  • Development questions
  • Best practice questions

Should I ask a separate "code review question" for each 'set of my questions' and post the same code, or just post the code and organise the questions into various 'departments'?

The code itself is small (< 100 lines), but because of its flexible nature (and my possible style/implementation mistakes), the possible questions and solutions it generates is may be larger than one question.

Or should I break the code up into small parts and ask about each section? (I'm guessing the answer is 'No' to that, because context is very useful, plus then the code wouldn't work, it has to be working code.)

The makefile does work, and compiles and links my project fine.

To summarise: If there's a lot of questions about one piece of code, should I ask all the questions in one post, or create many posts with different questions, but all containing the same code?

\$\endgroup\$
2

1 Answer 1

1
\$\begingroup\$

When you post to Code Review, there's always an implicit question:

How can my code be improved?

If you have specific aspects that you would like to be improved, then you can mention them in the question - as many as you like. Reviewers are always free to comment on anything they find in the code, even if you haven't drawn attention to it like that.

If your specific questions would cover everything that reviewers might consider anyway, then you could consider not giving any guidance to the aspects of interest, and just hope for wide-ranging reviews. I would probably take that approach initially, improve the code based on answers received, then post a second review request with the new code and ask about any aspects that weren't addressed in the first reviews.

Before you post your code for review, it's worth looking through a few of the existing makefile questions, as you may well learn things from those that you can apply to your own code. That will then allow reviewers to focus on the things that are specific to your Makefile, rather than repeating common problems.

An extra hint: don't Accept the first answer you get, as that indicates that you don't need more reviews. Wait a few days to see if you get several answers that address the different aspects of your code.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .