Tab indentation option / line length option

[Y@]

Hi,

Happy New Year!
May 2011 bring nice optimization ideas to all of you :o)...

First, I'd like to say "Nice job with these new tools!!! Very great
they are... useful !"

May I suggest an option to the Closure Linter for the "E:0005: Illegal
tab..." warning :
It might be interesting to choose an indentation style made of
tabulations by switching on an option (like --[no]tab-indentation :
default to false)

In that case :
- tabs could be use only at first place on each line, and before any
other character ;
- the next character could be one - then, only one - whitespace just
before - and only before - a star (for JsDocs) ;

OK Example :
[TAB]/**
[TAB][SP]* Some explanation.
[TAB][SP]*/
[TAB]function test() {
[TAB][TAB]someCode();
[TAB]}

Wrong Examples :
[TAB][SP]function test() { // wrong
[TAB][SP][TAB]some_code(); // wrong
[TAB][SP]} // wrong

[TAB][TAB]var[TAB]myVar; // wrong

---------------------------------------------------------
One another option could be interesting for the "E:0110: Line too
long" warning :
we might want to choose as well, how many characters we want to accept
for each line
(ie. --max-line-length=LENGTH : default to 80 and 0 for unlimited)
---------------------------------------------------------

FYI... My validation reference is the JSLint validation tool which
accepts the tab spaces...
(with most of the strict options activated, including 'use strict';
statement)
(JSLint by Douglas Crockford : http://jslint.com/)

++
Y@

[Andy Perelson]

Google's JavaScript style (and other languages as well I believe) is fairly explicit that no tabs should be in our files. The reasoning being that there is no official standard that I know of on how many spaces a tab is, and with engineers using many, many different editors we want the code to be readable in all of them despite differences in tab interpretation. You're welcome to track this as a feature request on the linter issues list (http://code.google.com/p/closure-linter/issues/list), but it would be very low priority for anyone at Google. Hopefully at some point we can make it easy to accept third party contributions in which case something like this could be added by people like yourself who really want it.

Line length falls under the same bucket, that we don't need it within Google as we use the linter to specifically enforce our style guide which only allows 80 character lines (with some special exceptions for long urls, etc.). However, that should be fairly trivial to implement, so a bit more likely that it'd get done.

Andy

[Guido Tapia]

One vote from me on customizable line length.  (No issue on the item list to 'add to favourites' yet) but yeah 80 chars seems a bit 90's, I mean when was the last time anyone printed out code?

[Y@]

Very surprising reactivity...
Thanks a lot for the answer ^^ !

I understand your point... I'll think about what you wrote ;o).
I've already produced some external "patches" (some little easy shell
things) for my personal use.
(for the "var;" problem and the tab/lineLength warns)

Once again, nice job !
Have a lot of fun :P !
Y@

[gcc]

Hi all,

On Thu, Jan 6, 2011 at 4:42 AM, Y@ <yga...@gmail.com> wrote:

May I suggest an option to the Closure Linter for the "E:0005: Illegal
tab..." warning :
It might be interesting to choose an indentation style made of
tabulations by switching on an option (like --[no]tab-indentation :
default to false)

On Thursday, January 6, 2011 6:37:20 PM UTC, ajp wrote: 

Google's JavaScript style (and other languages as well I believe) is fairly explicit that no tabs should be in our files. The reasoning being that there is no official standard that I know of on how many spaces a tab is, and with engineers using many, many different editors we want the code to be readable in all of them despite differences in tab interpretation. You're welcome to track this as a feature request on the linter issues list (http://code.google.com/p/closure-linter/issues/list), but it would be very low priority for anyone at Google. Hopefully at some point we can make it easy to accept third party contributions in which case something like this could be added by people like yourself who really want it.

I would really like it. Some people just like tabs, and I'm one of them. Perhaps the linter was never intended to be used on non-Google code, but if Google is not interested in making it a bit more flexible (at least having an option to disable certain warnings) then why open source it in the first place? What possible use could it have to people outside of Google in that case?

Cheers, Chris.

[Alexander Kulik]

Adding such thing like  --max-line-length=LENGTH is so easy for Googlers. 

But sadly, seems @ajp prefers spend time with arrogant answers liker here or here

[Johannes Nel]

i have to say arrogant seems a far cry from that reply, i quote:

I hear you guys, and I see the value of what you're asking. I'd love for the Closure Linter to really support the use cases of our entire community. But I personally haven't had the time to make this happen, and I don't know of anyone else who has

and

Thus to implement this, we need to implement it in such a way that we allow external users of the Closure Linter can configure max line length, potentially turn off errors, etc. but we don't want to allow this internally

a perfectly valid reply really. They share their tools which we love. We abide by their rules since we are too lazy to extend them ourselves, nobody is stopping you from changing this and sharing it.

On Wed, Nov 21, 2012 at 4:11 AM, Alexander Kulik <askt...@gmail.com> wrote:

Adding such thing like  --max-line-length=LENGTH is so easy for Googlers. 

But sadly, seems @ajp prefers spend time with arrogant answers liker here or here

--
j:pn
\\no comment

[Igor DeFaye]

I agree it would be really good to have such options. 

When working with an existing code base, it is very difficult to deal with thousands of line with tabulation error. 

I think handling it the way phpcs does is a good alternative. Just add how many spaces you want to replace your tabulation with, then when code check is done true indentation problems appear. Of course it implies that all the team members use the same tab-to-space conversion, but normally this rule should already exists if this was the convention chosen by then.

Regarding comments it should also be an option: all teams do not use the same convention. Especially now that screen are usually 16/9 and resolution keeps growing, a limit of 80 is very small: you don't scroll horizontally anymore but do a lot more vertically scroll.

An other interesting option would be to exclude some files or repertory when checking an entire directory. Sometimes your code needs external libraries and you want to exclude them from the checks.

[Johannes Nel]

Hi

I was going to say that the linter is about the most static of all the tools in the closure toolsset,  but found several recent commits. I do think however if you are going to branch one of the tools and it won't be absorbed back into the fold the linter would be the one to do, the others would become a hassle.

J

On Tue, Mar 26, 2013 at 11:32 PM, Justin Akehurst <akeh...@gmail.com> wrote:

On Thursday, January 6, 2011 10:37:20 AM UTC-8, ajp wrote:

Line length falls under the same bucket, that we don't need it within Google as we use the linter to specifically enforce our style guide which only allows 80 character lines (with some special exceptions for long urls, etc.). However, that should be fairly trivial to implement, so a bit more likely that it'd get done.

Andy

Say that someone wanted to plumb in a way to configure the line length as an option, and leave 80 as the default, so that Google code compliance still works.

Would that be acceptable? How receptive is the community and the Google Linter team to outside suggested patches and features to enable this functionality, granted that we follow all of the Google Python style guidelines for submitting a diff to add this functionality?

Our team here at EMC Isilon is looking at JavaScript frameworks to replace the one that we are currently using, and we are greatly impressed by the toolset of the Closure Tools. If our team were to add in some conveniences to this tool, and to other tools, for the greater use of the community and for our own needs, would this be accepted?

I would like to avoid forking the library just to add in features that we would need. Would love to know if there is a process that can be followed for contributing to this code and making this a better tool for everyone's use.

-Justin Akehurst

--
You received this message because you are subscribed to the Google Groups "Closure Linter Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-linter-di...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andy Perelson]

Unfortunately features that we want to support for the open source Closure Linter but not internally are not ones that can easily be contributed by the open source community. We'd want it to be coded in a way that internal usage really is impossible and you don't see all the code you'd need to touch to do that. Line length adjustment falls into that category. But we've been under some relatively active development internally lately and I have hopes that there is someone who'd be willing to take on line-length adjustment for open source. So hopefully we can get to that feature request.

As for the static-ness of the Closure Linter code base... I think it's fairly static right now. There are dreams of implementing / using a real grammar & parser so that we could fix a lot of issues with missing semi-colon and indentation checking. Doing that could dramatically change the code base but I don't know when it will happen. Till then you can expect it to be pretty stable though.

If you have really small patches feel free to send us diffs via feature request or bug report, but we haven't set up really accepting open source contributions yet.

Andy