White space / Indentation checking configuration about jshint HOT 30 CLOSED

Hm, the idea is interesting but we need to figure out the best way to specify your settings. The current /*jshint ... */ declaration is unsuitable for that.

from jshint.

I'd love to see this too. Or, to put it another way, I'd like a way to check indentation and trailing whitespace alone, without all the rest.

from jshint.

Indentation (number of spaces for one level of indentation) should be adjustable (2/4/8 spaces etc.)

from jshint.

fyi @victor-homyakov - indent allows you to define the level of indentation to whatever you want it to be.

EDIT: but you need to be using the white option

from jshint.

2 neonstalwart:
this should be at least documented on the http://jshint.com/, and much better will be input field for indentation near the "Apply strict whitespace rules"

from jshint.

Hi,
I started to write such a detailed format-checker module for JSHint (besides white - so at the end white and other format control options could be deleted). As mentioned by antonkovalyov, I had to create a place for complex options, first. As always it's json, so one can define

/*jshint format: {
    tabs: {
        ...
    },
    blanks: {
        declarations: {
            ...
        },
        ...
    }
}, white: true*/

This already works great (and it's not restricted to format-options) - but it can become a really huge comment block ;)
Does anyone don't like this syntax? Other ideas? Comments?

from jshint.

Any news on this? I'd quite like to be able to use switch using the "common" style and not crockford's mandate, while retaining other whitespace options.

from jshint.

Hi,

I submitted the current status, but it's far away from ready (proof of concept). I stuck because of the work on traceur-parser (my changes rely heavily on the parser and I don't want to work twice).

For tests, see https://github.com/WolfgangKluge/jshint/tree/format-check
I have no documentation yet, but in short:
I added the option checkformat. At the end, this should be a replacement for white.

checkformat looks at the (complex) option format (as shown above)

    format: {
        indent: {
            useTabs: false,         // use tab instead of blanks
            tabSize: 4,             // indentation or size of a single tab
            firstLevel: false,      // indent first level
            caseLabel: false,       // indent case labels (including default:)
            caseContent: true,      // indent content of a case block
            label: false            // indent lables
        },

        rules: {
            needed: " ",            // e.g. before and after 'in' or after 'delete'
            common: {
                expr_dot: "",                 // x_.y()
                dot_expr: "",                 // x._y()
                expr_comma: "",               // 1_, 2
                comma_expr: " ",              // 1,_2
                label_colon: "",              // label_:
                expr_semicolon: "",           // x.y()_;
                semicolon_expr: " ",          // x.y();_x = 2
                identifier_parenthesis: " ",  // if_(, while_(, catch_( ...
                expr_parenthesis: "",         // if ( true_), ...
                parenthesis_expr: "",         // if (_true, while (_1, ...
                semicolon_semicolon: ""       // for (;_;) in empty for-statements
            },
            operators: {
                unary_expr: "",         // -_2  new, void and delete are excluded from this rule
                expr_op: " ",           // 1 +_2
                op_expr: " ",           // 1_+ 2
                name_assignment: " ",   // var x_= 2
                assignment_expr: " "    // var x =_2
            },
            block: {
                identifier_bracket: " ",    // else_{, finally_{, do_{, ...
                bracket_identifier: " ",    // }_else, }_catch, }_while, ...
                parenthesis_bracket: " ",   // function ()_{
                identifier_identifier: " "  // } else_if {
            },
            objectLiteral: {
                name_colon: "",           // x_: value
                colon_expr: " "           // x:_value
            },
            "function": {
                identifier_name: " ",             // function_x (
                name_parenthesis: "",             // function x_(
                identifier_parenthesis: " ",      // function_(    anonymous function
                parameters: {
                    parenthesis_name: "",         // function (_a)
                    name_parenthesis: "",         // function ( a_)
                    parenthesis_parenthesis: ""   // function (_)
                }

            },
            "if": {
                parenthesis_expr: "",             // if (_x )
                expr_parenthesis: "",             // if ( x_)
                identifier_parenthesis: " "       // if_( x )
            },
            "for": {
                parenthesis_expr: "",             // for (_x )
                expr_parenthesis: "",             // for ( x_)
                identifier_parenthesis: " "       // for_( 
            },
            "switch": {
                parenthesis_expr: "",             // switch (_x )
                expr_parenthesis: "",             // switch ( x_)
                case_expr: " ",                   // case_x:
                expr_colon: "",                   // case x_:
                colon_expr: " ",                  // case x:_break;
                identifier_parenthesis: " "       // switch_(
            },
            "var": {
                identifier_name: " "             // var_name
            }
        }
    }

