1
\$\begingroup\$

I asked the question Meme (title with picture) exchanger. I don't want to separate it into independent questions because the components altogether form the whole architecture; I think that the entire context is important here.

However a user said that I need to insert the code into the question, as only code in the question can be reviewed. But I cannot because there is a limit on how many characters can fit in a question.

What can I do in this situation?


Comments for context

Do you have any remarks about queries(MySQLPostDAO, MySQLUserDAO)? – Miron

No, because they aren't included in the body of the question. If you want them to be reviewed they should be included in-line rather than linked to a repository. – Reinderien

I cannot include all my code in question, because my code has too many symbols. I tried. But I noticed a limitation when I finished including DAOs package. I cannot include all code physically. – Miron

I ll try to include only important files, but i think, that it will be bad without others – Miron

Files have been added to the question on request. – Mast

| |
\$\endgroup\$
4
\$\begingroup\$

Code that's not included can not be reviewed. That's simple.

"I don't want to separate it into independent questions because the components altogether form the whole architecture; I think that the entire context is important here."

Considering you've posted the general overview and context in your first question, that question can serve as extra context for each new question you post (provided you link towards them and don't delete any of the related questions). Now you can split-up and have context. Would this be acceptable to you?

An example: Nisse Server in 5 parts

| |
\$\endgroup\$
2
\$\begingroup\$

I think there are multiple levels of issues / reviews.

  1. Character level review.
    These are the 'petty' points such as style guide conformance and whitespace issues.

    You should have spaces on both sides of operators.

  2. Line level review.
    These are normally pretty basic changes and focus on how to improve the readability of a specific line.

    It's more Pythonic to use a generator expression than map.

  3. Function level review.
    These focus on how to improve the code of a function as a whole.

    You can use the 'groupby pattern' to improve the performance of your code.

    grouper = {}
    for item in items:
        grouper.setdefault(item[key], []).append(item)
    
  4. High level review.
    These are reviews that explain how to improve your code on a level higher than functions, such as classes, modules or even packages.

    It would be better if you used {insert design pattern here}.

  5. Theory level review.
    These are reviews that are so high level that the actual code doesn't matter only ideas do.

    It would be better if you used {insert design pattern here} to handle {insert design pattern here} which offloads to {insert design pattern here}...

So "how does this relate to the character limit and posting all my code?" I can hear you ask.

Well the more low level the review the easier it is to give.

  1. I can give character level reviews by only scrolling through the code.
  2. I can give line level reviews by skim reading the code.
  3. To give a function level review I need to understand the function compleatly. And so I need to read it at least once and understand everything.

Now, answeres are motivated by a lot of things, but humans tend to do what is easiest. And so that means that the bar for getting a high or theory level review is inherently hard.

Additionally wanting us to review more than 64000 characters brings more problems:

  • That's a lot of reading for possibly not much reward. Decreasing the likelihood of getting the review you want. This is just too much context and leads to information overload.
  • The more code you include the higher the chance you made a mistake and open your question up to character or line level reviews. I.e. not what you want.

What can I do in this situation?

The way I see it is you can either:

  1. Ask us to give a high level review and include a single module or class.
    To maximize the chance of getting the result you want you should:

    1. Clean the code to the point of having no character, line or function level issues. A linter / hinter may help here.
    2. Include the least amount of code to give us the compleate picture of just that code.
    3. Include enough code so we can actually give feedback. For example including used interfaces so we understand the mechanisms of your code.
  2. Focus on the theory and find a site that will review a UML of your code.


Getting high or theory level reviews is hard, I've struggled with getting them. But I know for a fact that adding more code hurts more than it helps.

| |
\$\endgroup\$

You must log in to answer this question.

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