openzeppelin / configs Goto Github PK

Look into use the ESLint "extends" functionality by installing this repo as an NPM package.

Since we're starting to use Dependabot across our repos, I think we should make code-style use pinned dependencies. Thus, we contain all of the linter related Dependabot PRs to this repository.

See OpenZeppelin/openzeppelin-contracts#1284.

It comes up in all PRs because it isn't natural to anyone, plus it doesn't add any value.

Try to find an existing document to base it on.

https://github.com/airbnb/javascript

This affects both Solidity and JavaScript style guides.

We're thinking 80 characters is too little. We're used to writing longer lines so it gets in the way of coding.

A justification for 120: it seems to be the width that GitHub uses.

Currently there are many style rules in both Solidity and JavaScript linters which are treated as errors.

In the interested of reducing friction for contributors, but without giving up on our pursuit of code style consistency, we have decided to demote style rules to warnings. This will allow us to ask contributors nicely to adhere to our style, instead of them running against a failed CI build.

In OpenZeppelin/openzeppelin-contracts#944 the question came up whether the line length limit should trigger an error or a warning.

I am strongly against making it an error. It should be a soft rule to nudge people in the right direction, but not something that should be strictly enforced.

Here is an interesting talk about the tyranny of style guides, which eventually had to be shared in this repository:
Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015.

In attempting to stay below the line length limit, a programmer could turn to using one-letter variable names. In this case I prefer a longer line with more meaningful variable names.

@ElOpio presents the argument that warnings will be ignored and accumulate over time. I agree with this, but in such a case we should consider removing the rule.

Try to find an existing document to base it on.

To comply with the Solidity style guide, we should add a rule to limit the maximum line length to 79 characters (note that solium doesn't yet support such a rule).

I would also drop the arg-overflow rule, since this one tackles the same problem.

This dispute happened on slack, so I'm copying the discussion here. It was brought by @facuspagnuolo.

@frangio: imo we have to enforce either all semicolons or no semicolons at all. either rule is quite rigorous but i think we definitely shouldn't be placing semicolons inconsistently
@ElOpio: yes, consistency is the objective.
@facuspagnuolo: we will always have different opinions about it but if i’m the only one against it I can live with it 🙂
@ElOpio: facu I have no opinion, as long as it's either all or none.
I think frangio doesn't like them much
@frangio: no, i don't have strong opinions about semicolons either. aesthetically i prefer no semicolons. but i recognize that there are some corner cases where semicolon injection can cause some confusion

e.g. having an expression in parentheses at the beginning of a line will cause javascript to think it's a function of the previous line's last expression

doSomething()
(x+2).should.equal(3)

my vote is for always semicolons because of the principle of least surprise

Try to find an existing document to base it on.

OpenZeppelin/solidity-docgen will be a good opportunity to test this since the codebase is small and it doesn't have any linters currently.

• TypeScript compiler options
• ESLint

https://github.com/ZeppelinSolutions/code-style/blob/ab54a1df5e936eaf1418a6235740c4939de3ed38/.eslintrc#L3-L6

Maybe we should keep the react plugin, we haven't reviewed it.

We are also interested in the rule eqeqeq which is not in eslint:recommended.

We need to decide on a small set of style rules as an initial replacement to standard.

Chai uses getters with side-effects to make assertions, like:

f().should.be.true

Side-effects are always wrong, so eslint makes the right thing sending an error like this:

error  Expected an assignment or function call and instead saw an expression  no-unused-expressions

But chai is very useful and popular.

This issue is discussed here: eslint/eslint#2102
There are many options, like disabling the rule, using dirty-chai, using eslint-plugin-chai-friendly, using jhint instead of eslint.

With "strict": true!! 😄

Can be used from other projects through extends as well.

https://eslint.org/docs/rules/no-return-await

Should be a warning.

https://eslint.org/docs/2.0.0/rules/object-shorthand