The comments should explain what is done (I think this tree has be be ordered at the end of the work... g)
Actually, all string-properties in rules are regular expressions (even not one uses this). E.g. you can define

            "var": {
                identifier_name: " +"             // var_name
            }

to allow one ore more blanks after var-statement.

See test files in /tests/fixtures/format for examples. The file whitespace.js is allowed if white == true but results in many errors if checkformat == true.

The rules for function, if, for and var should be optional (not yet). If not present, common should be used...

If you want different rules for switch-statement, see switch.js. But you have to set option white to false.

from jshint.

+1 for this, especially "anonFnSpace: false".

from jshint.

Any updates on this? Without this I basically can't use whitespace checking since everyone on my team (including me) omits the space between "function" and its parenthesis.

I can take a crack at it if you want.

from jshint.

This fix (is we want it to be flexible) requires some substantial refactoring. We're working on that.

from jshint.

thanks!

On Dec 29, 2011, at 12:24 PM, Anton Kovalyov wrote:

This fix (is we want it to be flexible) requires some substantial refactoring. We're working on that.

---

Reply to this email directly or view it on GitHub:
#28 (comment)

from jshint.

Closing in favor of jshint-next.

from jshint.

jshint-next was merged into the main repository - i can't find any related changes.

reopen?

from jshint.

would really like to see this implemented, anyone have updates on this?

from jshint.

Also waiting for an update.
It seems unreasonable to enforce all of Crockford's indentation rules on existing large projects that use another "common" styling approach.
The key is consistency, and not one style over another.
Should be an option to tweak it.

from jshint.

+1

from jshint.

@gonsfx jshint-next is still work in progress towards release 2.0. I indeed think this would be a great feature, because I neither like the Crockford's syntax of switch/cases (maybe because of my C background… ;-) ). But definitely, we need to discuss and find a concise and elegant way to define how to handle those style options.

@antonkovalyov what would be your opinion on this for 2.0?

from jshint.

Too big for 2.0, I want to make this release ASAP.

from jshint.

+1 for that. current switch identation rules is a large PITA

from jshint.

+1 Current situation is a pain. Visual Studio editor auto-indents the 'case's, which in my view is right and proper.

from jshint.

+1

from jshint.

+1

from jshint.

+1

from jshint.

+1

from jshint.

+5

from jshint.

Apply the patch below and set the "javaswitch" option to false :-)

diff --git a/src/stable/jshint.js b/src/stable/jshint.js
index 109edb2..a91750b 100644
--- a/src/stable/jshint.js
+++ b/src/stable/jshint.js
@@ -99,6 +99,7 @@ var JSHINT = (function () {
            globalstrict: true, // if global "use strict"; should be allowed (also enables 'strict')
            immed       : true, // if immediate invocations must be wrapped in parens
            iterator    : true, // if the `__iterator__` property should be allowed
+           javaswitch  : true, // if indentation inside switch block should follow java standard
            jquery      : true, // if jQuery globals should be predefined
            lastsemic   : true, // if semicolons may be ommitted for the trailing
                                // statements inside of a one-line blocks.
@@ -3494,7 +3495,7 @@ var JSHINT = (function () {
        t = state.tokens.next;
        advance("{");
        nonadjacent(state.tokens.curr, state.tokens.next);
-       indent += state.option.indent;
+       indent += state.option.indent * (state.option.javaswitch ? 1 : 2);
        this.cases = [];

        for (;;) {
@@ -3548,7 +3549,7 @@ var JSHINT = (function () {
                advance(":");
                break;
            case "}":
-               indent -= state.option.indent;
+               indent -= state.option.indent * (state.option.javaswitch ? 1 : 2);
                indentation();
                advance("}", t);
                funct["(breakage)"] -= 1;

You can also check my fork: https://github.com/BaseCaseGmbH/jshint

from jshint.

That patch seems to fix the issue, any chance of it getting merge into the main project as this is a major pain point (otherwise I have to disable all indentation checking which eliminates a big piece of what it checks)?

from jshint.

A parameter spacing option would be greatly appreciated. There isn't a consensus between style guides (as documented by Seravo Oy's js-winning-style) and there currently isn't a way to enforce a style with JSHint.

from jshint.

JSHint is moving away from style-related checks and warnings. There's a market for that kind of tool but it won't be JSHint. See this blog post for more info: http://www.jshint.com/blog/jshint-3-plans/

from jshint.