11
\$\begingroup\$

I have a project that I've undertaken to better understand several distinct aspects of the language and system I'm learning and am wondering what the best approach to asking about these aspects is.

I'd like review of

  1. the performance, clarity and efficacy of the algorithms I'm using;
  2. effective use of language idioms;
  3. how the project is factored and organized into files and modules; and,
  4. my approach to documenting and commenting the project.

While these blend into each other, the first and last (at least) seem quite distinct.

Should I ask separate questions for each (cross linking for reference), or for some combinations? Should I ask one large question with different parts? If I do ask separate questions (say for 1 and 4) is it appropriate to include slightly different code in each to focus the question (e.g. for 1, stripping out most comments and flattening the file structure)?

\$\endgroup\$
5
  • 4
    \$\begingroup\$ I strongly recommend you read this post on how to prepare code for a Code Review question here: getting the best out of Code Review Specifically, the last two paragraphs. \$\endgroup\$
    – rolfl
    Sep 17, 2015 at 20:52
  • \$\begingroup\$ @rolfl: That's more in line with what I'd expect. But it contradicts the answers so far. As I read that, I should have at least two focused questions, for example, one with the comments stripped out or dramatically reduced so reviewers can focus on (1, and perhaps 2 and 3), and another with them included and phrased to focus reviewers on (4). In the former I might even change the notes and comments to highlight relevant issues. \$\endgroup\$
    – orome
    Sep 17, 2015 at 20:56
  • 1
    \$\begingroup\$ In a sense you are right. Code Review welcomes iterative questions though, so I would recommend that you post a relatively focused question that contains, for example, one of the core algorithms. That will allow people to critique the algorithm implementation and performance, and also the effective use of language idioms. Using the insights provided from that question, you could later post a broader question (with documentation too, etc.). The project organization, files, etc. would generally be off topic as a standalone question, though \$\endgroup\$
    – rolfl
    Sep 17, 2015 at 21:05
  • \$\begingroup\$ @rolfl: That's good advice and sounds like the right approach. \$\endgroup\$
    – orome
    Sep 17, 2015 at 21:29
  • \$\begingroup\$ @rolfl: I've posted the first (perhaps second) of an iterative series to address the kinds of aspects listed above. Let's see how it goes! \$\endgroup\$
    – orome
    Sep 26, 2015 at 18:07

3 Answers 3

Reset to default
13
\$\begingroup\$

It is our policy that any and all aspects of the code are up for review. You can ask for special attention on aspects that interest you the most, and reviewers may or may not address those exactly.

As such, posting the same code with different specific questions won't make sense, as the different posts will still be effectively the same in terms of our policy.

On the other hand, if you can split your code to smaller logical elements that are reviewable independently without deep knowledge of the other parts, then it can be a good idea to split it to multiple questions. Shorter code is naturally easier to review, which attracts more reviewers.

I'm also going to quote verbatim @rolfl's comment:

Also, splitting the code in to independent parts is often an education for the programmer too, and leads to better, more modularized code as a bonus!

\$\endgroup\$
0
7
\$\begingroup\$

In my opinion, you should just ask the question and mention you'd like people to give their opinion on these 4 points.

Reviewers will be able to choose which aspect they want to review based on the time they have and their knowledge, and you should end up with pretty good points from the community.

Then, if you feel like you've gathered enough information, you can refactor your code and ask a follow-up question to see if other things can be improved.

This is how I'd do it.

\$\endgroup\$
2
  • \$\begingroup\$ I'd think that would produce scattered replies, and make it hard to pick an answer (and not very helpful for others). \$\endgroup\$
    – orome
    Sep 17, 2015 at 17:14
  • 3
    \$\begingroup\$ Picking an answer isn't really an issue, you just have to pick the one you feel is the most helpful to you. Answers are always scattered, because you can't really force reviewers to review a specific point of the code. If I want to review your memory usage, I'll do it even if you don't talk about it in your question. What I mean is that people that are interested will read the answers to find the information. It's not about being concise, it's about covering everything :) \$\endgroup\$
    – IEatBagels
    Sep 17, 2015 at 17:16
7
\$\begingroup\$

Welcome to Code Review!

I know where you're coming from: on Stack Overflow, you need to ask specific questions, and each post should have one single question and has one true answer.

This site is different in many ways. We took the Stack Exchange Q&A template, and turned it into... something else.

"Questions" on this site are not really questions. If you post one with a title such as "How can I improve performance with this foobarizer code?", and only post the code that's directly responsible for foobarizing, with //do something placeholder comments all over, you might get downvoted, and even closed as unclear or, depending how boiled-down (/MCVE'd) your code is, closed as stub/hypothetical code.

That's because on-topic "questions" on this site are all asking the same thing:

Does this code make my ass look fat?

And then some reviewers will point out naming issues and non-adherence to standards; others will take your code and walk you through a complete refactoring; others will take a single problematic line of code and explain everything there is to know about why that's wrong - all are acceptable answers, all are valuable; and as the reviewee you decide which one is the most helpful.

So how do you ask?

  1. Pick a title that succinctly describes as least vaguely what your code is about. Witty, punny titles tend to get more clicks than the boring ones.
  2. Format your post so that it's easy to follow - take the time to describe what each class does, use MarkDown formatting and MathJax as needed. Do not worry about long posts, unless the system tells you it's too long - but the best questions focus on a particular part of a project, e.g. a post for the Poker hand evaluation code, another post for the UI and modeling, another for the chat module, etc.: a whole entire project-in-a-post isn't illegal, but more likely to zombify.
  3. Point out the area(s) of concern, describe what the code is doing. Avoid cutting off "irrelevant parts" - there's no such thing as irrelevant code here.
\$\endgroup\$

You must log in to answer this question.

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