5
\$\begingroup\$

My question was closed with the stated reason being:

Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example.

That sounds like a fair enough rule, but there's just one problem: this is actual code. It's not theoretical code or pseducode - it's actual code that I've written that I have come up with a few different ways of writing, and I'd like some feedback on which seems best, or, if there's another better possible way of writing it, I'd like to hear that. I feel like there's a simpler way that I haven't considered yet.

(This question is now deleted and requires moderator tool privileges to view.)

I added a comment for the diamond moderator explaining why my question was on-topic, but I didn't get a response.

\$\endgroup\$
  • \$\begingroup\$ it's not possible to post answers to hypothetical code or stub code, because actual code can be anything there can be lot of answers which is based on wrong assumptions. \$\endgroup\$ – bhathiya-perera Oct 20 '14 at 13:30
10
\$\begingroup\$

First of all, don't take this the hard way. Really. Being put on hold is really not the end of the world, and it's easy to get out of.

Look, none of the different ways of writings you provided are valid Python code, for example:

pairs = {'{': '}', '[': ']', '(': ')'}
if stackTop in pairs:
    if c in pairs.values():
        if pairs[stackTop] == c:

...

This won't run like that, you know. Something is missing there at the end. What goes there?

This site is about reviewing fully working code, and the code snippets you posted are not quite there.

At the minimum, turn your snippets into functions. Something that anyone can copy-paste in a Python interpreter and expect to work.

\$\endgroup\$
11
\$\begingroup\$
            # It's considered fine.
        else:
            # It's considered a problem.
    else:
        # Other code which checks for other possible errors...
else:
    # Other code which checks for other possible errors...

That bit alone makes me go "you've cropped the code for us".

That's not what Code Review is for. Put the full code in the question, highlight the relevant bits and ask your specific questions.

The reasoning behind this is that you might be too deep. You're wondering about how you're going to make (example) 8 levels of nesting manageable, whereas by using guard statements and early returns you'd have a neat clean function.

When you replace the implementation with comments along the lines of and then there was code here that did stuff, no matter how descriptive, you lose this "You're dealing with the wrong problem" answer. Yet that's the answer you want; for any suggestion you make is one you're not gonna be willing to accept without exhaustive argumentation, or you'd have implemented that suggestion already. A third option, in comparison, usually makes you go "oh wow" and solves the problem for you.

That's why we need context, that's why replacing code with comments leads to off-topic.

\$\endgroup\$
  • 2
    \$\begingroup\$ I was about to answer something similar to this. The question proposes three 'stub' designs, and asks for design critique. It does not present working code, and ask for an implementation/code review. \$\endgroup\$ – rolfl Oct 20 '14 at 13:25
  • \$\begingroup\$ @rolfl That's a separate answer; my point is focused on "We can't help you effectively if you do that." \$\endgroup\$ – Pimgd Oct 20 '14 at 13:26

You must log in to answer this question.

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