new rule: require/disallow "Title Case" for parameter types

[hzoo]

* @param {Array} arr vs. * @param {array} arr

maybe an exception for string, number, etc?

[qfox]

I think we need to add some value for checkType rule. Something like capitalizedNatives or titleCasedNatives and lowerCasedNatives.

[qfox]

@hzoo What you prefer? Natives or primitives?

[qfox]

new value: strictNativeCase forces func-ty to test case of native types. Primitives (string, number, boolean) should be lowercased, objects (Object, Array, Date, RegExp) should be capitalized (or PascalCased).

@hzoo All is right?

[hzoo]

yeah that sounds good!

[qfox]

@hzoo Great. I'll release it today

[qfox]

@hzoo Merged and published as v0.1.0 ;-) Thanks!

[tunnckoCore]

Primitives (string, number, boolean) should be lowercased

There's no logic for me. I'm for all PascalCased. Maybe more values would be better.

Btw, where you see this style? refs?

[qfox]

Everywhere. Number is an Object for primitive number. As well as String for string and Boolean for boolean.

For example:

b = new Boolean(true);
typeof b; // object
typeof Boolean(b); // boolean — lowercased.

That's why ;-)

[qfox]

Anyway, seems like we need to patch this. The simplest way is to add one more rule value for all PascalCased. Would capitalizedNatives be fine?

[tunnckoCore]

Everywhere. Number is an Object for primitive number. As well as String for string and Boolean for boolean.

Everywhere.. Actually, I don't see it in js community, sometimes in php is all lowercased.. but very rarely.

Would capitalizedNatives be fine?

Yea.

[tunnckoCore]

btw, is there any auto type-hinting for sublime for js?

[qfox]

Really. I don't know ;-)

I mean, if you executing typeof 5 and it returns lowercased 'number' then it IS on each js platform. So yeah, it's everywhere.

[tunnckoCore]

I know that. I talk for that the param type corresponds to what you expect to come from argument, not what returns function. And in every project you can see docblocks with defined PascalCased param types.

But okey, maybe religion. It would be good to have rules. :D

[qfox]

Anyway this talk about number vs Number for me like primitive vs ObjectType.

And yes, much easier to make a separate mode for this instead of talking each time about preferences. Almost done.

[qfox]

Btw, lowercased primitives in google compiler docs: https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-define

[qfox]

Sorry for delay. Merged and published as 0.2.0 with pluginization. Thanks guys!

[tunnckoCore]

@zxqfox awesome. :) What is the naming convention? about

{
    "plugins": [
        "jscs-jsdoc"
    ],
    "jsDoc": {
        "enforceExistence": true
    }
}

If i create jscs-pluginName what will be the rule for it? By this jscs-jsdoc -> jsDoc i can guess there's no naming convention? It would be good to be same as plugin name withou jscs- prefix and camel-cased if - using this https://github.com/sindresorhus/camelcase?

[qfox]

@tunnckoCore Anything you define in ./lib/rules/rule.js file in result of getOptionName. Take a look at https://github.com/jscs-dev/node-jscs/wiki/Plugin-API

There is a weak part with nested rules and with browserifying. All other is pretty good already.

[tunnckoCore]

Oh, yea, sorry. btw last, lol, could you add @api tag? im surprised of that..

Yea, I know we can add custom with extra object, but.. for one tag that is also common

[qfox]

@tunnckoCore About @api: which standard describes it? Can't find.

We can discuss about creating some common preset of jsdoc tags just to minimize negative impact of first use. But I want to left existing presets clean.