Hi guys,

I was coding and I noticed that I often make the same error from using reduce.

e.g.

var options = ['nocaps', 'evil', 'node', 'browser'],
  optionsAsObject = options.reduce(function (options, item) {
   options[item] = true;
  }, {});

// When it should be:
var options = ['nocaps', 'evil', 'node', 'browser'],
  optionsAsObject = options.reduce(function (options, item) {
   options[item] = true;
   return options;
  }, {});

Functions have a default/implied return value of undefined, this means if the
array has more than one item this will throw an error.

I'm suggesting that if the reduce method is invoked with a non primative second
argument and function's first argument has an assignment to its property, there
must be an explicit return value.

e.g.

options.reduce(function (options, item) {
  // first argument is modified
  options[item] = true;

  // Missing return value
}, {}); // reduce is invoked with non primative second argument

Feedback guys?

--- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@...> wrote:
>
> Hi guys,
>
> I was coding and I noticed that I often make the same error from using reduce.
>
> e.g.
>
> var options = ['nocaps', 'evil', 'node', 'browser'],
>  optionsAsObject = options.reduce(function (options, item) {
>   options[item] = true;
>  }, {});
>
> // When it should be:
> var options = ['nocaps', 'evil', 'node', 'browser'],
>  optionsAsObject = options.reduce(function (options, item) {
>   options[item] = true;
>   return options;
>  }, {});
>
> Functions have a default/implied return value of undefined, this means if the
array has more than one item this will throw an error.
>
> I'm suggesting that if the reduce method is invoked with a non primative
second argument and function's first argument has an assignment to its property,
there must be an explicit return value.
>
> e.g.
>
> options.reduce(function (options, item) {
>  // first argument is modified
>  options[item] = true;
>
>  // Missing return value
> }, {}); // reduce is invoked with non primative second argument


I think the error may be that you are using the wrong method: reduce when you
should forEach.  I am not sure how to test for that.

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@> wrote:
> >
> > Hi guys,
> >
> > I was coding and I noticed that I often make the same error from using
reduce.
> >
> > e.g.
> >
> > var options = ['nocaps', 'evil', 'node', 'browser'],
> >  optionsAsObject = options.reduce(function (options, item) {
> >   options[item] = true;
> >  }, {});
> >
> > // When it should be:
> > var options = ['nocaps', 'evil', 'node', 'browser'],
> >  optionsAsObject = options.reduce(function (options, item) {
> >   options[item] = true;
> >   return options;
> >  }, {});
> >
> > Functions have a default/implied return value of undefined, this means if
the array has more than one item this will throw an error.
> >
> > I'm suggesting that if the reduce method is invoked with a non primative
second argument and function's first argument has an assignment to its property,
there must be an explicit return value.
> >
> > e.g.
> >
> > options.reduce(function (options, item) {
> >  // first argument is modified
> >  options[item] = true;
> >
> >  // Missing return value
> > }, {}); // reduce is invoked with non primative second argument
>
>
> I think the error may be that you are using the wrong method: reduce when you
should forEach.  I am not sure how to test for that.
>

No, I know when to use each method.

Ill try to give another example, the JSLint source uses a method named
array_to_object, which can be re-written like this:

function array_to_object(array, value) {
  return array.reduce(function (object, key) {
   object[key] = value;
   return object; //I forget this line allot
  }, {});
}

I suspect that the reduce method is used like this commonly, and I often forget
to type the "return object;" statement.

This is why the function passed into array.reduce should have an
explicit return value.

--- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@...> wrote:
>
>
>
> --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@> wrote:
> > >
> > > Hi guys,
> > >
> > > I was coding and I noticed that I often make the same error from using
reduce.
> > >
> > > e.g.
> > >
> > > var options = ['nocaps', 'evil', 'node', 'browser'],
> > >  optionsAsObject = options.reduce(function (options, item) {
> > >   options[item] = true;
> > >  }, {});
> > >
> > > // When it should be:
> > > var options = ['nocaps', 'evil', 'node', 'browser'],
> > >  optionsAsObject = options.reduce(function (options, item) {
> > >   options[item] = true;
> > >   return options;
> > >  }, {});
> > >
> > > Functions have a default/implied return value of undefined, this means if
the array has more than one item this will throw an error.
> > >
> > > I'm suggesting that if the reduce method is invoked with a non primative
second argument and function's first argument has an assignment to its property,
there must be an explicit return value.
> > >
> > > e.g.
> > >
> > > options.reduce(function (options, item) {
> > >  // first argument is modified
> > >  options[item] = true;
> > >
> > >  // Missing return value
> > > }, {}); // reduce is invoked with non primative second argument
> >
> >
> > I think the error may be that you are using the wrong method: reduce when
you should forEach.  I am not sure how to test for that.
> >
>
> No, I know when to use each method.
>
> Ill try to give another example, the JSLint source uses a method named
> array_to_object, which can be re-written like this:
>
> function array_to_object(array, value) {
>  return array.reduce(function (object, key) {
>   object[key] = value;
>   return object; //I forget this line allot
>  }, {});
> }
>
> I suspect that the reduce method is used like this commonly, and I often
forget to type the "return object;" statement.
>
> This is why the function passed into array.reduce should have an
> explicit return value.


function array_to_object(array) {
     var result = {};
     array.forEach(function (key) {
         result[key] = true;
     });
     return result;
}

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
>
>
> --- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@> wrote:
> >
> >
> >
> > --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> > >
> > > --- In jslint_com@yahoogroups.com, "rodobrist" <roderickobrist@> wrote:
> > > >
> > > > Hi guys,
> > > >
> > > > I was coding and I noticed that I often make the same error from using
reduce.
> > > >
> > > > e.g.
> > > >
> > > > var options = ['nocaps', 'evil', 'node', 'browser'],
> > > >  optionsAsObject = options.reduce(function (options, item) {
> > > >   options[item] = true;
> > > >  }, {});
> > > >
> > > > // When it should be:
> > > > var options = ['nocaps', 'evil', 'node', 'browser'],
> > > >  optionsAsObject = options.reduce(function (options, item) {
> > > >   options[item] = true;
> > > >   return options;
> > > >  }, {});
> > > >
> > > > Functions have a default/implied return value of undefined, this means
if the array has more than one item this will throw an error.
> > > >
> > > > I'm suggesting that if the reduce method is invoked with a non primative
second argument and function's first argument has an assignment to its property,
there must be an explicit return value.
> > > >
> > > > e.g.
> > > >
> > > > options.reduce(function (options, item) {
> > > >  // first argument is modified
> > > >  options[item] = true;
> > > >
> > > >  // Missing return value
> > > > }, {}); // reduce is invoked with non primative second argument
> > >
> > >
> > > I think the error may be that you are using the wrong method: reduce when
you should forEach.  I am not sure how to test for that.
> > >
> >
> > No, I know when to use each method.
> >
> > Ill try to give another example, the JSLint source uses a method named
> > array_to_object, which can be re-written like this:
> >
> > function array_to_object(array, value) {
> >  return array.reduce(function (object, key) {
> >   object[key] = value;
> >   return object; //I forget this line allot
> >  }, {});
> > }
> >
> > I suspect that the reduce method is used like this commonly, and I often
forget to type the "return object;" statement.
> >
> > This is why the function passed into array.reduce should have an
> > explicit return value.
>
>
> function array_to_object(array) {
>     var result = {};
>     array.forEach(function (key) {
>         result[key] = true;
>     });
>     return result;
> }
>

Ok, thanks Doug. I suppose that construct is less prone to errors.

There appears to be a new rule that looks for unnecessary parenthesis, but this
rule gets confused when wrapping regex:

