I've noticed a particular user making subtle but important changes to code samples in other people's posts. For example:


In this case the change was from:

IEnumerable<IGrouping<char, string>> queryFoodGroups =
                from item in groupingQuery
                group item by item[0];


var queryFoodGroups = from item in groupingQuery
                      group item by item[0];

I think that's a step too far. There may be a perfectly good reason that the OP is using IEnumerable<IGrouping<char, string>> instead of var and implicit types are not everyone's cup of tea. In fact the use of IEnumerable<IGrouping<char, string>> may even be the cause of the bug when it should be (for the sake of argument) IEnumerable<IGrouping<string, string>>, but the edit to var blew the chances of finding that out away and now the code just works and no-one explained to the user why...and of course because the code works people may downvote for asking why a (now) working piece of code doesn't run. All because someone tinkered with the original code.

In this example he replaces a fully qualified class name with var, fine if we know the user is developing in .NET 3.5+


This edit substantially rewrites the using statements presumably to suite his house style but it's not what the user is running:


Whilst I'm all for knocking a sample chunk of code into shape (formatting, correcting spelling mistakes, glaring syntax errors), however I think that making changes such as these start to fiddle with the OP's original meaning/intent and the problem the OP is trying to solve. At the end of the day this is how the OP has written their code, this is what they're running we should solve the problem based on that, not how we'd like to see the code written.

Additionally, answers that highlight a particular nuance in the OP's code become lost if people start "fixing" code in a question to their preferred style rather than suggesting a better approach in an answer.


2 Answers 2


Only ever touch whitespace, and if it's Python or the like, don't even touch that.

One little change might cover a bug the author has in his original code, that might results in "works on my machine comments" and in the end it might even result in no correct answer being posted at all.

If you change formatting or whatever in your answer, that's fine; for example, I often add correct whitespace around operators, move {} on the same line with their if statements and add missing semicolons in JavaScript, since the last two in combination might end up in more bugs. But I always make sure to add some comments to point out why I cleaned it up that way.

But I never change the code in a question, how bad it might be,. Put it in a code block, fix the indentation if possible and then don't touch it.

So what would I do if I see a change in the OP's code? I'd revert it.


If you are certain that you are simplifying the code example without changing the problem, and you believe that the extra content is clouding the issue (or making it difficult for others to answer) then there may be good reason to edit the code example, especially if you expect it'll help the OP understand the issue better.

Keep in mind that questions are not sacrosanct, and are meant to be timeless examples of problems that one might encounter.

The person who posted the question might not understand or know enough about the problem to cut the code down to the bare minimum to demonstrate the problem.

Experts who come by later may see the problem, understand it, and may be able to simplify the code so that it's easier to grasp the true error.

Of course, if one doesn't know enough about the problem to answer it completely and correctly, then one shouldn't approach simplifying the code.

But it can be a great help to a beginner to see how an expert pares the code down to the bare minimum to cause the problem, and it's generally not difficult for them to re-apply that information back to their more complex example themselves.

  • 2
    Another example would be fixing typos or other errors that prevent code from parsing when the question is regarding a problem at runtime. If you can reproduce the problem yourself, then you can make such edits with complete confidence...
    – Shog9
    Commented Jan 17, 2011 at 18:33
  • @polly @shog - I think removing cruft, fixing typos etc is fair game (so many examples come replete with logging code or exception handling that aren't required to repro the problem). But when you start to alter the code such that you change the way it functions its a different thing.
    – Kev
    Commented Jan 17, 2011 at 18:45
  • @Kev - well, should the dividing line be at "change function of code" or should it be at "change the error or cause of the problem in the code" - Obviously the error or issue should not be removed or changed, but if, for instance, someone includes use of a framework in a simple problem about pointers, should the framework references be removed so the question focuses on the pointer problem, or should they be left in, possibly confusing the issue with people wondering whether it's a code problem, a framework usage problem, or even a framework bug?
    – Pollyanna
    Commented Jan 17, 2011 at 18:51
  • @polly - I'm less fussed about framework references being removed, for example run of the mill .NET interop calling to COM or Win32 API's. But if it's a less common framework then perhaps that should remain in the code for clarity if not noted by the OP . But I know what you mean. However changing return value or method call sigs/semantics (e.g. changing from implicit typing to explicit typing I'd say is a no no as that's where the problem may lie in the OP's code).
    – Kev
    Commented Jan 17, 2011 at 19:01
  • @Kev - Well sure, if the problem lies in the typing, or the variable usage, etc, then certainly it cannot be changed without fundamentally changing the error itself. But even these things should be on the table if the question is a simple error that only looks ugly because it's gussied up with irrelevant code. Again, the person who modifies the code should intimately understand the code example as posted, the error, and know without doubt that their simplification will not alter the issue or error that the OP is facing. That's really such a high bar that in general practice I agree with you.
    – Pollyanna
    Commented Jan 17, 2011 at 19:10
  • 2
    @Kev - But I do not wish to scare people away from simplifying code in general. I don't want people to get the idea that the code example is sacred and shouldn't be touched. We certainly should never imply that code should not be altered.
    – Pollyanna
    Commented Jan 17, 2011 at 19:11
  • @polly - as a seasoned developer and SO user I agree, I simplify code all the time so I (and others can see past the trees). But I leave the core behaviour, method sigs, semantics, return types etc of the code intact. But changing from explicit to implicit typing should be off limits just because it makes the code "look nicer", as should be changing to suit your "house style" because these changes in and of themselves may inadvertently alter the behaviour of the code.
    – Kev
    Commented Jan 17, 2011 at 19:25
  • ...Such changes would be the equivalent of wiping away forensic evidence just because you didn't like the colour of the stain on the handle of the murder weapon. That stain may be important an important clue to solving the crime.
    – Kev
    Commented Jan 17, 2011 at 19:26
  • @Kev: OT, but... I also think of gruesome death while answering questions!
    – Shog9
    Commented Jan 17, 2011 at 19:57
  • @shog - frequently I imagine I'm on a firing squad :)
    – Kev
    Commented Jan 17, 2011 at 20:16
  • @shog I rather point out the flaw in the my answer and then provide a solution to the actual problem, recent example: stackoverflow.com/questions/4714045/… The other answer only pointed out the typo. I don't see a problem with the OP code here, it's rather a problem with people who do not read the question before posting an answer.
    – Ivo Wetzel
    Commented Jan 18, 2011 at 0:23
  • @Ivo: Your solution is effective, but only if you're answering the question. It's not uncommon to be able to recognize / reproduce a problem without having a ready solution - but this can still allow you to refine the question!
    – Shog9
    Commented Jan 18, 2011 at 0:29

You must log in to answer this question.

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