-1
\$\begingroup\$

NB. It's not an argument against "keeping the original code intact". I understand the point, I agree with the benefits and I realize the issues that may arise should we digress.

I'd like to hear the opinion of the community on the difference in regard to editing the original question after an answer's been provided between SO and CR.

My point is that on SO, the original question should contain the problematic issue and the answer needs to present a version relieved of said issue. Improving the original code to embrace the presented solution makes the latter meaningless and the former unhelpful, right? The protocol of SO dictates IMnsHO: "if XXX, apply to YYY" and both parts are necessary.

The point with CR (again - IMnsHO) is rather to present a proper, readable and maintainable coding style. As such, it's of little interest how badly the original is composed and the essential goal's to conform to a higher standard (as agreed upon by the community). The protocol of CR dictates then: "whatever your XXX, apply YYY", which (when looking at the relevant part) boils down to "apply YYY".

Of course I'm making the issue simpler than it is because I wish to focus on the principle of the matter. Has the above discrepancy been considered? What was the verdict and its rationale?

Those in my network who use CR, do so to see good quality code to fetch inspiration for themselves, strengthen their best-practices and motivate co-workers to conform to a predictable quality. Are we odd doing such? If not, wouldn't it be a good idea to consider improving the questions, as to follow the pattern "subject: declaring unsing(...) in methods? body: like-this, like-that, ta-da!"?