var mhtml = true,
     disqualify = (mhtml) ? (/^(\s?<((pre)|(script)))/) : (/^(\s?<script)/);

For safety regular expressions not used in or with a method I typically wrap in
parenthesis because some software can get confused as to where the regular
expression syntax ends.  Everywhere else in my code the excess parenthesis rule
is happy to allow me to wrap regex, except when the regex also contains
parenthesis.

Thanks,
Austin

--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:

> There appears to be a new rule that looks for unnecessary parenthesis, but
this rule gets confused when wrapping regex:
>
> var mhtml = true,
>     disqualify = (mhtml) ? (/^(\s?<((pre)|(script)))/) : (/^(\s?<script)/);
>
> For safety regular expressions not used in or with a method I typically wrap
in parenthesis because some software can get confused as to where the regular
expression syntax ends.  Everywhere else in my code the excess parenthesis rule
is happy to allow me to wrap regex, except when the regex also contains
parenthesis.


I completely agree. It is wise to wrap regexp literals in parens to avoid
syntactic weirdness. But that is not what JSLint is complaining about. Try this:

var mhtml = true,
     disqualify = mhtml ? (/^(\s?<((pre)|(script)))/) : (/^(\s <script)/);

Thank you!

Austin

I’ve run into an error that is a bit strange to see. The <summary> tag is not
allowed as it is unrecognized however the <details> tag is allowed. I’ve updated
my own copy of JSLint and Brackets (Addition at line 828: “summary:  {parent: '
details '},”) but this would be a great addition to the project too now that
Chrome and Safari both support it. Although Safari still doesn’t have it within
their official documentation, it does use the same method that Chrome does.

--- In jslint_com@yahoogroups.com, Matthew Potter <mdpotter@...> wrote:
>
> I've run into an error that is a bit strange to see. The <summary> tag is not
allowed as it is unrecognized however the <details> tag is allowed. I've updated
my own copy of JSLint and Brackets (Addition at line 828: "summary:  {parent: '
details '},") but this would be a great addition to the project too now that
Chrome and Safari both support it. Although Safari still doesn't have it within
their official documentation, it does use the same method that Chrome does.


Thanks. Please try it now.

Unexpected '*'.

Rationale for acceptance:

The * selector in CSS, also known as the universal selector, is useful for
setting styling to the full array of possible tags and all descendants of an
ancestor without having to be verbose about the DOM tree involved.

One common use is
* {font-family:<fonts>;}

Restrictions that are reasonable
When naked the * selector should be the 1st line within a style block, as this
applies to all elements regardless of location in the DOM tree. When clothed the
* may not be the first selector indicated unless html is the second (this is to
accommodate common CSS hacks for IE, yes we all hate that blasted bane.)

invalid: * <additional selector(s) except html>
valid: * html {css hacks}
valid: body * {}

Would also like to see CSS 3.0 style attributes added as modern browsers now
support them. And those that don't can have graceful fallback.

--- In jslint_com@yahoogroups.com, "george_weilenmann"  wrote:
>
> Would also like to see CSS 3.0 style attributes added as modern browsers now
support them. And those that don't can have graceful fallback.


Can you be more specific?

Directives Missing
@media
@keyframes FF 16+, IE 10, Opera 12.10; Chrome, Android, Safari 4, Opera 12, with
prefix,
@import [url] list-of-media-queries  the @import works currently only for [url],
list-of-media-queries aids in RWD.
@page used to make printing style adjustment most useful for printable material.
While there are a few others they do not yet have widespread support and are
considered experimental or highly experiemental


Selectors missing

* universal
E[attr|="val"] attribute contains hyphenated values example span tag with lang
attribute having value en-us
:only-child pseudo
:lang(fr) `this one looks like it has some support in JSLint but is buggy when
you have language code present it throws 'Expected ')' and instead saw 'fr'.'
and when missing states expected language code.`
all 4 pseudo elements ::first-line ::first-letter ::before ::after

E ~ F sibling selector

CSS 3 Missing properties
Multiple values on
background-image & background-position, strangely background-origin already
supports this in JSLint.
background-repeat, additionally the values round and space throw an error.

CSS 3 values

calc is either fully supported or supported with prefix. This one being quite
useful for some styles of RWD.
hsl(0-360, 0-100%, 0-100%) & hsla(0-360, 0-100%, 0-100%, 0.0-1.0) both have
support in modern browsers.
CSS Gradients (specs http://www.w3.org/TR/css3-images/#gradients)
rem units for length (spec http://www.w3.org/TR/css3-values/#rem-unit)

Prefixes
While prefixes are not an Ideal, they do allow for experimentation and
presenting more advanced items where supported. FF finally adopted the -webkit-
in conjunction with -moz- prefix; again graceful failure can be done here. Top 4
prefixes in use are -webkit-, -ms-, -moz-, -o- listed current market share order
as listed in the use log of Wikimedia Oct 2012.

That looks like a good start. As time permits I will look for others that are
currently missing support / under-supported / have errors.

Thank you.

Hi,

My colleague was linting this and getting an error

var a = /<.+>[^]<.+>/;

Unescaped '^'.

He argued that [^] was a valid succinct way of saying "any character"
rather than [.\n\r]* or [\s\S]*

What do you think?

Regards,

Luke


[Non-text portions of this message have been removed]

On 1/18/13 4:28 AM, "Luke Page" <luke.a.page@...> wrote:

>My colleague was linting this and getting an error
>
>var a = /<.+>[^]<.+>/;
>
>Unescaped '^'.
>
>He argued that [^] was a valid succinct way of saying "any character"
>rather than [.\n\r]* or [\s\S]*
>
>What do you think?

ah yes, very clever. most impressive. and *therefore* it is, i think, the
kind of thing jslint should grumble about.

regexes are hard enough to understand as it is.

I think it looks like an error if you haven't come across it before, but
once you have, it is probably quite understandable.

You could argue that it could be a mistake and the programmer missed off
the character class, but I'm not sure that would be a common/predictable
mistake.

I wondered whether the above was a known pattern for people who do a lot of
regex's ?


On 18 January 2013 14:22, Tom Worster <fsb@...> wrote:

> **
>
>
> On 1/18/13 4:28 AM, "Luke Page" luke.a.page@...> wrote:
>
> >My colleague was linting this and getting an error
> >
> >var a = /<.+>[^]<.+>/;
> >
> >Unescaped '^'.
> >
> >He argued that [^] was a valid succinct way of saying "any character"
> >rather than [.\n\r]* or [\s\S]*
> >
> >What do you think?
>
> ah yes, very clever. most impressive. and *therefore* it is, i think, the
> kind of thing jslint should grumble about.
>
> regexes are hard enough to understand as it is.
>
>
>


[Non-text portions of this message have been removed]

such cleverness isn't valid in other regex languages, so it would seem to an
unfortunate pattern to learn.
--
  -Peter Buckner

On Jan 18, 2013, at 7:01 AM, Luke Page wrote:

> I think it looks like an error if you haven't come across it before, but
> once you have, it is probably quite understandable.
>
> You could argue that it could be a mistake and the programmer missed off
> the character class, but I'm not sure that would be a common/predictable
> mistake.
>
> I wondered whether the above was a known pattern for people who do a lot of
> regex's ?
>


[Non-text portions of this message have been removed]

If you read the documentation on mozilla.org you will find [^] as their
suggested "any character" expression

Ben
On Jan 18, 2013 4:28 AM, "Luke Page" <luke.a.page@...> wrote:

> **
>
>
> Hi,
>
> My colleague was linting this and getting an error
>
> var a = /<.+>[^]<.+>/;
>
> Unescaped '^'.
>
> He argued that [^] was a valid succinct way of saying "any character"
> rather than [.\n\r]* or [\s\S]*
>
> What do you think?
>
> Regards,
>
> Luke
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

Can you point me to the specific link, page, paragraph etc. where this is
spec'd, I looked on mozilla and could not find this "suggestion". I wanted to
take a look at it in a RegExp validator; and it's not a valid RegExp.

<.+>[^]<.+>

ends up being analyzed as follows

<
any character, one or more repetitions
>
(X) unmatched bracket in character class
Beginning of line or string
]
<
any character, one or more repetitions
>


--- In jslint_com@yahoogroups.com, Ben White  wrote:
>
> If you read the documentation on mozilla.org you will find [^] as their
> suggested "any character" expression
>
> Ben
> On Jan 18, 2013 4:28 AM, "Luke Page"  wrote:
>
> > **
> >
> >
> > Hi,
> >
> > My colleague was linting this and getting an error
> >
> > var a = /<.+>[^]<.+>/;
> >
> > Unescaped '^'.
> >
> > He argued that [^] was a valid succinct way of saying "any character"
> > rather than [.\n\r]* or [\s\S]*
> >
> > What do you think?
> >
> > Regards,
> >
> > Luke
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

2013/1/19 george_weilenmann <abyssoft@...>
> Can you point me to the specific link, page, paragraph etc. where this is
> spec'd, I looked on mozilla and could not find this "suggestion".

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Reg\
Exp
"The character set [^] can be used to match any character including newlines."

--
keradus

Thankyou that did not pop out at me when I looked through that document earlier.
I would say avoid that pattern as it is not valid RegExp.

I think the way they listed the information lead to erroneous understanding. [^]
in that statement was use to symbolically represent the RegExp symbol . ; why
they chose to confuse the issue is beyond me. The segment right below that when
taken in context with the above helps to make this a little clearer but not
much.


--- In jslint_com@yahoogroups.com, Keradus  wrote:
>
> 2013/1/19 george_weilenmann
> > Can you point me to the specific link, page, paragraph etc. where this is
> > spec'd, I looked on mozilla and could not find this "suggestion".
>
>
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Reg\
Exp
> "The character set [^] can be used to match any character including newlines."
>
> --
> keradus
>

Did a little digging  [^]  compiles to  not null/empty it is a side effect
resulting from the spec for RegExp as performed in JavaScript but does not apply
to other implementations of RegExp.

Given that this is unique to JavaScript I'd say that JSLint is in the right as
it is confusing.


--- In jslint_com@yahoogroups.com, Keradus  wrote:
>
> 2013/1/19 george_weilenmann
> > Can you point me to the specific link, page, paragraph etc. where this is
> > spec'd, I looked on mozilla and could not find this "suggestion".
>
>
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Reg\
Exp
> "The character set [^] can be used to match any character including newlines."
>
> --
> keradus
>

On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann <abyssoft@...>
wrote:
> Given that this is unique to JavaScript I'd say that JSLint is in the
> right as it is confusing.

So, which regular expression syntax should JSLint enforce? POSIX? Is
that even compatible with the implementation in JavaScript?

Given that there are many dialects of regular expressions and not one
single authoratitive standard, in my opinion, JSLint should enforce:

Regular expressions as defined by ECMAScript. :-)

(minus dangerous constructs)

--- In jslint_com@yahoogroups.com, "Felix E. Klee"  wrote:
>
> On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann
> wrote:
> > Given that this is unique to JavaScript I'd say that JSLint is in the
> > right as it is confusing.
>
> So, which regular expression syntax should JSLint enforce? POSIX? Is
> that even compatible with the implementation in JavaScript?
>
> Given that there are many dialects of regular expressions and not one
> single authoratitive standard, in my opinion, JSLint should enforce:
>
> Regular expressions as defined by ECMAScript. :-)


One of the design principles behind JSLint is that if a feature is problematic,
and if it can be completely replaced with another feature that is less
problematic, then the more problematic feature should not be allowed. In making
that determination, the following are irrelevant: It is permitted by a standard.
It is sometimes useful. It is totally awesome. It is popular.

douglascrockford <douglas@...> wrote on Sat, 19 Jan 2013
at 13:20:21 -0000 in <kde6il+8gnb@eGroups.com>:

> One of the design principles behind JSLint is that if a feature is
> problematic, and if it can be completely replaced with another
> feature that is less problematic, then the more problematic feature
> should not be allowed.

It would really help if the documentation explained why [^] was
excluded.

--jhawk@...
   John Hawkinson

from http://www.regular-expressions.info/javascript.html

JavaScript implements Perl-style regular expressions. However, it lacks quite a
number of advanced features available in Perl and other modern regular
expression flavors:

No \A or \Z anchors to match the start or end of the string. Use a caret or
dollar instead.
Lookbehind is not supported at all. Lookahead is fully supported.
No atomic grouping or possessive quantifiers.
No Unicode support, except for matching single characters with \uFFFF.
(Note form me on this: only the oldest implementations suffer this limitation
today)
No named capturing groups. Use numbered capturing groups instead.
No mode modifiers to set matching options within the regular expression.
No conditionals.
No regular expression comments. Describe your regular expression with JavaScript
// comments instead, outside the regular expression str

[^] is confusing and definitely should be avoided.

--- In jslint_com@yahoogroups.com, "Felix E. Klee"  wrote:
>
> On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann
> wrote:
> > Given that this is unique to JavaScript I'd say that JSLint is in the
> > right as it is confusing.
>
> So, which regular expression syntax should JSLint enforce? POSIX? Is
> that even compatible with the implementation in JavaScript?
>
> Given that there are many dialects of regular expressions and not one
> single authoratitive standard, in my opinion, JSLint should enforce:
>
> Regular expressions as defined by ECMAScript. :-)
>
> (minus dangerous constructs)
>

I need to support user-supplied math functions. Are there any good alternatives
to using eval, or, more likely, the Function constructor?

I could write js code to evaluate js expression parse trees, though I suspect
the performance wouldn't be acceptable.

It looks like ADsafe is a bit like this (running 3rd party code safely), but I
don't really understand ADsafe usage. Are you expected to run jslint on a
server, before serving the js to the browser? If so, that doesn't help. I could
run jslint in the browser, but then wouldn't I still need to eval the code if it
passed? In that case I can use something simpler and much more restrictive than
jslint.

I understand why the following code generates the warning "Unexpected 'typeof'.
Use '===' to compare directly with undefined"

var foo;

if (typeof foo === 'undefined') {
     alert('foo undefined');
}

JSLint wants me to write this instead:

var foo;

if (foo === undefined) {
     alert('foo undefined');
}

Which is all well and good.

However I noticed that I can get around the error by simply switching the
operands in the typeof expression:

var foo;

if ('undefined' === typeof foo) {
     alert('foo undefined');
}

Is this by design? Am I missing something silly and fundamental here? Or is it a
bug in JSLint?

--- In jslint_com@yahoogroups.com, "andrew_wh"  wrote:
>
> I understand why the following code generates the warning "Unexpected
'typeof'. Use '===' to compare directly with undefined"
>
> var foo;
>
> if (typeof foo === 'undefined') {
>     alert('foo undefined');
> }
>
> JSLint wants me to write this instead:
>
> var foo;
>
> if (foo === undefined) {
>     alert('foo undefined');
> }
>
> Which is all well and good.
>
> However I noticed that I can get around the error by simply switching the
operands in the typeof expression:
>
> var foo;
>
> if ('undefined' === typeof foo) {
>     alert('foo undefined');
> }
>
> Is this by design? Am I missing something silly and fundamental here? Or is it
a bug in JSLint?


Thanks. Please try it now.