Code style: Charlike. Self preferences on top of Standard Style v9 release. They may or may not be included in next releases.
(TOC generated by verb using markdown-toc)
This config extends standard v9 javascript style and just add few more rules to it, which leads to more readable code. Most of the rules here, are already suggested in the Standard repo, but they are just proposals, so they may or may not be included in the v9 or v10 version of the Standard. I just want one very stable place with all needed things included. Don't want separate CLI too, since we have ESLint CLI which works great.
Status: Locked
- Does not accepts changes - everyone can sit on top of it, like this sits on top of Standard
- Meant to be used as config, won't include CLI - probably, not make much sense
- This isn't a CLI tool - we have ESLint CLI already
Most noticeable change is that we
- Disallow computed property spacing, this
foo[ 'bar' ]
is just too ugly - computed-property-spacing- Standard allows both styles, through the
eslint-plugin-standard
option calledeither
- Standard allows both styles, through the
In addition we have few more rules
- Maximum line length should always be strictly 80, we ignore comments - max-len
- Maximum params to be 3, hence more leads to very big and complex code/functions - max-params
- If that's your case, you are encouraged to split your code more
- Always use parens with arrow functions - arrow-parens
- Maximum one statement per line, please - max-statements-per-line
- Maximum 10 statements per scope - max-statements
- No nested hell - maximum 5 nested callbacks (max-nested-callbacks) and depth (max-depth)
- If that's your case, reogranize code, increase or disable with eslint style comments
- No extra semi - hence, we use style without any semicolons - no-extra-semi
- No empty blocks and statements - no-empty. But allowing empty
catch (er) {}
s - Prefer destructing of arrays and objects when possible, because we're in 2017 - prefer-destructuring
- Prefer arrow block body only if needed - arrow-body-style, so
- No
() => { return { a: 1 } }
, when you can just() => ({ a: 1 })
- No
() => { return 1 }
, when() => 1
is enough
- No
Since this is just thin layer on top of the Standard, I don't think we should release our own badge. But in
another hand - we are a bit different, so preferebly just call it code style charlike
.
So in case you use the charlike style in your projects or just want to support and promote it, then include this badge in your README file.
Code for the badge above:
<!-- somewhere at the top -->
[![code-style-charlike][charlike-img]][charlike-url]
<!-- somewhere at the bottom -->
[charlike-img]: https://img.shields.io/badge/code%20style-charlike-536dfe.svg
[charlike-url]: https://github.com/tunnckoCore/eslint-config-charlike
Install with npm
$ npm install eslint-config-charlike --save
or install using yarn
$ yarn add eslint-config-charlike
This config is designed to work with the extends
feature of eslint inside
the .eslintrc
files. You can learn more about Shareable Configs on the
official ESLint website.
Install it then add this to your .eslintrc
file:
{
"extends": "charlike"
}
Note: We omitted the eslint-config-
prefix since it is automatically assumed by ESLint.
You can override settings from the shareable config by adding them directly into your .eslintrc
file.
- always-done: Handle completion and errors with elegance! Support for streams, callbacks, promises, child processes, async/await and sync functions. A drop-in replacement… more | homepage
- minibase: Minimalist alternative for Base. Build complex APIs with small units called plugins. Works well with most of the already existing… more | homepage
- try-catch-core: Low-level package to handle completion and errors of sync or asynchronous functions, using once and dezalgo libs. Useful for and… more | homepage
Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
Please read the contributing guidelines for advice on opening issues, pull requests, and coding standards.
If you need some help and can spent some cash, feel free to contact me at CodeMentor.io too.
In short: If you want to contribute to that project, please follow these things
- Please DO NOT edit README.md, CHANGELOG.md and .verb.md files. See "Building docs" section.
- Ensure anything is okey by installing the dependencies and run the tests. See "Running tests" section.
- Always use
npm run commit
to commit changes instead ofgit commit
, because it is interactive and user-friendly. It uses commitizen behind the scenes, which follows Conventional Changelog idealogy. - Do NOT bump the version in package.json. For that we use
npm run release
, which is standard-version and follows Conventional Changelog idealogy.
Thanks a lot! :)
Documentation and that readme is generated using verb-generate-readme, which is a verb generator, so you need to install both of them and then run verb
command like that
$ npm install verbose/verb#dev verb-generate-readme --global && verb
Please don't edit the README directly. Any changes to the readme must be made in .verb.md.
Clone repository and run the following in that cloned directory
$ npm install && npm test
Charlike Mike Reagent
Copyright © 2016-2017, Charlike Mike Reagent. MIT
This file was generated by verb-generate-readme, v0.4.2, on February 28, 2017.
Project scaffolded using charlike cli.