:arrow_heading_up: JavaScript Code Style checker (unmaintained)
Home Page: https://jscs-dev.github.io
License: MIT License
JSCS is a code style linter and formatter for your style guide
To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.
How about to fix errors automatically in special mode?
jscs . --autofix or something
The config:
"disallowSpacesInFunctionExpression": { "beforeOpeningRoundBrace": true }The code:
{
get locale() {
return locale;
}
}The result:
Illegal space before opening round brace at js/helpers/i18n.js :
73 | get locale() {
-----------------------------^
74 | return locale;
75 | }
Operator - should not stick to preceding expression at ./lib/plugins_loader.js :
30 | .readdirSync(this.PLUGINS_PATH)
31 | .filter(function(pluginPath) {
32 | return pluginPath.substr(-1 * self.PLUGINS_EXT.length) === self.PLUGINS_EXT;
---------------------------------------------^re #54
As it stands now preset isn't very useful as it only has the jquery style. Seeing as the config is fairly verbose it would be nice to have some ways to reuse it.
Would be useful if preset could have a searchpath in this order:
"main" in package.json can be a .json file it could be the preset and requiring the module, would give you the preset config object.I try to run jscs on a pretty large project (~1125 files with ~90.000 LOC). When I run jscs in the project root, it prints:
Error: EMFILE, readdir 'foo/bar'
Where foo/bar is a random (?) subdirectory of the project. I assume this has to do with too many files somehow (if i restrict jscs to a random path further down the hierarchy, everything works fine).
Is there anyone else encountering this problem? Should some limits be introduced somewhere in the code?
If I declare - operator as disallowLeftStickedOperators, then it throw when passing a negative number as parameter.
Operator - should not stick to preceding expression at env.js :
336 | it('adds new filepath to the load paths', function () {
337 | this.env.appendPath('support/scaffold');
338 | assert.equal(this.env.paths.slice(-1)[0], path.resolve('support/scaffold'));
------------------------------------------------^
339 | });
340 |
Given the following configuration:
{
"requireCurlyBraces": ["if", "else", "for", "while", "do"],
"requireSpaceAfterKeywords": ["if", "else", "for", "while", "do", "switch", "return", "function"],
"requireSpacesInFunctionExpression": {
"beforeOpeningCurlyBrace": true
},
"requireMultipleVarDecl": true,
"requireSpacesInsideObjectBrackets": "all",
"disallowSpaceAfterObjectKeys": true,
"disallowLeftStickedOperators": ["?", "+", "-", "/", "*", "=", "==", "===", "!=", "!==", ">", ">=", "<", "<="],
"disallowRightStickedOperators": ["?", "+", "/", "*", ":", "=", "==", "===", "!=", "!==", ">", ">=", "<", "<="],
"requireRightStickedOperators": ["!"],
"requireLeftStickedOperators": [","],
"disallowSpaceAfterPrefixUnaryOperators": ["++", "--", "+", "-", "~"],
"disallowSpaceBeforePostfixUnaryOperators": ["++", "--"],
"requireSpaceBeforeBinaryOperators": ["+", "-", "/", "*", "=", "==", "===", "!=", "!=="],
"requireSpaceAfterBinaryOperators": ["+", "-", "/", "*", "=", "==", "===", "!=", "!=="],
"disallowKeywords": [ "with" ],
"disallowMultipleLineBreaks": true,
"validateLineBreaks": "LF",
"disallowKeywordsOnNewLine": ["else"],
"requireLineFeedAtFileEnd": true
}For an offending line such as the following, 4 warnings are generated.
foo( n*2 );Operator * should not stick to following expression at example.js :
Operator * should not stick to following expression at example.js :
Operator * should not stick to following expression at example.js :
Operator * should not stick to following expression at example.js :
Coming from disallowLeftStickedOperators, disallowRightStickedOperators, requireSpaceBeforeBinaryOperators and requireSpaceAfterBinaryOperators. I can understand getting two (space before and space after), though it'd be useful if the warning message mentioned it in that case.
However having all four of them trigger seems odd. So I wonder, are these (sticked operators and binary operators) overlapping sets, or is one of them a superset and as such I shouldn't enable both?
In both Crockford's code conventions and MediaWiki's code conventions it is specified that:
(" (left parenthesis) must be separated by one space. This gives visual distinction between keywords and function invocations.In other words, always a space after function, both for anonymous and named functions.
The documentation features the following two examples:
/*
Option: requireSpacesInFunctionExpression
- beforeOpeningRoundBrace
- beforeOpeningCurlyBrace
Requires space before () or {} in function declarations.
Accepts:
function () {}
function a () {}
Rejects:
function() {}
function (){}
*/
/*
Option: disallowSpacesInFunctionExpression
- beforeOpeningRoundBrace
- beforeOpeningCurlyBrace
Disallows space before () or {} in function declarations.
Accepts:
function(){}
function a(){}
Rejects:
function () {}
function a (){}
*/Basically what we need is a way to accept:
function () {}
function a() {}And reject:
function(){}
function() {}
function a (){}
function a () {}The beforeOpeningRoundBrace option is currently not sufficient for that purpose.
Just like JSHint had:
/*
Option: consistentQuoteMarks
requires all quote marks to be consistent
possible values: "single", "double", true
single:
Invalid example:
var foo = "blah blah";
Valid example:
var foo = 'blah blah';
double:
Invalid example:
var foo = 'blah blah';
Valid example:
var foo = "blah blah";
true:
Invalid example:
var foo = 'blah blah';
var bar = "blah blah";
Valid example:
var foo = "blah blah";
var bar = "blah blah";
Valid example:
var foo = 'blah blah';
var bar = 'blah blah';
*/
Please publish a version for Rhino or browser-like environments so we can use this library outside of nodeJS. See https://code.google.com/p/wro4j/issues/detail?id=806 for a related discussion.
In relation to #66, something like this:
/*
Option: requireSucceedingCommas
disallows preceding commas in lists
Invalid example:
var x = {
one: 1
, two: 2
}
Valid example:
var x = {
one: 1,
two: 2
}
*/
I have invalid symlink in path
/lib
symlink <--- this symlink is invalid
jscs fails to check projects with msg
Error: ENOENT, stat './lib/symlink'
excludeFiles option doesn't work for this
In a CI environment, it is common to collect results in the checkstyle XML format. This could probably implemented in a way compatible to jshint (supporting reporter=checkstyle as a CLI option).
"disallowMultipleVarDecl": true is good option, but useless in for loop
As usually we use this code and it's invalid because I have multiple var declaration
for (var i = 0, j = myArray.length; i < j; i++) {
}
I can fix it in this way, but it looks not good
var j = myArray.length;
for (var i = 0; i < j; i++) {
}
we can bikeshed on the name, but something like this:
/*
Option: requireSafeLineBreaks
requires statements to end on an operator if split between lines
Invalid example:
var foo = "blah blah"
+ "blah blah";
Valid example:
var foo = "blah blah" +
"blah blah";
*/
According to http://usejsdoc.org/tags-type.html you can use object notation to specify param type, i.e.
@param {{foo: "bar"}} arg
Hey,
I've just discovered and started using jscs. It's an amazing tool, something that I was wanting has soo much time!
I have a few suggestions:
Rename the config file to .jscsrc
Just like JSHint (and a few other also) does: .jshintrc.
What do you think about it? The file name would get cleaner without "another" extension.
Use camelCase options
That's a major standard I think. I don't remember of JS projects which still use _ as word separator...
Don't throw AssertError if option has default value
I've created a config file for one of my projects, and jscs threw various times AssertErrors because I've setted the default value of some options; I believe this would be even simpler to you guys :)
I'll be waiting for your feedback.
Thanks in advance.
P.S.: Sorry for bad title, couldn't think of any better :(
As of JSHint 3.0, all style conformance rules are being dropped: jshint/jshint#1339 . JSCS is the perfect tool to reimplement these checks. Hopefully, all can be implemented, as this will help a lot with adoption of JSCS as the defacto style checker.
Here's all the options being dropped:
...
Hi!
Installed following version of grunt-jscs-checker:
├─┬ [email protected]
│ └─┬ [email protected]
My config file .jscs.json:
{
"requireCurlyBraces": ["for", "while", "do"],
"requireSpaceAfterKeywords": ["if", "for", "while", "do", "switch", "return"],
"requireMultipleVarDecl": true,
"disallowSpacesInsideArrayBrackets": true,
"disallowSpacesInsideParentheses": true,
"requireSpacesInsideObjectBrackets": "all",
"disallowQuotedKeysInObjects": true,
"disallowSpaceAfterObjectKeys": true,
"disallowLeftStickedOperators": ["?", "+", "-", "/", "*", "=", "==", "===", "!=", "!==", ">", ">=", "<", "<="],
"requireRightStickedOperators": ["!"],
"disallowRightStickedOperators": ["?", "+", "/", "*", ":", "=", "==", "===", "!=", "!==", ">", ">=", "<", "<="],
"requireLeftStickedOperators": [","],
"disallowKeywords": ["with", "eval"],
"disallowKeywordsOnNewLine": ["else"],
"safeContextKeyword": "self",
"validateJSDoc": {
"checkParamNames": true,
"checkRedundantParams": true,
"requireParamTypes": true
}
}Console output after grunt running:
Running "jscs:app" (jscs) task
Warning: Unsupported rules: disallowSpacesInsideParentheses, safeContextKeyword Use --force to continue.
Sadness :-(
It seems to me that we could check nextToken.type !== 'Identifier' additionally in corresponding condition.
Config:
{
"disallowLeftStickedOperators": ["-"]
}Source code:
fn(-1);Error:
Operator - should not stick to preceding expression at test.js :
1 |fn(-1);
-----------^
2 |
1 code style errors found.
Please add a rule that requires the use of tab for indentation instead of spaces (but you should still be able to use spaces inside strings).
Please add a rule that requires opening braces on new line, whenever possible. For example:
function good()
{
// body goes here
}
instead of:
function bad() {
// body goes here
}
The only case I'm aware of where this is disallowed is for returning anonymous objects:
return {
"key": value
}
Warning "Operator ! should stick to operand at example.js" keeps popping up no matter what I do to the offending line.
It looks like a false positive to me (perhaps the code doesn't account for the possibility of parenthesis to appear in that location?).
Warning:
Operator ! should stick to operand at example.js :
2 |/*global X */
3 |function foo( a, b ) {
4 | if ( !( b instanceof X.Blue ) && !X.Object.isPlainObject( b ) ){
--------------^
5 | return;
6 | }
>> 1 code style errors found!
example.js:
/*jshint unused:false */
/*global X */
function foo( a, b ) {
if ( !( b instanceof X.Blue ) && !X.Object.isPlainObject( b ) ){
return;
}
return a;
}.jscs.json:
{
"requireCurlyBraces": ["if", "else", "for", "while", "do"],
"requireSpaceAfterKeywords": ["if", "else", "for", "while", "do", "switch", "return"],
"disallowSpaceAfterPrefixUnaryOperators": ["++", "--", "+", "-", "~", "!"]
}I've tried removing and adding all kinds of spaces to try and see if that satisfies it, but it seems impossible without changing anything other than whitespace.
Please, we need it!
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Right now when setting requireSpacesInsideArrayBrackets, you can ignore on nested or require spaces everywhere.
It would be useful to be able to also ignore spaces if an object literal is provided, e.g.:
[{ foo: 'bar' }]
[{
foo: 'bar'
}, {
foo: 'bar'
}]
// but require
[ 'foo' ]
// my innocent JS code
...
/*jscs: false*/
// evil uncontrolled awful JS code
...
/*jscs: true*/
// again my beautifull JS code
...Inside /*jscs: false*/ ... /*jscs: true*/ jscs will ignore all code.
What do you think?
Extra qoutes for key at ./extended-text.js :
28 | state: {
29 |
30 | 'short': function() {
--------------------^
Reserved words: http://www.quackit.com/javascript/javascript_reserved_words.cfm
Check whether the source conforms to 2 spaces / 4 spaces / hard tabs / smart tabs (tabs for indentation, spaces for alignment) etc.
In the jQuery JavaScript style guide, whitespace is added inside various parens, round and square. A few samples:
array = [ a, b ];
foo( options, object[ property ] );For function calls, there are exceptions to this rule:
// Function with a callback, object, or array as the sole argument:
// No space on either side of the argument
foo({
a: "alpha",
b: "beta"
});
// Function with a callback, object, or array as the first argument:
// No space before the first argument
foo(function() {
// Do stuff
}, options );
// Function with a callback, object, or array as the last argument:
// No space after after the last argument
foo( data, function() {
// Do stuff
});I have no idea how much effort it is to write rules for this. Before I look into that, I'd like to hear from someone if this is reasonable and would be merged. Maybe some hints on how to implement it?
"main" property to package.json. require('jscs/lib/checker') => require('jscs');Options disallowLeftStickedOperators and disallowRightStickedOperators should not deal with : tokens between keys and values in objects.
.jscs.json:
{
"disallowSpaceAfterObjectKeys": true,
"disallowLeftStickedOperators": ["?", ":"],
"disallowRightStickedOperators": ["?", ":"]
}
log:
Operator : should not stick to preceding expression at test.js :
1 |({
2 | pampam: 'param',
------------------^
3 | param : 'pampam'
4 |});
Illegal space after key at test.js :
1 |({
2 | pampam: 'param',
3 | param : 'pampam'
-----------------^
4 |});
5 |
I think we should add a config field which can validate bad variable names.
All one- two-symbol vars, expect in-loop vars like i, j. Abstract names like item.
Lots of the rules iterate through all the tokens like this:
var tokens = file.getTokens();
for (var i = 0, l = tokens.length; i < l; i++) {
var token = tokens[i];
if (token.type === 'Keyword') {
...
}
}
I'd like to extract this out to JsFile as a function iterateTokensByType as a compliment to iterateNodesByType. Thoughts?
Perhaps something like:
/*
Option: requirePrecedingCommas
Enforces preceding commas in lists
Invalid example:
var x = {one: 1, two: 2}
Valid example:
var x = {
one: 1
, two: 2
}
*/Using the option
"requireCurlyBraces": ["case", "default", "switch"]
no warning is thrown if my code contains
switch (somevariable) {
case "a":
break;
case "b":
case "c":
break;
default:
x
}even though I'd expect it to require brackets after lines 2, 5 and 7. Correct should be:
switch (somevariable) {
case "a": {
break;
}
case "b":
case "c": {
break;
}
default: {
x
}
}Can this be added?
The following rule:
"requireSpaceAfterKeywords": ['for']
Will complain about the following code:
{for: 'bar'}
I believe this is incorrect. Object keys should be ignored for "requireSpaceAfterKeywords"
@Gissues:{"order":50,"status":"done"}
$ cat test.js
function test(ololo) {
return !! ololo;
}
$ cat .jscs.json
{
"disallow_right_sticked_operators" : [ "!" ]
}
$ jscs test.js --config .jscs.json
Operator ! should not stick to following expression at test.js :
0 |function test(ololo) {
1 | return !! ololo;
-------------------^
2 |}
3 |
1 code style errors found.
$Will I do not write "!!"? Or will jscs parse "!!" as one token and not as twice "!" ?
Hey!
I've created a Grunt plugin to apply JSCS. It's called grunt-jscs-checker.
I'd appreciate if you guys could gave some opinions on it, like, for example, how to test it - I can't figure out how!
Thanks in advance!
It would be easier to follow up on changes, if there would be a version history with changelog available. Could that be added in the readme, and/or added as tags with comments?
Configuration is nice, but having to set this on multiple project or often is a bit tedious.
It'd be super nice if jscs offered a set of predefined rules matching common styles guides like Idiomatic, Google style guide, BSD KNF, etc etc
Then you'd just have to set an option to check using the defined guide. { "style_guide": "idiomatic" }
Illegal space after `function` keyword at ./js/transport/Wrapper.js :
72 |
73 | function getKeysAndInit() {
---------------------^
74 | window.clearTimeout(getKeyTimeout);
Invalid JSDoc @param at ./js/components/validator.userphone.js
429 | * @params {...*} [args]
---------------^
This is message is incorrect because this is syntax allowed by jsdoc.
http://usejsdoc.org/tags-param.html - search Allows a parameter to be repeated
Could you consider tagging releases in git?
This would make it a lot easier to:
0.2.5:/tasks/jscs.js#L14),Thanks!
PS: Since you use npm, you may also want to use the npm-version utility to automatically edit package.json, commit it and tag it (npm-version). Plain git tag vX.X.X [<commit> works best for retroactively tagging.
users should be warned of this option as it throws code violations on negative numbers. It should instruct them to use requireSpaceAfterBinaryOperators instead.
/*
Option: disallowTrailingWhitespace
requires all lines to end on a non-whitespace character
Invalid example:
var foo = "blah blah";
Valid example:
var foo = "blah blah";
*/
In short, the option would require that all variable declarations be made at the top of their declaring scope -- where a JS interpreter would "hoist" them.
Previously, I had proposed this idea and implemented it for JSHint, but JSHint is moving away from styling entirely in V3.0, so it was not accepted. Unlike JSHint, JSCS seems like the perfect place for this sort of feature!
Rather than duplicating the detailed explanation/examples, see the issue jshint/jshint#1263 and pull request jshint/jshint#1283 for additional info and previous discussions.
This will be my first contribution to jscs, so it might take me a bit to port it over. Hopefully it won't be very different/difficult.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.