What I’m referring to mostly started with this edit where strong language that possibly originated as a joke from the OP was flagged as rude and removed from the question entirely.

The code in the question seemed rude to the answerer and I, too, thought something might be done.

A conversation started in chat about the ins and outs of such approach. A few key points were raised:

  • there doesn't seem to be historical precedence of such edits (see here or here) so is this something to take care about on behalf of the policy; or should the "do not alter posted code" rule prevail?
  • if we are to censor rude language, what are we calling rude? (is this rude?)
  • if we are to censor rude language, how should we proceed? (simply removing the content as in the example, using [redacted] or something similar…)

3 Answers 3


Language in Posts and editing profanities generally

For this section, let's assume that profanity was not forbidden

Stack Exchange is a site for users starting at the age of 13 (16 in EU). It's also intended to serve as a place for professionals to gather and create awesome answers that help future visitors.

For that reason, the policy explicitly states to prefer professional language and avoid any profanities. Users are encouraged to improve posts by editing them. That includes removing words (or even whole sentences) that do not add to the post.

There is established precedent for editing out profanity (and profanity-replacements) as not contributing to the actual content of a post.

Editing Profanities in Code

Some sites (like Code Review) have put specific editing rules in place to avoid problems stemming from "overzealous" editing. That is why we disallow edits to the code.

While we disallow edits to code in the general case, I'd say network policy trumps site-policy in cases like this.

On that note: It's not really necessary to go out of your way to clean things like that up. That can raise some eyebrows

The specific case

In this specific case the moderator team was made aware of the question through a flag as "Rude / Abusive". Flags of that kind are high priority.

In this case I saw no need to delete and lock the post, applying a 100-rep penalty for the asker for something that could be fixed with a simple edit.

If users (justifiably) take offense to the language in a post, either the language gets removed, or the post gets removed. In this case removing the two offending words was significantly less problematic.

In closing I want to lose a few words about what R/A flags do, what they're intended for and which problem they solve.

The intention of the rude / abusive flag

R/A flags do the following things:

  • Apply an automatic downvote
  • Are handled as high-priority moderator flags in the moderator queues
  • If the flag is validated - either by coming with 5 other flags or by a mod -, the post is deleted with a full-blown censoring. Even 10k Users do not initially see the original post.
  • If the flag is validated, the author of the post is given a 100 rep penalty.

Seeing this we can conclude that these flags are intended to utterly destroy things like:

  • Targeted abuse
  • Raw Evil
  • Cthulu

These flags are not the tool to be used for some "mildly over the line" formulations that can be fixed by simply editing the question.

More explicit guidance can be found in the network meta faq

  • 1
    \$\begingroup\$ Good points. Next time I will just edit it out. Thanks for clarifying! \$\endgroup\$ Commented May 18, 2018 at 7:27
  • \$\begingroup\$ How clear should you make it that you've edited the code? My general inclination is that if you just deleted (typical and best case) swears from comments or strings and it makes no real difference to clarity, functionality, &c, then say nothing. Better to let the asker save face and avoid causing further offence to readers by drawing attention to it. If you're cleaning up objectionable variable or function names, or otherwise change something that reviewers would likely comment on, it's better to leave a comment indicating that, so that reviewers don't get confused about what is whose. \$\endgroup\$
    – Josiah
    Commented May 20, 2018 at 8:34
  • 1
    \$\begingroup\$ @Josiah A friendly comment has never hurt anyone in my experience. So I would prefer adding a comment. \$\endgroup\$ Commented May 27, 2018 at 8:48

I just wanted to add my two cents.

In this case, the language would be printed when the reviewer compiles or tests the code. If you're doing any of this in an area or on a machine where this wouldn't be acceptable, I think I'd rather it be removed.


For i = 1 to 10
    msgbox("you bugger of the " & i & "th degree!")

would be different than

for i = 1 to 10 'This bugger thing sucks
     msgbox("Test " & i & " successful")

Obviously insert your own unacceptable language. The first one could simply be fixed to be acceptable whereas the second one doesn't need to be fixed.

  • 3
    \$\begingroup\$ I don't really see a distinction. Now if the offending string were piped to a speech synth, that would be a bit worse! But if people have whatever objection to unsavory text on their screen, it doesn't much matter whether that's in a message box, in the terminal, in their preferred IDE, or in their browser. \$\endgroup\$
    – Josiah
    Commented May 20, 2018 at 8:26
  • \$\begingroup\$ That's a reasonable opinion. <--Which sounds sarcastic, but it really isn't sarcastic. \$\endgroup\$ Commented May 21, 2018 at 22:59

If we agree that we should allow censoring I think there are the following things to consider when censoring code:

  • Amount of ways to censor:

    • One method used all over Code Review.

      Having one method would mean that answers will be able to see censorship clearly when it's been removed. This means they can mentally prepare for the censorship, and act on it any way it affects the question.

      Say you have the function remove_[redacted], if people know that's censored they won't vote to close the question, and will know to just work normally.

    • Many ways.

      This makes pattern matching harder for users. And so users may be confused about a question, without knowing it's censored.

  • Visibility:

    • Replace with nothing.

      • Removes something users can comment on.
      • May make reviewing harder, as you don't know what is censored.

        'x is not a number you y'
    • Format with common replacement, [redacted].

      • Allows you to know what is a censored and not.
      • The code may already have a [redacted] in the code.
    • Format with some extra special characters, ['redacted,]

      • Allows you to know what is a censored and not.
      • There's a lot of options, and it's hard to know what is good to use.
  • IDs:

    Not giving things an ID can lead to confusing situations where users don't know what things mean. Take:

    rude_words = {'', '', '', ''}
    rude_words = {'a', 'b', 'c', 'd'}

I think we should keep these edits highly visible, and for them to have ID's if there's a requirement. The only problem then is what do we select as the replacement.

  • Redacted is quite similar to withheld, it's something that happens before posting. By the OP.
  • Removed or withdrawn would make more sense, as they are actions anyone can perform.
  • Withdrawn is uncommon and so is unlikely to clash with users code.
  • Using [] is common in English to show a change in a document. This is a common operator in a lot of programming languages however.
  • Using {} is common in a lot of programming languages to format into a string.
  • Using () is normally something the op would include in a question to say describe something, and wouldn't make that much sense. It's also common in programming languages.

And so I'd use both [withdrawn] and [withdrawn:a] if an id is needed.

  • 2
    \$\begingroup\$ What problem are you trying to solve by making removal of profanities more visible? \$\endgroup\$
    – Vogel612
    Commented May 17, 2018 at 16:45
  • 1
    \$\begingroup\$ Presumably the question being addressed is what if the profanity is part of the code, perhaps a variable or function name, as opposed to an incidental part of a string or comment. \$\endgroup\$
    – Josiah
    Commented May 19, 2018 at 17:10
  • \$\begingroup\$ @Vogel612 Part to do with what Josiah said, however you answer invalidated. Something that wouldn't be a problem with the above solution. \$\endgroup\$
    – Peilonrayz Mod
    Commented May 19, 2018 at 19:08

You must log in to answer this question.

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