\$\endgroup\$
17
  • \$\begingroup\$ To clarify, is your question asking about the benefits/downsides to not allowing answer invalidation (i.e, modifying the question after answers have been received to display the 'reviewed' code?) \$\endgroup\$
    – Dan
    Jan 12, 2016 at 9:52
  • 2
    \$\begingroup\$ Possible duplicate of For an iterative review, is it okay to edit my own question to include revised code? \$\endgroup\$
    – Quill
    Jan 12, 2016 at 10:02
  • 1
    \$\begingroup\$ Keeping the original content is important for posterity. If you update the code you're fundamentally changing what the answers are responding to, which only adds confusion and removes clarity. \$\endgroup\$ Jan 12, 2016 at 10:33
  • \$\begingroup\$ @Quill I read the link provided but failed to see the answer to my question (rather, it raises said question as far I can tell). Would you mind giving me a helping hand and guide me to which part I might be missing? Also, would you mind elaborating on the short/long term? I seem not to follow which part of my point is short-term. \$\endgroup\$ Jan 12, 2016 at 11:41
  • 1
    \$\begingroup\$ @Zak I think that Konrad seeks to understand / discuss the purpose and scope of Code Review, and is suggesting that a different set of editing / titling guidelines might work better. \$\endgroup\$ Jan 12, 2016 at 11:41
  • \$\begingroup\$ @SuperBiasedMan My point is that for CR needs, posterity is unnecessary, hence, whatever might be important for the posterity itself, would be unnecessary by association. Could you take a second peek at the last sentence in the last paragraph (and the third form the bottom too). \$\endgroup\$ Jan 12, 2016 at 11:43
  • 2
    \$\begingroup\$ @KonradViltersten I don't agree with the premise that only the final result matters. Comparison makes the lessons more valuable. It's better to say "A is better than B because A uses X while B involves Y" than it is to say "A is good because it uses X". The latter is abstract and vague, while the former is a concrete example of what someone did try to do, and why the improvement offers a clear advantage. \$\endgroup\$ Jan 12, 2016 at 11:45
  • \$\begingroup\$ @Quill Now I see your point. Suppose you've got a lousy code. Your rewrite it to good quality. Then, I have lousy code (doing roughly the same thing as yours). I rewrite it to good quality. Then Jabba The Hut has lousy code... See? The lousy parts are temporary and short-term. The qualitative code is sustainable and long-term. (It happens also to be short-term too, should Jaba code qualitatively from the start. I know I don't...) \$\endgroup\$ Jan 12, 2016 at 11:46
  • 1
    \$\begingroup\$ @Quill Konrad is suggesting that Code Review could more effective as a knowledge base if question titles followed a convention of stating the concern with the code rather than the purpose of the code. \$\endgroup\$ Jan 12, 2016 at 11:48
  • \$\begingroup\$ @Zak As 200 said. Plus, the lousy code needs not to be displayed. Only the circumstances for what it's supposed to do need to be searchable. I want to know how to nicely call my variables. I only need to search for "nice call variable". No need to see how others abused the language. \$\endgroup\$ Jan 12, 2016 at 11:48
  • 1
    \$\begingroup\$ "The lousy code needs not to be displayed" misses the point of Code Review, though. That's like buying a cake. We're more like a test kitchen where we discuss and document how we arrived at the optimal recipe, including all the failed attempts. \$\endgroup\$ Jan 12, 2016 at 11:51
  • \$\begingroup\$ @SimonForsberg Just to be clear - I don't mean to challenge that answer linked to. Yet. I wish to hear the rationale for it, because I'm failing to see it. So this is me being modest (yes, hell's getting colder, haha). If I can't get any such rationale, then I'll challenge it, for sure. :) \$\endgroup\$ Jan 12, 2016 at 11:51
  • \$\begingroup\$ @SuperBiasedMan Excellent observation. Now that I think about it, I still claim that my point is valid but that the need to comparison might be incorporated in form of the answers. You're right that it's not only the final result that matters, even the way to get there does. I stand corrected. Would you agree that the final result is more important than the trial-and-error'ish way to get there? \$\endgroup\$ Jan 12, 2016 at 11:55
  • 2
    \$\begingroup\$ @KonradViltersten I don't, because the "final result" implies a correct ending solution. I see Code Review as an iterative series of possible solutions. We shouldn't assert that a singular correct answer is canonical, but provide ideas and improvements that work towards better code, rather than the 'best' code. \$\endgroup\$ Jan 12, 2016 at 12:00
  • 2
    \$\begingroup\$ By the way, we are building a knowledge base of a different kind. If you want to see the pitfalls to avoid when writing tic-tac-toe or Project Euler Problem 3, we've got that covered! \$\endgroup\$ Jan 12, 2016 at 12:17

2 Answers 2

9
\$\begingroup\$

The point with CR (again - IMnsHO) is rather to present a proper, readable and maintainable coding style.

This is where we might disagree.

The point of Code Review Stack Exchange is to ask for reviews, it is not about the final result, but about the process.

Code Review Stack Exchange is not a repository where we have a whole bunch of working programs, in their best version (what is best may be opinion-based as well), in many different languages.

As such, it's of little interest how badly the original is composed and the essential goal's to conform to a higher standard (as agreed upon by the community).

"as agreed upon by the community", that's a problem. It is not up to the community of Code Review Stack Exchange to decide what is the higher/best standard. It is up to us to determine whether or not the code posted in the questions are living up to the standards or not.


If you want to see code in its best, most recent, most clean version, use Github.

If you want more eyes on your code and want to improve it as it looks in a specific state, at a specific time, then use Code Review Stack Exchange.

\$\endgroup\$
2
  • \$\begingroup\$ "...it is not about the final result, but about the process...". Given that, I have no issue anymore. My idea of the repository of good code is great but probably not appropriate here. I was aiming at some kind of wiki-based how-to's for coding style, I guess... \$\endgroup\$ Jan 12, 2016 at 12:03
  • 3
    \$\begingroup\$ @KonradViltersten Maybe if SO's documentation feature does well and gets added to CR this is something that could be included here as our 'documentation'. \$\endgroup\$ Jan 12, 2016 at 12:09
9
\$\begingroup\$

Getting the best value out of Code Review

I disagree with the premise that Code Review is about "Whatever your XXX, apply YYY". Code Review looks at your code, holistically and in the context of its intended usage, and provides customized advice to improve your program and your coding skills. As the Help Center states, Code Review is not the place to ask "What is best practice?" questions. Rather, it is the place to get open-ended critique on any and all aspects of your code. Your code, in its original form, is at the heart of every question.

In that light, I think that some of your questions have been rather sketchy. Some have been judged off-topic. Others are marginal, and I think that you aren't asking questions in a way that gives you the best value out of Code Review.

For example, Single instance of reusable HttpClient reads almost like a Stack Overflow question. The question title (originally "Is a single instance of reusable HttpClient a bad idea?") asks a pointed question. "Poof" is a made-up name (which is often problematic, but would probably be allowable here, if it weren't for the mismatched parentheses). I don't know why you've told us to imagine a try-catch — the error handling code should be included in the question, and we may critique that too. (Alternatively, just don't mention the try-catch at all, and if an answer complains about your lack of error-handling, you can just silently ignore that advice.) In short, it looks like you've gone to some lengths to sanitize your code for the question, when in fact you would get a more honest review of your code if you just presented it as-is. (Would you sanitize your code before asking a co-worker to review it, then check in some other version of that code?)

Another question from yesterday (Function to validate a GUID, an EntityState, and some data) has problem with lack of context. I would have a hard time giving you good advice, because I don't know what else is in your class. Is your Validate() function called from one method or many? (If it's one, then it may be better not to have this code in its own function. If it's many, then perhaps there is a way to refactor.) Perhaps validating everything all at once isn't even the best way to do it. But since there isn't any context given, we don't really have much freedom to offer you better advice. Rather, we are restricted to tweaking whatever little code you've presented in the question.

Anyway, my goal here is not to criticize your questions. I just wanted to point out that "Whatever your XXX" is not the best mentality for Code Review. We really do care about your particular XXX and all its details. If you want to ask about general principles abstractly, Software Engineering would be the place. If you have a specific question about your code, whether or not it is in a working state, then Stack Overflow would be the place.

Question titles

We once tried to Prompt for more meaningful question titles. It turned out to be complicated and unworkable in general. Given the choice between titling questions based on the purpose of the code or titling questions based on the concern that the author has about the code, it became clear that the purpose of the code was more important. After all, each question is about your code. Code Review may reveal problems with the code that you didn't even know existed. Also, if question titles stated the concern, we would end up with hundreds of questions with the title like "Please help me clean up this mess of if statements!" With the longer questions, there would be too many concerns to fit in the title.

So, in the end, we changed our site policy to Stop mentioning major concerns in title.

Editing questions after receiving answers

To preserve the fundamental question-and-answer nature of this site, the code in the question must be preserved. The Help Center states the policy, and suggests alternative ways to share your final result, if you so desire. The rationale for not editing or adding "finished" code to questions is given in this meta post.

\$\endgroup\$

You must log in to answer this question.

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