1
\$\begingroup\$

Most of the reviewers/answerers here should be familiar enough with Ctrl+K and Home,Shift+▼,Del keystroke combinations that an edit to provide some readability without losing the original content of the code submitted should supercede the site policy of not modifying the OP's original code.

Cleaning up code without modifying the original working functionality should not be considered against site policy per se. In my limited experience, an OP rarely knows the editor as well as someone looking to answer their question. If the intent is to post working code, why aren't commented code lines removed by the editor submission process auto-magically? Kinda like a spam or F-Filter.

Isn't that what the reputation/privileges relationship is all about? I was led to believe that a higher rep meant that the Powers-That-Be trusted that you knew what you were doing and are acting in the best interest of the site. I typically copy and paste the code into its appropriate VS editor. It is only then that I start to actually see the code for what it is intended to do. If I have to make multiple revisions to remove comments and indent to some level of standardization, why shouldn't I edit the OQ and save others the same trouble? If my revisions are ever in doubt the SE system allows for a backtrack to a previous version.

Questions submitted with code lines commented out without complete redress within the question's narrative should never have been submitted in the first place. Code Review should not be reduced to 'throw sh·crap·it mud at a wall to see what sticks. Genuine submissions should be 'This is what I've come up with. Can you suggest where it might be better?'

I am not trying to do a cut-and-run here. I'm trying to reduce the time it takes me to understand a module's sub procedure(s) to the point that I can see it from a wide standpoint and make intelligent decisions as to how to improve the code.

FWIW, I've been trying to take at least one question and seriously delve into it each weekend since I've been a member. My goal is to find out what the user is trying to accomplish and give them the best that I can offer. To date I have encountered nothing but frustration towards that goal. Today was no different.

¹ Within relevant tags, supplying a dozen or so redacted rows of sample data together with expected results should be virtually mandatory. Visualizing the start to end procedure and end-product from the code alone is rarely the most expedient method. A link to a larger set would be even better but images of data and/or code should be vehemently derided.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ I also regularly try to "deep" reviews. I have come to a point where ugly code gets a shallow review from me, and that, if I am going to spend an hour or so reviewing a question at a deeper level, that the deeper issues should be clearly "visible" in the code. In other words, I will put more effort in to reviewing questions that the asker has put more effort in to asking. I believe that this works well, because it rewards the askers who put in the most effort. \$\endgroup\$
    – rolfl Mod
    Commented Apr 5, 2015 at 13:02
  • \$\begingroup\$ @rolfl - Given that the policy as posted code is verbatim and never to be altered, would a 'passer-by' now know that the improved code was somewhere down below in one of the answers or would they simply move on to the next question that has not been answered yet? \$\endgroup\$
    – user66882
    Commented Apr 5, 2015 at 14:25

1 Answer 1

Reset to default
8
\$\begingroup\$

As explained in Should you edit some else's code in a question?, the site policy is to leave the original code verbatim, with the exception that whitespace can be fixed only if it is obvious that the author had difficulty posting the code the way it was intended. That means fixing something that is systematically botched, not tidying up messy code.

Since Code Review answers can address all aspects of the code, including code formatting, it is important to not touch the original code (other than the exception). Bad formatting needs to be pointed out in an answer, not silently edited away.

If you feel that the formatting is so atrocious that nobody could possibly understand it without first reformatting the code, then post an answer that reformats the code with no other changes. You can also post a second answer addressing other issues.

\$\endgroup\$
7
  • \$\begingroup\$ At what point does commented code become whitespace? I'm not talking about actual comments. I'm talking about one to several lines of code that are very similar to the actual working lines but were commented out because they were prior attempts that failed that and were commented out and left into the code dump that CR received. example \$\endgroup\$
    – user66882
    Commented Apr 5, 2015 at 12:24
  • \$\begingroup\$ The edits in that example look legitimate. VB code wouldn't be in a Stack Snippet — that's for JavaScript. Neither the text nor the formatting of the code changed — only the mechanics of how it was embedded using Markdown. \$\endgroup\$
    – 200_success Mod
    Commented Apr 5, 2015 at 12:29
  • \$\begingroup\$ I'm NOT advocating altering the content. Quite the opposite. I'm advocating readability for the next reviewer/solution provider that may have insight into how to improve the code. \$\endgroup\$
    – user66882
    Commented Apr 5, 2015 at 12:29
  • \$\begingroup\$ I understand. Posting an answer that fixes just the formatting and strips out extraneous comments will provide adequate feedback to the author and act as a public service to other reviewers. \$\endgroup\$
    – 200_success Mod
    Commented Apr 5, 2015 at 12:35
  • \$\begingroup\$ Oh-key-doh-key, I guess I'm just used to something like that being labeled 'Not an Answer' in SO. Different site, different canons. \$\endgroup\$
    – user66882
    Commented Apr 5, 2015 at 12:50
  • 4
    \$\begingroup\$ @Jeeped - I agree that poorly formatted, 'ugly' code is a real hindrance to writing a deep, technical review. At one stage I would have agreed that the solution is to reformat the poor code. Now I strongly believe that CR has it right in this policy to not touch the code. Sometimes the most important review is: "Fix your code formatting because it is too hard to review in its current state". That is the most important thing the asker needs to learn, and doing it for them teaches them nothing. They need to know their formatting sucks, and that readable code is step 1. \$\endgroup\$
    – rolfl Mod
    Commented Apr 5, 2015 at 12:58
  • 1
    \$\begingroup\$ "doing it for them teaches them nothing" is the most important take away from this. Our regular answerers tend to expect regular askers to be showing signs of improvement over time. No one wants to be constantly fixing or commenting on someone's poor formatting, so over time, someone who regularly posts questions with poor formatting and doesn't pay attention to the regular answers commenting on how to do it right and why doing it right is important, than they'll simply stop getting answers. \$\endgroup\$
    – nhgrif
    Commented Apr 5, 2015 at 16:04

You must log in to answer this question.