jscs-dev / node-jscs Goto Github PK
View Code? Open in Web Editor NEW:arrow_heading_up: JavaScript Code Style checker (unmaintained)
Home Page: https://jscs-dev.github.io
License: MIT License
:arrow_heading_up: JavaScript Code Style checker (unmaintained)
Home Page: https://jscs-dev.github.io
License: MIT License
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?
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;
---------------------------------------------^
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
}
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"}
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 :-(
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 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).
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?
// 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?
$ 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 "!" ?
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
.
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";
*/
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 | }
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';
*/
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 AssertError
s 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 :(
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.
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
"main"
property to package.json. require('jscs/lib/checker') => require('jscs');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
}
*/
Please, we need it!
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
users should be warned of this option as it throws code violations on negative numbers. It should instruct them to use requireSpaceAfterBinaryOperators
instead.
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 |
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' ]
Check whether the source conforms to 2 spaces / 4 spaces / hard tabs / smart tabs (tabs for indentation, spaces for alignment) etc.
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?
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?
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" }
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
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 seems to me that we could check nextToken.type !== 'Identifier'
additionally in corresponding condition.
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.
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
}
*/
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.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.
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).
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?
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 |
/*
Option: disallowTrailingWhitespace
requires all lines to end on a non-whitespace character
Invalid example:
var foo = "blah blah";
Valid example:
var foo = "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
"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++) {
}
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.
How about to fix errors automatically in special mode?
jscs . --autofix
or something
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?
Illegal space after `function` keyword at ./js/transport/Wrapper.js :
72 |
73 | function getKeysAndInit() {
---------------------^
74 | window.clearTimeout(getKeyTimeout);
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:
...
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.
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
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.