[Prototype-core] Re: Add JavaScript Lint to build process?
Please note that I didn't mean to imply that Prototype should adhere
to every warning and suggestiong that JSLint emits. IMHO, many of
them add little/no value and can safely be ignored. But missing semi-
colons, and ambiguous if-else blocks (for example) are the sorts of
things that should probably get cleaned up.
FWIW, here's what our jsl warnings configurations look like As you
can see, I've disabled a bunch of stuff that just didn't add much
value for our team:
-no_return_value # function {0} does not always return a
value
+duplicate_formal # duplicate formal argument {0}
-equal_as_assign # test for equality (==) mistyped as
assignment (=)?{0}
+var_hides_arg# variable {0} hides argument
-redeclared_var # redeclaration of {0} {1}
-anon_no_return_value # anonymous function does not always
return a value
+missing_semicolon# missing semicolon
+meaningless_block# meaningless block; curly braces have
no impact
+comma_separated_stmts# multiple statements separated by
commas (use semicolons?)
+unreachable_code # unreachable code
-missing_break# missing break statement
-missing_break_for_last_case # missing break statement for last case
in switch
-comparison_type_conv # comparisons against null, 0, true,
false, or an empty string allowing implicit type conversion (use ===
or !==)
-inc_dec_within_stmt # increment (++) and decrement (--)
operators used as part of greater statement
+useless_void # use of the void type may be
unnecessary (void is always undefined)
+multiple_plus_minus # unknown order of operations for
successive plus (e.g. x+++y) or minus (e.g. x---y) signs
+use_of_label # use of label
-block_without_braces # block statement without curly braces
-leading_decimal_point# leading decimal point may indicate a
number or an object member
+trailing_decimal_point # trailing decimal point may indicate a
number or an object member
+octal_number # leading zeros make an octal number
+nested_comment # nested comment
-misplaced_regex # regular expressions should be preceded
by a left parenthesis, assignment, colon, or comma
-ambiguous_newline# unexpected end of line; it is
ambiguous whether these lines are part of the same statement
-empty_statement # empty statement or extra semicolon
-missing_option_explicit # the option explicit control comment
is missing
+partial_option_explicit # the option explicit control comment,
if used, must be in the first script tag
+dup_option_explicit # duplicate option explicit control
comment
+useless_assign # useless assignment
-ambiguous_nested_stmt# block statements containing block
statements should use curly braces to resolve ambiguity
+ambiguous_else_stmt # the else statement could be matched
with one of multiple if statements (use curly braces to indicate
intent)
-missing_default_case # missing default case in switch
statement
+duplicate_case_in_switch # duplicate case in switch statements
+default_not_at_end # the default case is not at the end of
the switch statement
+legacy_cc_not_understood # couldn't understand control comment
using /*...@keyword@*/ syntax
+jsl_cc_not_understood# couldn't understand control comment
using /*jsl:keyword*/ syntax
+useless_comparison # useless comparison; comparing
identical expressions
+with_statement # with statement hides undeclared
variables; use temporary variable instead
+trailing_comma_in_array # extra comma is not recommended in
array initializers
+assign_to_function_call # assignment to a function call
-parseint_missing_radix # parseInt missing radix parameter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
Oh! You're talking about JavaScript Lint, not JSLint... maybe we could
agree on a set of warnings and publish that on the website.
Best,
Tobie
On Mar 27, 1:06 pm, Robert Kieffer bro...@gmail.com wrote:
Please note that I didn't mean to imply that Prototype should adhere
to every warning and suggestiong that JSLint emits. IMHO, many of
them add little/no value and can safely be ignored. But missing semi-
colons, and ambiguous if-else blocks (for example) are the sorts of
things that should probably get cleaned up.
FWIW, here's what our jsl warnings configurations look like As you
can see, I've disabled a bunch of stuff that just didn't add much
value for our team:
-no_return_value # function {0} does not always return a
value
+duplicate_formal # duplicate formal argument {0}
-equal_as_assign # test for equality (==) mistyped as
assignment (=)?{0}
+var_hides_arg # variable {0} hides argument
-redeclared_var # redeclaration of {0} {1}
-anon_no_return_value # anonymous function does not always
return a value
+missing_semicolon # missing semicolon
+meaningless_block # meaningless block; curly braces have
no impact
+comma_separated_stmts # multiple statements separated by
commas (use semicolons?)
+unreachable_code # unreachable code
-missing_break # missing break statement
-missing_break_for_last_case # missing break statement for last case
in switch
-comparison_type_conv # comparisons against null, 0, true,
false, or an empty string allowing implicit type conversion (use ===
or !==)
-inc_dec_within_stmt # increment (++) and decrement (--)
operators used as part of greater statement
+useless_void # use of the void type may be
unnecessary (void is always undefined)
+multiple_plus_minus # unknown order of operations for
successive plus (e.g. x+++y) or minus (e.g. x---y) signs
+use_of_label # use of label
-block_without_braces # block statement without curly braces
-leading_decimal_point # leading decimal point may indicate a
number or an object member
+trailing_decimal_point # trailing decimal point may indicate a
number or an object member
+octal_number # leading zeros make an octal number
+nested_comment # nested comment
-misplaced_regex # regular expressions should be preceded
by a left parenthesis, assignment, colon, or comma
-ambiguous_newline # unexpected end of line; it is
ambiguous whether these lines are part of the same statement
-empty_statement # empty statement or extra semicolon
-missing_option_explicit # the option explicit control comment
is missing
+partial_option_explicit # the option explicit control comment,
if used, must be in the first script tag
+dup_option_explicit # duplicate option explicit control
comment
+useless_assign # useless assignment
-ambiguous_nested_stmt # block statements containing block
statements should use curly braces to resolve ambiguity
+ambiguous_else_stmt # the else statement could be matched
with one of multiple if statements (use curly braces to indicate
intent)
-missing_default_case # missing default case in switch
statement
+duplicate_case_in_switch # duplicate case in switch statements
+default_not_at_end # the default case is not at the end of
the switch statement
+legacy_cc_not_understood # couldn't understand control comment
using /*...@keyword@*/ syntax
+jsl_cc_not_understood # couldn't understand control comment
using /*jsl:keyword*/ syntax
+useless_comparison # useless comparison; comparing
identical expressions
+with_statement # with statement hides undeclared
variables; use temporary variable instead
+trailing_comma_in_array # extra comma is not recommended in
array initializers
+assign_to_function_call # assignment to a function call
-parseint_missing_radix # parseInt missing radix parameter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
I'm glad Robert brought up this subject. I asked about this on IRC a while back and the answer was that prototype was hand-crafted, is beautiful the way it is, and that modifying it to pass strict syntax checking would somehow make it slower... I agree that there is some beautiful code in prototype but that's not a good enough reason for not being able to use jslint to find real bugs. And this issue is especially painful when I'm passing a large file consisting of several concatenated scripts to jslint ... since many of them rely on prototype, and it's at the beginning, I cannot see results for my own scripts because jslint will stop after too many (harmless) errors in prototype. For now, I'm running the various scripts through jslint separately. My justification for cleaning up prototype's code is that in some places the craftiness exceeds utility, and that prototype's awesomeness will only increase if the source code also passes basic software quality tests. For example, a statement like var result = value1, value2; there's really no need to use the comma operator with an assignment. Only one of the values will be assigned, and it's better to move the side-effect code into a separate statement where it will be easier to read. There are volumes written about avoiding errors by not writing code like that in the first place. You either believe it or you don't, I guess. If the core developers aren't interested in anyone contributing strict fixes, does anyone have thoughts about maintaining a separate strict version of prototype? Either way I volunteer to make a first pass at it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
Just had another thought -- it's possible to satisfy proponents of both strict coding and quick downloads. Given a strictly written program, it's possible to write a transformation to apply all the syntax shortcuts to it and produce an equivalent lean version with minimum whitespace and punctuation. So if this were the process, everyone would win. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
2009/3/15 Tobie Langel tobie.lan...@gmail.com:
I wonder why Caja is taken in so much more consideration than a
practice that always existed in the programming world.
There's two reasons to that:
1. I've been consulting for Google Caja team to make Prototype Caja-
compliant,
2. Valija[1], the language which was created by the Google Caja team
as a result of that work[2], is an approximate subset of the ES3.1
strict mode, so supporting it today means supporting strict mode
tomorrow.
Best,
Tobie
[1] http://code.google.com/p/google-caja/wiki/WhatsMissing
[2]
http://groups.google.com/group/google-caja-discuss/browse_thread/thread/284935fa0784316d/31e476a985ae8c66?lnk=gst#31e476a985ae8c66
Is there any evidence that NOT being strict is slower for a non-strict
environment?
Does missing a few {} or the odd ; in allowable places make the parser
have more work to do?
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
Is there any evidence that NOT being strict is slower for a non-strict
environment?
huh?
Does missing a few {} or the odd ; in allowable places make the parser
have more work to do?
That's implementation specific.
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
I wonder why Caja is taken in so much more consideration than a practice that always existed in the programming world. There's two reasons to that: 1. I've been consulting for Google Caja team to make Prototype Caja- compliant, 2. Valija[1], the language which was created by the Google Caja team as a result of that work[2], is an approximate subset of the ES3.1 strict mode, so supporting it today means supporting strict mode tomorrow. Best, Tobie [1] http://code.google.com/p/google-caja/wiki/WhatsMissing [2] http://groups.google.com/group/google-caja-discuss/browse_thread/thread/284935fa0784316d/31e476a985ae8c66?lnk=gst#31e476a985ae8c66 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
Some of those have been fixed in my branch for Caja compliance. On Mar 12, 11:10 pm, Robert Kieffer bro...@gmail.com wrote: Would it be worth doing some sort of javascript lint'ing as part of the 'dist' or 'test' tasks? ... or as part of whatever the final release processis? When I run http://www.javascriptlint.comagainst 1.6.0.3 or trunk, even using a fairly conservative config, I see a healthy dose of warnings (included below). In addition to dozens of 'missing semicolon' warnings, I also see stuff like this (on latest trunk dist): prototype.js|450| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|2206| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|2745| lint warning: the else statement could be matched with one of multiple if statements (use curly braces to indicate intent) prototype.js|3269| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|3577| warning: variable nodes hides argument prototype.js|3932| lint warning: multiple statements separated by commas (use semicolons?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
