1. The users of this style guide will probably expect that all of the rules that it prescribes will be enforced by eslint. However, this is not the case - there is a secret, non-documented segmentation where some rules are enforced and others are not, because they would be "too noisy on a legacy codebase". An example of a problematic rule like this is covered in issue #2020. I propose that all of

Given the immense popularity of Docker and the need to harden it different per platform (see ideas below) - we'd like to start writing a Docker best practices section.

You're welcome to contribute ideas and write best practices - writing and brainstorming will people is an amazing way to deepen your Docker understanding.

At first, we want to collect ideas for best practices, solidify a list

"If/else bodies with multiple statements require braces [readability/braces] " error is given for code like

if constexpr (foo) {
...
} else if constexpr (bar) {
...
} else {
...
}
while

if (foo) {
...
} else if (bar) {
...
} else {
...
}
is fine.

https://eslint.org/docs/rules/use-isnan

This is a proposal to modify the use-isnan rule.

Current rule setting:

use-isnan: "error"

Proposed rule setting:

["error", {"enforceForSwitchCase": true}]

The switch statement internally uses the === comparison to match the expression's value to a case clause.
Therefore, it can never match _case NaN. Also, `swit

https://github.com/rubocop-hq/ruby-style-guide#no-braces-opts-hash

See also rubocop-hq/rubocop#7641

foo(kw: 1) and foo({kw: 1}) will have different meanings in Ruby 3. And Ruby warns them since Ruby 2.7 if it is used unexpectedly, and Ruby raises an argument error in Ruby 3.
But the style guide says "always omit the curly braces".

So I propose revising t

There is some noise, I need to clean it up

Creating this to track adding a general guideline around logging-vs-returning
errors, and doing only one of the two at any error handling site to avoid
double logging.

As discussed/hijacked in #344, I proposed to have an option to limit the length of docstring and comments:

1. Multi-line docstring: max_doc_length, default to max_line_length (current behavior)
2. Single-line docstring: max_single_doc_length, default to max_doc_length + 3 if max_doc_length is set, otherwise to max_line_length
3. Comment block: max_comment_length, default to `max

Parentheses are not required when using the threading macros for functions having no argument specified, so use them only when necessary.

;; good
(-> x fizz :foo first frob)

;; bad; parens add clutter and are not needed
(-> x (fizz) (:foo) (first) (frob))

;; good, parens are necessary with an arg
(-> x
    (fizz a b) 
    :foo
    first 
    (frob x y))

See the Intermezzo here:

https://docs.python.org/3/tutorial/controlflow.html#intermezzo-coding-style

Which does a good job of summarizing PEP8 and benefits from existing in the official Python tutorial.

https://github.com/pablohpsilva/vuejs-component-style-guide#why-6

Again, grouping makes the component easier to read (name; extends; props, data and computed; components; watch and methods; lifecycle methods, etc.);

export default {
    // Do not forget this little guy
    name: 'RangeSlider',
    // share common functionality with component mixins
    mixins: [],
    // compos

Can we Add length literal in Array i.e will Help to find the length of Array.

array.length
return : x: size of Array

The docs pages for the rules should mention each rule's default.

Otherwise the only way to know is to inspect the code.

What version of this package are you using?
"eslint-config-standard": "^14.1.0"

What operating system, Node.js, and npm version?
node.js is 10.18.0 and npm version is 6.13.4

What happened?
when i use this npm with eslint, it get something wrong to notice me the errors in the javascript file of my project.like this error:
1:1 error Definition for rule 'no-async-promise-ex

The problem

We need a more modern way to edit examples.

• TypeScript
• pug
• SCSS

It would be incredible if we could get contextual autocompletion

Proposed solution

• Use Monaco as the editor
• Update the inbrowser-compiler with
  • possible babel-typescript
  • pug co

The Catalog docs say:

By default, Catalog integrates with Create React App and next.js. Run create-catalog in the same directory as you’ve set up your app.

Upon doing so it installs everything with no errors and says:

Run yarn run catalog-start to get started.

After running yarn run catalog-start I'm getting the following: ```Error: Cannot find module 'babel-plugin-react-requ

today on my RSS Feed I found this great article do you think is a good idea to add it on the best practice?

Rule Names should be written with their most general part first and their most specific part last is not usual because ex. infoLabel, cancelButton are very common names in iOS which is also encouraged in the next rule Include a hint about type in a name if it would otherwise be ambiguous examples.

https://github.com/airbnb/swift#general-part-first
https://github.com/airbnb/swift#hi

For bigger styleguides it's very nice to have a fixed sidebar navigation to:
a) navigate to other parts of the styleguide
b) see where you are in the styleguide

This code inside my main .lsg file already works pretty decently:

@javascript-after transpiler: coffee-script
  $ ->
    $nav = $('<nav id="toc" class="lsg--toc"></nav>')

    $.each $('.lsg--anchor'), (index, anchor) ->
      $anc