1 # Disallow Warning Comments (no-warning-comments)
3 Developers often add comments to code which is not complete or needs review. Most likely you want to fix or review the code, and then remove the comment, before you consider the code to be production ready.
7 // FIXME: this is not a good idea
12 This rule reports comments that include any of the predefined terms specified in its configuration.
16 This rule has an options object literal:
18 * `"terms"`: optional array of terms to match. Defaults to `["todo", "fixme", "xxx"]`. Terms are matched case-insensitive and as whole words: `fix` would match `FIX` but not `fixing`. Terms can consist of multiple words: `really bad idea`.
19 * `"location"`: optional string that configures where in your comments to check for matches. Defaults to `"start"`. The other value is match `anywhere` in comments.
21 Example of **incorrect** code for the default `{ "terms": ["todo", "fixme", "xxx"], "location": "start" }` options:
24 /*eslint no-warning-comments: "error"*/
26 function callback(err, results) {
35 Example of **correct** code for the default `{ "terms": ["todo", "fixme", "xxx"], "location": "start" }` options:
38 /*eslint no-warning-comments: "error"*/
40 function callback(err, results) {
45 // NOT READY FOR PRIME TIME
46 // but too bad, it is not a predefined warning term
50 ### terms and location
52 Examples of **incorrect** code for the `{ "terms": ["todo", "fixme", "any other term"], "location": "anywhere" }` options:
55 /*eslint no-warning-comments: ["error", { "terms": ["todo", "fixme", "any other term"], "location": "anywhere" }]*/
61 * The same goes for this TODO comment
63 * as well as any other term
67 Examples of **correct** code for the `{ "terms": ["todo", "fixme", "any other term"], "location": "anywhere" }` options:
70 /*eslint no-warning-comments: ["error", { "terms": ["todo", "fixme", "any other term"], "location": "anywhere" }]*/
73 // even not any other term
76 * The same goes for block comments
77 * with any other interesting term
84 * If you have a large code base that was not developed with a policy to not use such warning terms, you might get hundreds of warnings / errors which might be counter-productive if you can't fix all of them (e.g. if you don't get the time to do it) as you might overlook other warnings / errors or get used to many of them and don't pay attention on it anymore.
85 * Same reason as the point above: You shouldn't configure terms that are used very often (e.g. central parts of the native language used in your comments).