Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt a code style #141

Open
gajus opened this issue Apr 24, 2016 · 7 comments
Open

Adapt a code style #141

gajus opened this issue Apr 24, 2016 · 7 comments
Milestone

Comments

@gajus
Copy link
Collaborator

gajus commented Apr 24, 2016

Adapt a code style and declare "lint" script.

It is really hard to contribute to a codebase when it has not adapted code style.

I am biased (author), but I recommend eslint-config-canonical as it is the most strict of the existing style guides (, which has its pros and cons).

Alternatively, please have a look at https://github.com/dustinspecker/awesome-eslint.

If you choose to go with Canonical style guide, I will happily submit a PR.

@phpnode phpnode added this to the 4.0 milestone May 10, 2016
@jprichardson
Copy link

I am biased as well (which dev isn't?)... but my recommendation would be Standard: https://github.com/feross/standard - you can see that it's well past 5k stars and the primary principle is to not bikeshed on style and just get work done. Any eslint-config will almost certainly involve tinkering around with style properties and have other committers debate the merits of those changes. With standard, you're drawing a hardline in the sand and getting back to work.

@gajus
Copy link
Collaborator Author

gajus commented May 29, 2016

That argument applies to any eslint config... "standard" name does not make it an exception.

Besides, eslint-config-standard is not a real style guide. It only defines a bare minimum of style requirements.

On May 29, 2016, at 01:48, JP Richardson [email protected] wrote:

I am biased as well (which dev isn't?)... but my recommendation would be Standard: https://github.com/feross/standard - you can see that it's well past 5k stars and the primary principle is to not bikeshed on style and just get work done. Any eslint-config will almost certainly involve tinkering around with style properties and have other committers debate the merits of those changes. With standard, you're drawing a hardline in the sand and getting back to work.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@gajus
Copy link
Collaborator Author

gajus commented May 29, 2016

@phpnode See the changes I have done for node-mysql2. sidorares/node-mysql2#268

I am happy to contribute equivalent style config and changes to this code base.

@phpnode
Copy link
Member

phpnode commented May 29, 2016

@gajus that'd be awesome, thanks! I've added you as a collab on github.

@phpnode
Copy link
Member

phpnode commented May 29, 2016

Standard is out because of the semi-colons thing, you can prise them from my cold, dead, fingers 😄

@gajus
Copy link
Collaborator Author

gajus commented May 29, 2016

@phpnode Would you like me to branch from master or v2 branch?

@jprichardson
Copy link

jprichardson commented May 29, 2016

That argument applies to any eslint config... "standard" name does not make it an exception.

It doesn't in this case, because by design, standard is not configurable. You'd be correct if I recommended https://github.com/feross/eslint-config-standard

Standard is out because of the semi-colons thing, you can prise them from my cold, dead, fingers

Cool, fair enough. There's https://github.com/Flet/semistandard for that 😛

But on a serious note, I'm glad this issue was brought up. Any style is better than no style and I'm glad to see this this as it'll make everyone more productive and allow them to focus on what really matters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants