Skip to main content

no-profane-comments

Disallow profane wording in source comments.

Targeted pattern scope​

This rule checks normal source comments with retext-profanities.

Ordinary line and block comments are analyzed in full. For JSDoc, only the leading description before the first block tag is analyzed. The complete block tag section—including tag descriptions and continuation lines—is ignored. Inline JSDoc tags such as {@link Thing} remain part of the leading description and do not start the ignored block-tag section.

Block-comment decoration is normalized before analysis. Tool-control comments such as eslint-disable and TypeScript suppression comments are ignored.

What this rule reports​

This rule reports comment prose that retext-profanities considers profane or vulgar.

By default, it includes lower-sureness matches as well, which means mildly risky words can still be reported when the upstream data marks them as profane in some contexts.

Why this rule exists​

Profane comments usually do not improve technical documentation. More often, they add frustration, reduce professionalism, and make comment text harder to reuse in logs, docs, or support channels.

Reporting this wording keeps inline documentation easier to share and helps teams avoid normalizing hostile or low-signal commentary in the codebase.

❌ Incorrect​

// This fallback is a pain in the butt.
useFallback();
/* slave replicas still follow the leader node. */
connect();

✅ Correct​

// This fallback is still frustrating to maintain.
useFallback();
/* Secondary replicas still follow the leader node. */
connect();

Behavior and migration notes​

  • The rule is report only. It does not auto-rewrite comment wording.
  • Markdown code spans such as `slave` are ignored by the plugin's markdown-aware comment projection layer, which helps avoid reports on literal identifiers.
  • Use profanitySureness to ignore low-confidence matches when the default is too noisy for your repository.
  • This rule is a stricter style choice, so keeping it in the explicit all preset is a better default than enabling it in every recommended rollout.

Additional examples​

Raise the minimum sureness and allow one known legacy term temporarily:

import writeGoodComments from "eslint-plugin-write-good-comments-2";

export default [
 {
  plugins: {
   "write-good-comments": writeGoodComments,
  },
  rules: {
   "write-good-comments/no-profane-comments": [
    "error",
    {
     allow: ["slave"],
     profanitySureness: 1,
    },
   ],
  },
 },
];

ESLint flat config example​

import writeGoodComments from "eslint-plugin-write-good-comments-2";

export default [
 {
  files: ["**/*.{ts,tsx,js,jsx}"],
  plugins: {
   "write-good-comments": writeGoodComments,
  },
  rules: {
   "write-good-comments/no-profane-comments": "error",
  },
 },
];

When not to use it​

Do not use this rule if your team intentionally allows coarse internal tone in comments or if your repository contains domain terms that the upstream profanity data flags even though they are required in context.

If you still want the rule but only for high-confidence matches, keep it enabled with a stricter profanitySureness instead of disabling it outright.

Package documentation​

This rule wraps direct retext-profanities analysis:

Rule catalog ID: R004

Further reading​