Closed GoogleCodeExporter closed 9 years ago
This is a change we should support for the open source version of the Closure
Linter. Internally (and with anyone contributing to the Closure Tools) we don't
want to allow suppression of errors as it allows ignoring a part of the Google
JavaScript Style Guide. But, not everyone using this tool is following our
style guide completely.
Original comment by a...@google.com
on 12 Nov 2010 at 5:58
I think so too - it will be very cool to disable (or increase) line length.
I'll wait for such functionality.
Original comment by ua.and...@gmail.com
on 3 Feb 2011 at 5:35
Hmm.. Google still doing code reviews with pen and paper? ;)
+1 Ability to set custom line length.
Original comment by peter.su...@gmail.com
on 24 Feb 2011 at 1:01
Created a small patch which hardcodes a new max line length.
Original comment by peter.su...@gmail.com
on 24 Feb 2011 at 2:13
Attachments:
Thanks for this patch - worked well! :)
But it will be good to have a possibility to pass it as parameter (or turn off
checking at all).
Original comment by ua.and...@gmail.com
on 24 Feb 2011 at 2:32
I've created a patch that does this: http://codereview.appspot.com/4291044/
It adds --ignore_errors which takes a comma-separated list of the integer error
numbers (i.e. 110, not E0110).
Original comment by ibmirkin@gmail.com
on 12 Mar 2011 at 7:54
Thanks, worked as expected!
One note: parameters must be passed before the path, e.g.:
c:\gjslint --ignore_errors 110,5 D:\project\*.js
Original comment by ua.and...@gmail.com
on 14 Mar 2011 at 9:32
[deleted comment]
It would be nice for this to be an official patch. What is the philosophy
behind throwing an error for lines exceeding 80 chars in length?
Original comment by ra...@gamzee.com
on 6 Sep 2011 at 6:55
The bottom line to the philosophy question is because that's what Google's JS
style guide says is the limit. This page has some good explanations about how
the limit came about, and arguments for and against it:
http://programmers.stackexchange.com/questions/100392/should-we-keep-the-80-char
acter-per-line-limit-in-java-code
Original comment by JayYoung...@gmail.com
on 6 Sep 2011 at 4:19
Since this seems to be personal preference, it seems to be it should be a
warning at best, if gjslint differentiates between warnings and errors.
Original comment by ra...@gamzee.com
on 6 Sep 2011 at 7:43
I agree too.
Sometimes I don't need limit width.
Or I have specific requirements.
So I want change/disable this error (or maybe others too) by code.
Original comment by ua.and...@gmail.com
on 7 Sep 2011 at 7:32
Reasonable programmers can disagree with style guidelines like maximum line
length. Different environments also impose different requirements. Given
this, I vote for merging in the patch that allows selectively ignoring
particular errors.
Original comment by t...@animoto.com
on 11 Nov 2011 at 7:14
Issue 38 has been merged into this issue.
Original comment by a...@google.com
on 7 Mar 2012 at 12:06
I've created a wrapper that allows disabling specific errors without modifying
the closure-linter source code. See here for details:
http://kewisch.wordpress.com/2012/07/28/disable-specific-error-messages-in-closu
re-linter/
Original comment by kewi...@gmail.com
on 28 Jul 2012 at 10:47
--disable Disable specific error. Usage Ex.: gjslint --disable 1,0011 foo.js.
--max_line_length Maximum line length allowed without warning.
Original comment by vagra...@google.com
on 29 Jul 2013 at 8:01
Original comment by vagra...@google.com
on 29 Jul 2013 at 8:17
Original issue reported on code.google.com by
guil...@gmail.com
on 8 Nov 2010 at 12:24