Dear Vendor,

Please provide an update on ECCN for the product JSLint.

Thanks,

Sree
OAI-sys, Application Development and Testing Tools
Travelers Insurance.
HPSM Workgroup: APP-ENT-SOFTWARE-TOOLS
svardhan@...<mailto:svardhan@...>

________________________________
From: Vardhan,Sree
Sent: Thursday, January 05, 2012 10:22 AM
To: 'jslint_com@yahoogroups.com'
Subject: ECCN required for JSLint

Dear Vendor,

We are using your software product JSLint in one or more of our engagements at
Travelers in which the software will be used by non-U.S. citizens.  Under U.S.
export regulations, when Travelers provides software access to a non-US citizen,
it is considered an export to that person's home country. It makes no difference
where the software is loaded or where the person accesses the software, when we
provide access, we are performing an export.

The government has a classification system that covers everything from goods and
commodities to software and technology. The classifications are used to define
the government controls and export reporting/licensing requirements.  In most
cases, the government has little or no control/reporting requirements for
run-of-the-mill business software. However, in some cases, this software may
have encryption or certain high performance features that can be used for
criminal or terrorist purposes; these are the ones that they would like to
track.  They do this through the use of Export Compliance Classification Numbers
(ECCN).

The export classification number or ECCN, as it is called, requires in-depth
product knowledge, especially when classifying software products.  As such, we
look to the vendor to provide that information to Travelers.

Please provide the ECCN for JSLint at your earliest convenience.



Thanks,

Sree
OAI-sys, Application Development and Testing Tools
Travelers Insurance.
HPSM Workgroup: APP-ENT-SOFTWARE-TOOLS
svardhan@...<mailto:svardhan@...>


==============================================================================
This communication, including attachments, is confidential, may be subject to
legal privileges, and is intended for the sole use of the addressee. Any use,
duplication, disclosure or dissemination of this communication, other than by
the addressee, is prohibited. If you have received this communication in error,
please notify the sender immediately and delete or destroy this communication
and all copies.


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

--- In jslint_com@yahoogroups.com, "Vardhan,Sree" <svardhan@...> wrote:
> Dear Vendor,
>
> Please provide an update on ECCN for the product JSLint.
>
> Thanks,
>
> Sree

Dear Sree,

In this relationship, I am not a vendor. I have never submitted an invoice to
you. You have never paid a penny to me. I am an Open Source Software Developer.
I have developed programs and components that some people have found useful. I
make my software available to all the people in the world for free, with no
expectation of anything in return.

Because my free software is distributed on the Internet, it may be received by
people who will use it for evil purposes. That is why the source of the program
includes this condition of use:

     The software shall be used for good, not evil.

I will not secure an ECCN for JSLint unless someone provides an overwhelmingly
powerful financial incentive.

Yours in earnest!

Douglas Crockford

> I would write it this way:
>
> function test(x) {
> ~~~~'use strict';
> ~~~~return x === 1
> ~~~~~~~~? 'one'
> ~~~~~~~~: x === 2
> ~~~~~~~~? 'two'
> ~~~~~~~~: x === 3
> ~~~~~~~~? 'three'
> ~~~~~~~~: x === 4
> ~~~~~~~~? 'four'
> ~~~~~~~~: 'zero';
> }
>
> The placement of ? and : makes it easier to read them as then and else if.

I was under the impression that a line that starts with the return
statement should end with a semicolon, in order to not give the
interpreter a chance to mess it up.

I can't test it in IE6 right now, but isn't it conceivable that a dull
browser would turn the above function into "return x===1;"?

Or does the "'use strict';" prevent that sort of misguided benevolence?

Hi

I'm new to javascript, but I have a solid C/C++ background. One of
reasons why I prefer C++ over C is because it stricter. I prefer to
catch errors during compile time rather in run time. That's why I
addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!

During use of JSLint I hit several issues, I want to discuss.

1. JSLint does not handle functions with circular dependencies well.

Let I have following code:

var f1 = function () { f2(); },
     f2 = function () { f1(); };

JSLint won't validate this code, with the reason that 'f2' is not yet
defined. But I think it is a valid code. As far as I understand, all
variables declarations inside function are visible by javascript
engine regardless of declaration order and are subject to closure
capturing. So the code is roughly equivalent to:

var f1, f2;

f1 = function () { f2(); };
f2 = function () { f1(); };

I think it would be nice if JSLint will make a distinction, whenever
variable is used directly or used in closure. So it will reject code
like:

var v = f() + 1,
     f = function () { return 1; };

But still allow code like mine.

When making a closure, it is important that variable must be declared,
but order is not important, variable can be declared everywhere inside
function.

When variable value is actually used (not with closure), then it is
really important to check that it was set before.

2. Why ++ operator is banned? (Sorry for raising this question again).

As I mentioned before I've been working with C/C++ many years. And
when I see p += 1 inside a loop it hurts my eyes.

I tried to figure out why these operators are fallen out of favor. I
read discussions, I watched Douglas Crockford's lectures. But I still
don't really understand what is bad in ++ operator.

Douglas reasons banning of operators because they are too error
prone. But I think that not these operators are error prone as the way
they used.

People are often made mistakes when operators are used inside an
expression. That's the real problem. So why to ban whole operator
rather then ban it's dangerous usage. It's pretty safe to use
operators when result is ignored: when expression statement is a
single inc/dec operator or when inc/dec operator is a part of comma
expression which value is ignored (like expression statement, or third
expression in 'for' loop).

Douglas suggests to use p += 1 instead of ++p, but I don't see any
safety benefits. They are almost equivalent. You may literally replace
every ++p with (p += 1) but bugs wouldn't be magically cured. The only
difference is operator precedence. But precedence does not matter, if
increment operators are allowed only in cases where result is ignored.

I think it is not fair to ban innocent operators, better to catch the
situations where result of (p += 1) or ++p or p++ is actually used.

Thank you for attention!

PS. Funny thing that Google's javascript linter, gjslint doesn't like
space between function keyword and opening brace. So it is impossible
to make a source which makes both linters happy.

(Personally I agree with JSLint, it is consistent to add a space
between language keyword and opening brace. If you write "if (",
"while (", "switch (", ..., why to omit space with function keyword?).

Hi

There is some indentation strangeness. JSLint does not like properly
indented text:

/*global g */
/*jslint indent: 2 */
(function () {
   "use strict";
   return function () {
     return g
       .method({ a: 1,
                 b: {
                   c: function () {}
                 }
               });
   };
}());

instead it suggests to fix indentation as follows:

/*global g */
/*jslint indent: 2 */
(function () {
   "use strict";
   return function () {
     return g
       .method({ a: 1,
                 b: {
           c: function () {}
         }
               });
   };
}());

Is this desired behavior, or it is a bug? Probably indentation level
4 hard coded somewhere, and indendation subtracted by multiple of 4
rather than 2?

NB: Please select "Use Fixed Width Font" in "Message Option" to see
indentation properly.

JSLint accepts two conventions for block-like structures, open and compact. Your
code conforms to neither. Try

/*global g */
/*jslint indent: 2 */
(function () {
~~"use strict";
~~return function () {
~~~~return g
~~~~~~.method({
~~~~~~~~a: 1,
~~~~~~~~b: {
~~~~~~~~~~c: function () {}
~~~~~~~~}
~~~~~~});
~~};
}());

Thank you for a quick answer! It's a honor to get an answer directly
from JSLint author.

So JSLint does not allow to mix open and compact forms. If I get right
I used compact form for outer block and open for inner block?

I think it's better to make a warning not to mix styles, rather then
suggest wrong indentation.

On other hand I don't see anything wrong in mixing styles. What if
after adding 'b' key I realize that line won't fit in 79 characters in
compact form? Naturally I rewrite contents of 'b' key from compact to
open form (actually mixed styles appeared in that way, while code
evolved). I don't see a reason to rewrite outer blocks to open form
too, as code is perfectly readable already.

Here is my original code with leading spaces substituted by
tilde. (Thanks for idea, how to show indents in variable width font,
by the way).

/*global g */
/*jslint indent: 2 */
(function () {
~~"use strict";
~~return function () {
~~~~return g
~~~~~~.method({ a: 1,
~~~~~~~~~~~~~~~~b: {
~~~~~~~~~~~~~~~~~~c: function () {}
~~~~~~~~~~~~~~~~}
~~~~~~~~~~~~~~});
~~};
}());

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> JSLint accepts two conventions for block-like structures, open and compact.
Your code conforms to neither. Try
>
> /*global g */
> /*jslint indent: 2 */
> (function () {
> ~~"use strict";
> ~~return function () {
> ~~~~return g
> ~~~~~~.method({
> ~~~~~~~~a: 1,
> ~~~~~~~~b: {
> ~~~~~~~~~~c: function () {}
> ~~~~~~~~}
> ~~~~~~});
> ~~};
> }());
>

Good morning!

I was thinking about mixing open and compact forms. And I think
disallowing to use open inside compact and vice verse brings
inconveniences.

It's fine for lint to use function parameters in compact form:

func(1, 2, 3,
~~~~~4, 5, 6, function () {});

But when one parameter listed in compact form internally contains open
form, lint fails to validate:

func(1, 2, 3,
~~~~~4, 5, 6, function () {
~~~~~});

To pass validation, it's needed to rewrite outer block to open
form. Do you agree that code below, which is correct from lint point
of view, looks worse for a human?

func(
~~1,
~~2,
~~3,
~~4,
~~5,
~~6,
~~function () {
~~}
);

Good morning,

Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):

function myfunc() { … }
func(1, 2, 3, 4, 5, 6, myfunc);

Regards,
Jakob


Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
caerusx
Sendt: 23. januar 2012 09:57
Til: jslint_com@yahoogroups.com
Emne: [jslint] Re: Indentation quirk?

Good morning!

I was thinking about mixing open and compact forms. And I think
disallowing to use open inside compact and vice verse brings
inconveniences.

It's fine for lint to use function parameters in compact form:

func(1, 2, 3,
~~~~~4, 5, 6, function () {});

But when one parameter listed in compact form internally contains open
form, lint fails to validate:

func(1, 2, 3,
~~~~~4, 5, 6, function () {
~~~~~});

To pass validation, it's needed to rewrite outer block to open
form. Do you agree that code below, which is correct from lint point
of view, looks worse for a human?

func(
~~1,
~~2,
~~3,
~~4,
~~5,
~~6,
~~function () {
~~}
);

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

Hi

For one liners it's better to use lambda forms. No matter how
descriptive name is, better to see an actual code immediately, if it
just one line.

Often lambda forms are used just to bind some parameters to existing
functions, or just to pass some expression (e.g. sort function), or
some simple filtering function. And it's weird to give an explicit
name to these one liners in language supporting lambda forms.

It's just my opinion.

Nevertheless, I don't think that it is a good idea to rewrite a
readable code to less readable just to pass a lint.

Like in my other topic with cyclic dependent functions. It is possible
to work around lint requirement by splitting declarations of variable
and assignment to separate statements, but why to do this if it
actually complicates code.


--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Good morning,
>
> Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
>
> function myfunc() { � }
> func(1, 2, 3, 4, 5, 6, myfunc);
>
> Regards,
> Jakob
>
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P� vegne
af caerusx
> Sendt: 23. januar 2012 09:57
> Til: jslint_com@yahoogroups.com
> Emne: [jslint] Re: Indentation quirk?
>
> Good morning!
>
> I was thinking about mixing open and compact forms. And I think
> disallowing to use open inside compact and vice verse brings
> inconveniences.
>
> It's fine for lint to use function parameters in compact form:
>
> func(1, 2, 3,
> ~~~~~4, 5, 6, function () {});
>
> But when one parameter listed in compact form internally contains open
> form, lint fails to validate:
>
> func(1, 2, 3,
> ~~~~~4, 5, 6, function () {
> ~~~~~});
>
> To pass validation, it's needed to rewrite outer block to open
> form. Do you agree that code below, which is correct from lint point
> of view, looks worse for a human?
>
> func(
> ~~1,
> ~~2,
> ~~3,
> ~~4,
> ~~5,
> ~~6,
> ~~function () {
> ~~}
> );
>
> [Non-text portions of this message have been removed]
>

Hi

The formatting problem you outlined had to do with how your code should be
distributed over multiple lines, so it is not “just one line”. If it was just
one line jslints line breaking rules would hardly apply.

I recommend that you improve the readability of your code because that makes it
better code. That it also then happens to comply with the recommendations of
jslint is an added bonus.

/Jakob

Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
caerusx
Sendt: 23. januar 2012 12:38
Til: jslint_com@yahoogroups.com
Emne: SV: [jslint] Re: Indentation quirk?




Hi

For one liners it's better to use lambda forms. No matter how
descriptive name is, better to see an actual code immediately, if it
just one line.

Often lambda forms are used just to bind some parameters to existing
functions, or just to pass some expression (e.g. sort function), or
some simple filtering function. And it's weird to give an explicit
name to these one liners in language supporting lambda forms.

It's just my opinion.

Nevertheless, I don't think that it is a good idea to rewrite a
readable code to less readable just to pass a lint.

Like in my other topic with cyclic dependent functions. It is possible
to work around lint requirement by splitting declarations of variable
and assignment to separate statements, but why to do this if it
actually complicates code.

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Good morning,
>
> Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
>
> function myfunc() { � }
> func(1, 2, 3, 4, 5, 6, myfunc);
>
> Regards,
> Jakob
>
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P� vegne
af caerusx
> Sendt: 23. januar 2012 09:57
> Til: jslint_com@yahoogroups.com
> Emne: [jslint] Re: Indentation quirk?
>
> Good morning!
>
> I was thinking about mixing open and compact forms. And I think
> disallowing to use open inside compact and vice verse brings
> inconveniences.
>
> It's fine for lint to use function parameters in compact form:
>
> func(1, 2, 3,
> ~~~~~4, 5, 6, function () {});
>
> But when one parameter listed in compact form internally contains open
> form, lint fails to validate:
>
> func(1, 2, 3,
> ~~~~~4, 5, 6, function () {
> ~~~~~});
>
> To pass validation, it's needed to rewrite outer block to open
> form. Do you agree that code below, which is correct from lint point
> of view, looks worse for a human?
>
> func(
> ~~1,
> ~~2,
> ~~3,
> ~~4,
> ~~5,
> ~~6,
> ~~function () {
> ~~}
> );
>
> [Non-text portions of this message have been removed]
>


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

Hi

Very often one line function does not fit in the same line with
function keyword, so it's naturally to write it as open block.

Consider:

some_function_with_the_long_name(arg1, arg2, arg3, arg4,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~function () {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~other_some_long_function(par1, par2);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~});

You just can't write lambda function in compact form, it does not
fit. Rewriting code with named function, is less readable:

var binder3;

[... some lines of code ...]

binder3 = function () {
~~other_some_long_function(par1, par2);
};

some_function_with_the_long_name(arg1, arg2, arg3, arg4, binder3);

You have too look back, what binder3 is actually doing. Though it just
a three lines upper, but it definitely takes more time to look back.

More over, you have to split 'binder3' declaration and assignment. If
you assign it in declaration statement, code become even more
unreadable (you have to look back more code to find binder3
definition).

And by JSLint rules, you can't declare var just before calling
'some_function_with_the_long_name', as you get an error: "Combine this
with the previous 'var' statement.".

You may object, that you may give a better name to 'binder3'. But any
good name is not as expressive as code. You may give a name like
'compare_tuples', but it does not express the all meaning (what
relation is used for comparison, and what parts of tuple actually
compared).

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Hi
>
> The formatting problem you outlined had to do with how your code should be
distributed over multiple lines, so it is not "just one line". If it was just
one line jslints line breaking rules would hardly apply.
>
> I recommend that you improve the readability of your code because that makes
it better code. That it also then happens to comply with the recommendations of
jslint is an added bonus.
>
> /Jakob
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> Sendt: 23. januar 2012 12:38
> Til: jslint_com@yahoogroups.com
> Emne: SV: [jslint] Re: Indentation quirk?
>
>
>
>
> Hi
>
> For one liners it's better to use lambda forms. No matter how
> descriptive name is, better to see an actual code immediately, if it
> just one line.
>
> Often lambda forms are used just to bind some parameters to existing
> functions, or just to pass some expression (e.g. sort function), or
> some simple filtering function. And it's weird to give an explicit
> name to these one liners in language supporting lambda forms.
>
> It's just my opinion.
>
> Nevertheless, I don't think that it is a good idea to rewrite a
> readable code to less readable just to pass a lint.
>
> Like in my other topic with cyclic dependent functions. It is possible
> to work around lint requirement by splitting declarations of variable
> and assignment to separate statements, but why to do this if it
> actually complicates code.
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> >
> > Good morning,
> >
> > Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
> >
> > function myfunc() { � }
> > func(1, 2, 3, 4, 5, 6, myfunc);
> >
> > Regards,
> > Jakob
> >
> >
> > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P�
vegne af caerusx
> > Sendt: 23. januar 2012 09:57
> > Til: jslint_com@yahoogroups.com
> > Emne: [jslint] Re: Indentation quirk?
> >
> > Good morning!
> >
> > I was thinking about mixing open and compact forms. And I think
> > disallowing to use open inside compact and vice verse brings
> > inconveniences.
> >
> > It's fine for lint to use function parameters in compact form:
> >
> > func(1, 2, 3,
> > ~~~~~4, 5, 6, function () {});
> >
> > But when one parameter listed in compact form internally contains open
> > form, lint fails to validate:
> >
> > func(1, 2, 3,
> > ~~~~~4, 5, 6, function () {
> > ~~~~~});
> >
> > To pass validation, it's needed to rewrite outer block to open
> > form. Do you agree that code below, which is correct from lint point
> > of view, looks worse for a human?
> >
> > func(
> > ~~1,
> > ~~2,
> > ~~3,
> > ~~4,
> > ~~5,
> > ~~6,
> > ~~function () {
> > ~~}
> > );
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> [Non-text portions of this message have been removed]
>

I don’t see this going anywhere, but I’d like to point out that

1)      A function call split over 3-4 lines is not a “one line function”. If
you would like to make it one, stop declaring new functions inside the call.
2)      Why would you use “var” to first declare and then define a function.
JavaScript has “function” for this purpose. Jslint does not complain about
function statements separated from var statements.

/Jakob


Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
caerusx
Sendt: 23. januar 2012 13:36
Til: jslint_com@yahoogroups.com
Emne: SV: [jslint] Re: Indentation quirk?




Hi

Very often one line function does not fit in the same line with
function keyword, so it's naturally to write it as open block.

Consider:

some_function_with_the_long_name(arg1, arg2, arg3, arg4,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~function () {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~other_some_long_function(par1, par2);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~});

You just can't write lambda function in compact form, it does not
fit. Rewriting code with named function, is less readable:

var binder3;

[... some lines of code ...]

binder3 = function () {
~~other_some_long_function(par1, par2);
};

some_function_with_the_long_name(arg1, arg2, arg3, arg4, binder3);

You have too look back, what binder3 is actually doing. Though it just
a three lines upper, but it definitely takes more time to look back.

More over, you have to split 'binder3' declaration and assignment. If
you assign it in declaration statement, code become even more
unreadable (you have to look back more code to find binder3
definition).

And by JSLint rules, you can't declare var just before calling
'some_function_with_the_long_name', as you get an error: "Combine this
with the previous 'var' statement.".

You may object, that you may give a better name to 'binder3'. But any
good name is not as expressive as code. You may give a name like
'compare_tuples', but it does not express the all meaning (what
relation is used for comparison, and what parts of tuple actually
compared).

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Hi
>
> The formatting problem you outlined had to do with how your code should be
distributed over multiple lines, so it is not "just one line". If it was just
one line jslints line breaking rules would hardly apply.
>
> I recommend that you improve the readability of your code because that makes
it better code. That it also then happens to comply with the recommendations of
jslint is an added bonus.
>
> /Jakob
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> Sendt: 23. januar 2012 12:38
> Til: jslint_com@yahoogroups.com
> Emne: SV: [jslint] Re: Indentation quirk?
>
>
>
>
> Hi
>
> For one liners it's better to use lambda forms. No matter how
> descriptive name is, better to see an actual code immediately, if it
> just one line.
>
> Often lambda forms are used just to bind some parameters to existing
> functions, or just to pass some expression (e.g. sort function), or
> some simple filtering function. And it's weird to give an explicit
> name to these one liners in language supporting lambda forms.
>
> It's just my opinion.
>
> Nevertheless, I don't think that it is a good idea to rewrite a
> readable code to less readable just to pass a lint.
>
> Like in my other topic with cyclic dependent functions. It is possible
> to work around lint requirement by splitting declarations of variable
> and assignment to separate statements, but why to do this if it
> actually complicates code.
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> >
> > Good morning,
> >
> > Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
> >
> > function myfunc() { � }
> > func(1, 2, 3, 4, 5, 6, myfunc);
> >
> > Regards,
> > Jakob
> >
> >
> > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P�
vegne af caerusx
> > Sendt: 23. januar 2012 09:57
> > Til: jslint_com@yahoogroups.com
> > Emne: [jslint] Re: Indentation quirk?
> >
> > Good morning!
> >
> > I was thinking about mixing open and compact forms. And I think
> > disallowing to use open inside compact and vice verse brings
> > inconveniences.
> >
> > It's fine for lint to use function parameters in compact form:
> >
> > func(1, 2, 3,
> > ~~~~~4, 5, 6, function () {});
> >
> > But when one parameter listed in compact form internally contains open
> > form, lint fails to validate:
> >
> > func(1, 2, 3,
> > ~~~~~4, 5, 6, function () {
> > ~~~~~});
> >
> > To pass validation, it's needed to rewrite outer block to open
> > form. Do you agree that code below, which is correct from lint point
> > of view, looks worse for a human?
> >
> > func(
> > ~~1,
> > ~~2,
> > ~~3,
> > ~~4,
> > ~~5,
> > ~~6,
> > ~~function () {
> > ~~}
> > );
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> [Non-text portions of this message have been removed]
>


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

1) I agree, it is not a real problem. When I validated my code I hit
    just several errors of such kind for 1000+ lines of code. And I was
    not able to find out why JSLint suggests wrong indentation. Douglas
    post helped me much to find out why JSLint behaves so. It was not a
    problem for me to convert outer blocks to open form, and now my
    code is successfully passing validation.

    Actually with one exception (vars: true), but it just because my
    javascript editor (js-mode for emacs) can't parse multiline var
    statement. So I avoid it by splitting multiline var declarations to
    multiple subsequent one line declarations. Anyway UglifyJS will
    combine them together.

    So for now I just have not real but just technical interest, why
    open form inside compact form confuses JSLint.

    I don't think as it should be left as is. In test case I provided
    in first post JSLint suggests to use indisputably wrong
    indentation. And worse, after making changes which it wants, badly
    formatted javascript is passing validation.

    So as minimum, JSLint should not successfully validate wrongly
    formatted text. And if JSLint want to be kind, it would be nice if
    it produce human readable error that mixing of block forms is not
    allowed. ...Or it may allow to mix different forms, whatever author
    will decide.

2) Thank you for pointing me that! (really)

    Long time ago, I've been reading that some buggy javascript
    implementations doesn't work well with nested functions in a way
    that nested functions actually declared in outer scope. And it is
    better to use var + lambda function, since every implementation
    work correctly in such case.

    I don't even recall where I've read this. I thought it was Google's
    JavaScript style guide, but now I see it actually encourage use of
    nested function. I guess either this recommendation is totally
    outdated or I've misread something. Now I will use nested functions :)


--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> I don't see this going anywhere, but I'd like to point out that
>
> 1)      A function call split over 3-4 lines is not a "one line function". If
you would like to make it one, stop declaring new functions inside the call.
> 2)      Why would you use "var" to first declare and then define a function.
JavaScript has "function" for this purpose. Jslint does not complain about
function statements separated from var statements.
>
> /Jakob
>
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> Sendt: 23. januar 2012 13:36
> Til: jslint_com@yahoogroups.com
> Emne: SV: [jslint] Re: Indentation quirk?
>
>
>
>
> Hi
>
> Very often one line function does not fit in the same line with
> function keyword, so it's naturally to write it as open block.
>
> Consider:
>
> some_function_with_the_long_name(arg1, arg2, arg3, arg4,
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~function () {
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~other_some_long_function(par1, par2);
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~});
>
> You just can't write lambda function in compact form, it does not
> fit. Rewriting code with named function, is less readable:
>
> var binder3;
>
> [... some lines of code ...]
>
> binder3 = function () {
> ~~other_some_long_function(par1, par2);
> };
>
> some_function_with_the_long_name(arg1, arg2, arg3, arg4, binder3);
>
> You have too look back, what binder3 is actually doing. Though it just
> a three lines upper, but it definitely takes more time to look back.
>
> More over, you have to split 'binder3' declaration and assignment. If
> you assign it in declaration statement, code become even more
> unreadable (you have to look back more code to find binder3
> definition).
>
> And by JSLint rules, you can't declare var just before calling
> 'some_function_with_the_long_name', as you get an error: "Combine this
> with the previous 'var' statement.".
>
> You may object, that you may give a better name to 'binder3'. But any
> good name is not as expressive as code. You may give a name like
> 'compare_tuples', but it does not express the all meaning (what
> relation is used for comparison, and what parts of tuple actually
> compared).
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> >
> > Hi
> >
> > The formatting problem you outlined had to do with how your code should be
distributed over multiple lines, so it is not "just one line". If it was just
one line jslints line breaking rules would hardly apply.
> >
> > I recommend that you improve the readability of your code because that makes
it better code. That it also then happens to comply with the recommendations of
jslint is an added bonus.
> >
> > /Jakob
> >
> > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> > Sendt: 23. januar 2012 12:38
> > Til: jslint_com@yahoogroups.com
> > Emne: SV: [jslint] Re: Indentation quirk?
> >
> >
> >
> >
> > Hi
> >
> > For one liners it's better to use lambda forms. No matter how
> > descriptive name is, better to see an actual code immediately, if it
> > just one line.
> >
> > Often lambda forms are used just to bind some parameters to existing
> > functions, or just to pass some expression (e.g. sort function), or
> > some simple filtering function. And it's weird to give an explicit
> > name to these one liners in language supporting lambda forms.
> >
> > It's just my opinion.
> >
> > Nevertheless, I don't think that it is a good idea to rewrite a
> > readable code to less readable just to pass a lint.
> >
> > Like in my other topic with cyclic dependent functions. It is possible
> > to work around lint requirement by splitting declarations of variable
> > and assignment to separate statements, but why to do this if it
> > actually complicates code.
> >
> > --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > >
> > > Good morning,
> > >
> > > Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
> > >
> > > function myfunc() { � }
> > > func(1, 2, 3, 4, 5, 6, myfunc);
> > >
> > > Regards,
> > > Jakob
> > >
> > >
> > > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P�
vegne af caerusx
> > > Sendt: 23. januar 2012 09:57
> > > Til: jslint_com@yahoogroups.com
> > > Emne: [jslint] Re: Indentation quirk?
> > >
> > > Good morning!
> > >
> > > I was thinking about mixing open and compact forms. And I think
> > > disallowing to use open inside compact and vice verse brings
> > > inconveniences.
> > >
> > > It's fine for lint to use function parameters in compact form:
> > >
> > > func(1, 2, 3,
> > > ~~~~~4, 5, 6, function () {});
> > >
> > > But when one parameter listed in compact form internally contains open
> > > form, lint fails to validate:
> > >
> > > func(1, 2, 3,
> > > ~~~~~4, 5, 6, function () {
> > > ~~~~~});
> > >
> > > To pass validation, it's needed to rewrite outer block to open
> > > form. Do you agree that code below, which is correct from lint point
> > > of view, looks worse for a human?
> > >
> > > func(
> > > ~~1,
> > > ~~2,
> > > ~~3,
> > > ~~4,
> > > ~~5,
> > > ~~6,
> > > ~~function () {
> > > ~~}
> > > );
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> [Non-text portions of this message have been removed]
>

Hi caerusx, hi everyone,

I am new to the list too, so I'm not (yet) tired of answering the (easy)
++ question, so I'll answer.

1.
I would personally say that your 2nd version is better. It better shows
you understand that you are capturing those variables. It better
expresses that you understand what you write. First declare, then use.

2.
There is an error prone + unary operator that converts a number into a
string.
Sure you always write you loops like this one:

      for (var i = 0; i < 10; ++i) { document.write("hello"); }

but if you unfortunately insert a space between the two +, it is still
valid JavaScript:

      for (var i = 0; i < 10; + +i) { document.write("hello"); }

Though it won't do the same thing at all, looping forever.
That's why jslint complains with the two unary operators: + and ++.
I personally always disable the warning. But I should not.

/Benjamin


On 22/01/2012 13:09, caerusx wrote:
>
> Hi
>
> I'm new to javascript, but I have a solid C/C++ background. One of
> reasons why I prefer C++ over C is because it stricter. I prefer to
> catch errors during compile time rather in run time. That's why I
> addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!
>
> During use of JSLint I hit several issues, I want to discuss.
>
> 1. JSLint does not handle functions with circular dependencies well.
>
> Let I have following code:
>
> var f1 = function () { f2(); },
> f2 = function () { f1(); };
>
> JSLint won't validate this code, with the reason that 'f2' is not yet
> defined. But I think it is a valid code. As far as I understand, all
> variables declarations inside function are visible by javascript
> engine regardless of declaration order and are subject to closure
> capturing. So the code is roughly equivalent to:
>
> var f1, f2;
>
> f1 = function () { f2(); };
> f2 = function () { f1(); };
>
> I think it would be nice if JSLint will make a distinction, whenever
> variable is used directly or used in closure. So it will reject code
> like:
>
> var v = f() + 1,
> f = function () { return 1; };
>
> But still allow code like mine.
>
> When making a closure, it is important that variable must be declared,
> but order is not important, variable can be declared everywhere inside
> function.
>
> When variable value is actually used (not with closure), then it is
> really important to check that it was set before.
>
> 2. Why ++ operator is banned? (Sorry for raising this question again).
>
> As I mentioned before I've been working with C/C++ many years. And
> when I see p += 1 inside a loop it hurts my eyes.
>
> I tried to figure out why these operators are fallen out of favor. I
> read discussions, I watched Douglas Crockford's lectures. But I still
> don't really understand what is bad in ++ operator.
>
> Douglas reasons banning of operators because they are too error
> prone. But I think that not these operators are error prone as the way
> they used.
>
> People are often made mistakes when operators are used inside an
> expression. That's the real problem. So why to ban whole operator
> rather then ban it's dangerous usage. It's pretty safe to use
> operators when result is ignored: when expression statement is a
> single inc/dec operator or when inc/dec operator is a part of comma
> expression which value is ignored (like expression statement, or third
> expression in 'for' loop).
>
> Douglas suggests to use p += 1 instead of ++p, but I don't see any
> safety benefits. They are almost equivalent. You may literally replace
> every ++p with (p += 1) but bugs wouldn't be magically cured. The only
> difference is operator precedence. But precedence does not matter, if
> increment operators are allowed only in cases where result is ignored.
>
> I think it is not fair to ban innocent operators, better to catch the
> situations where result of (p += 1) or ++p or p++ is actually used.
>
> Thank you for attention!
>
> PS. Funny thing that Google's javascript linter, gjslint doesn't like
> space between function keyword and opening brace. So it is impossible
> to make a source which makes both linters happy.
>
> (Personally I agree with JSLint, it is consistent to add a space
> between language keyword and opening brace. If you write "if (",
> "while (", "switch (", ..., why to omit space with function keyword?).
>
> __._,_._
>
>


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

Hi

Thanks for answer!

It makes a sense. But '+=' operator is vulnerable to character swap
typo, 'i =+ 1' is also valid javascript expression.

The unary operators are really evil. Unary plus operator is used
either accidentally or as a hack (in C++ to trigger decaying of array
or implicit conversion to int, in Perl to emphasize that construction
is really an expression looks like a block but not a real block, and
as shorthand to parseInt in JavaScript). Unary minus is actually used,
but usage is very rare (probably programmers writing computational
programs encounter it more often).

Better to ban unary operators. I think ban of unary plus operator most
users would go unnoticed, and unary minus can be easily rewritten as
(0 - i).


--- In jslint_com@yahoogroups.com, Benjamin Gandon <benje@...> wrote:
>
> Hi caerusx, hi everyone,
>
> I am new to the list too, so I'm not (yet) tired of answering the (easy)
> ++ question, so I'll answer.
>
> 1.
> I would personally say that your 2nd version is better. It better shows
> you understand that you are capturing those variables. It better
> expresses that you understand what you write. First declare, then use.
>
> 2.
> There is an error prone + unary operator that converts a number into a
> string.
> Sure you always write you loops like this one:
>
>      for (var i = 0; i < 10; ++i) { document.write("hello"); }
>
> but if you unfortunately insert a space between the two +, it is still
> valid JavaScript:
>
>      for (var i = 0; i < 10; + +i) { document.write("hello"); }
>
> Though it won't do the same thing at all, looping forever.
> That's why jslint complains with the two unary operators: + and ++.
> I personally always disable the warning. But I should not.
>
> /Benjamin
>
>
> On 22/01/2012 13:09, caerusx wrote:
> >
> > Hi
> >
> > I'm new to javascript, but I have a solid C/C++ background. One of
> > reasons why I prefer C++ over C is because it stricter. I prefer to
> > catch errors during compile time rather in run time. That's why I
> > addressed to JSLint. Thanks to Douglas Crockford's for creating JSLint!
> >
> > During use of JSLint I hit several issues, I want to discuss.
> >
> > 1. JSLint does not handle functions with circular dependencies well.
> >
> > Let I have following code:
> >
> > var f1 = function () { f2(); },
> > f2 = function () { f1(); };
> >
> > JSLint won't validate this code, with the reason that 'f2' is not yet
> > defined. But I think it is a valid code. As far as I understand, all
> > variables declarations inside function are visible by javascript
> > engine regardless of declaration order and are subject to closure
> > capturing. So the code is roughly equivalent to:
> >
> > var f1, f2;
> >
> > f1 = function () { f2(); };
> > f2 = function () { f1(); };
> >
> > I think it would be nice if JSLint will make a distinction, whenever
> > variable is used directly or used in closure. So it will reject code
> > like:
> >
> > var v = f() + 1,
> > f = function () { return 1; };
> >
> > But still allow code like mine.
> >
> > When making a closure, it is important that variable must be declared,
> > but order is not important, variable can be declared everywhere inside
> > function.
> >
> > When variable value is actually used (not with closure), then it is
> > really important to check that it was set before.
> >
> > 2. Why ++ operator is banned? (Sorry for raising this question again).
> >
> > As I mentioned before I've been working with C/C++ many years. And
> > when I see p += 1 inside a loop it hurts my eyes.
> >
> > I tried to figure out why these operators are fallen out of favor. I
> > read discussions, I watched Douglas Crockford's lectures. But I still
> > don't really understand what is bad in ++ operator.
> >
> > Douglas reasons banning of operators because they are too error
> > prone. But I think that not these operators are error prone as the way
> > they used.
> >
> > People are often made mistakes when operators are used inside an
> > expression. That's the real problem. So why to ban whole operator
> > rather then ban it's dangerous usage. It's pretty safe to use
> > operators when result is ignored: when expression statement is a
> > single inc/dec operator or when inc/dec operator is a part of comma
> > expression which value is ignored (like expression statement, or third
> > expression in 'for' loop).
> >
> > Douglas suggests to use p += 1 instead of ++p, but I don't see any
> > safety benefits. They are almost equivalent. You may literally replace
> > every ++p with (p += 1) but bugs wouldn't be magically cured. The only
> > difference is operator precedence. But precedence does not matter, if
> > increment operators are allowed only in cases where result is ignored.
> >
> > I think it is not fair to ban innocent operators, better to catch the
> > situations where result of (p += 1) or ++p or p++ is actually used.
> >
> > Thank you for attention!
> >
> > PS. Funny thing that Google's javascript linter, gjslint doesn't like
> > space between function keyword and opening brace. So it is impossible
> > to make a source which makes both linters happy.
> >
> > (Personally I agree with JSLint, it is consistent to add a space
> > between language keyword and opening brace. If you write "if (",
> > "while (", "switch (", ..., why to omit space with function keyword?).
> >
> > __._,_._
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

Hi

I rewrote all my functions declared as var to functions declared as
function. (Thanks for giving me an insight that it's safe to declare
nested functions). And I hit another problem: JSLint does not like
'this' keyword inside function, it fails to validate function with an
error "Strict violation".

But function doesn't even supposed to access global 'this'
object. It's just harmless jQuery callback which expects to be called
in a context of DOM node.

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> I don't see this going anywhere, but I'd like to point out that
>
> 1)      A function call split over 3-4 lines is not a "one line function". If
you would like to make it one, stop declaring new functions inside the call.
> 2)      Why would you use "var" to first declare and then define a function.
JavaScript has "function" for this purpose. Jslint does not complain about
function statements separated from var statements.
>
> /Jakob
>
>
> Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> Sendt: 23. januar 2012 13:36
> Til: jslint_com@yahoogroups.com
> Emne: SV: [jslint] Re: Indentation quirk?
>
>
>
>
> Hi
>
> Very often one line function does not fit in the same line with
> function keyword, so it's naturally to write it as open block.
>
> Consider:
>
> some_function_with_the_long_name(arg1, arg2, arg3, arg4,
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~function () {
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~other_some_long_function(par1, par2);
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~});
>
> You just can't write lambda function in compact form, it does not
> fit. Rewriting code with named function, is less readable:
>
> var binder3;
>
> [... some lines of code ...]
>
> binder3 = function () {
> ~~other_some_long_function(par1, par2);
> };
>
> some_function_with_the_long_name(arg1, arg2, arg3, arg4, binder3);
>
> You have too look back, what binder3 is actually doing. Though it just
> a three lines upper, but it definitely takes more time to look back.
>
> More over, you have to split 'binder3' declaration and assignment. If
> you assign it in declaration statement, code become even more
> unreadable (you have to look back more code to find binder3
> definition).
>
> And by JSLint rules, you can't declare var just before calling
> 'some_function_with_the_long_name', as you get an error: "Combine this
> with the previous 'var' statement.".
>
> You may object, that you may give a better name to 'binder3'. But any
> good name is not as expressive as code. You may give a name like
> 'compare_tuples', but it does not express the all meaning (what
> relation is used for comparison, and what parts of tuple actually
> compared).
>
> --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> >
> > Hi
> >
> > The formatting problem you outlined had to do with how your code should be
distributed over multiple lines, so it is not "just one line". If it was just
one line jslints line breaking rules would hardly apply.
> >
> > I recommend that you improve the readability of your code because that makes
it better code. That it also then happens to comply with the recommendations of
jslint is an added bonus.
> >
> > /Jakob
> >
> > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne
af caerusx
> > Sendt: 23. januar 2012 12:38
> > Til: jslint_com@yahoogroups.com
> > Emne: SV: [jslint] Re: Indentation quirk?
> >
> >
> >
> >
> > Hi
> >
> > For one liners it's better to use lambda forms. No matter how
> > descriptive name is, better to see an actual code immediately, if it
> > just one line.
> >
> > Often lambda forms are used just to bind some parameters to existing
> > functions, or just to pass some expression (e.g. sort function), or
> > some simple filtering function. And it's weird to give an explicit
> > name to these one liners in language supporting lambda forms.
> >
> > It's just my opinion.
> >
> > Nevertheless, I don't think that it is a good idea to rewrite a
> > readable code to less readable just to pass a lint.
> >
> > Like in my other topic with cyclic dependent functions. It is possible
> > to work around lint requirement by splitting declarations of variable
> > and assignment to separate statements, but why to do this if it
> > actually complicates code.
> >
> > --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > >
> > > Good morning,
> > >
> > > Your problem seems to be your insistence on declaring a function inside a
function call. This is much better (from a readability perspective):
> > >
> > > function myfunc() { � }
> > > func(1, 2, 3, 4, 5, 6, myfunc);
> > >
> > > Regards,
> > > Jakob
> > >
> > >
> > > Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] P�
vegne af caerusx
> > > Sendt: 23. januar 2012 09:57
> > > Til: jslint_com@yahoogroups.com
> > > Emne: [jslint] Re: Indentation quirk?
> > >
> > > Good morning!
> > >
> > > I was thinking about mixing open and compact forms. And I think
> > > disallowing to use open inside compact and vice verse brings
> > > inconveniences.
> > >
> > > It's fine for lint to use function parameters in compact form:
> > >
> > > func(1, 2, 3,
> > > ~~~~~4, 5, 6, function () {});
> > >
> > > But when one parameter listed in compact form internally contains open
> > > form, lint fails to validate:
> > >
> > > func(1, 2, 3,
> > > ~~~~~4, 5, 6, function () {
> > > ~~~~~});
> > >
> > > To pass validation, it's needed to rewrite outer block to open
> > > form. Do you agree that code below, which is correct from lint point
> > > of view, looks worse for a human?
> > >
> > > func(
> > > ~~1,
> > > ~~2,
> > > ~~3,
> > > ~~4,
> > > ~~5,
> > > ~~6,
> > > ~~function () {
> > > ~~}
> > > );
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> [Non-text portions of this message have been removed]
>

Last year I experimented with type inference in JSLint. I was not satisfied with
the results of the experiment, so I am pulling all of that code out. JSLint will
no longer recognize the 'confusion' option. It will continue to allow and ignore
type information in /*properties*/ directives for some transition time.

I may attempt another inference experiment in the future.

--- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
>
> A comment before the DOCTYPE sends all versions of IE into quirks mode,
> defeating the purpose of the doctype you've specified.  See
> http://stackoverflow.com/questions/941100/can-html-comments-appear-before-th
> e-doctype-declaration  Move the DOCTYPE line above the comment and you'll be
> fine.  It's unfortunate the error message doesn't include this clarity.
>
> Rob

Thanks for the information on using comments before the DOCTYPE.

However, it seems there is no solution to this if one decides they want or need
to use comments before the DOCTYPE? Is there anyway to tell JSLint to accept it?

Albert

Also, what if the comment is a server macro or something that will be processed
by the server so it doesn't show up to the end user? Is JSLint useless for this
case? I would hope not.


>
> Thanks for the information on using comments before the DOCTYPE.
>
> However, it seems there is no solution to this if one decides they want or
need to use comments before the DOCTYPE? Is there anyway to tell JSLint to
accept it?
>
> Albert
>

JSLint wants CSS blocks to end in semicolons, like this:

<style type="text/css">
#eid{color:navy}
</style>

It's perfectly OK to not have a semicolon in "{color:navy}".

I don't see an option for this? Is there an option to stop this check?

And if not, can such an option be added?

--- In jslint_com@yahoogroups.com, "cse_html_validator" <alhome@...> wrote:

> JSLint wants CSS blocks to end in semicolons, like this:
>
> <style type="text/css">
> #eid{color:navy}
> </style>
>
> It's perfectly OK to not have a semicolon in "{color:navy}".

I recommend that you follow JSLint's advice.

This is a difference between maintainable CSS (which should follow a very strict
format) and ~minified~ CSS. Just as JSLint won't pass minified JS (which would
also be written with a missing semicolon in the same essential location), it
won't, and should not, pass minified CSS.

-- DES


________________________________
  From: cse_html_validator <alhome@...>
To: jslint_com@yahoogroups.com
Sent: Wednesday, 1 February 2012, 11:02
Subject: [jslint] Ending CSS block with semicolon


 

JSLint wants CSS blocks to end in semicolons, like this:

<style type="text/css">
#eid{color:navy}
</style>

It's perfectly OK to not have a semicolon in "{color:navy}".

I don't see an option for this? Is there an option to stop this check?

And if not, can such an option be added?




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

Personally, I prefer to fix my code to follow JSLint's recommendations.
That said, I also put all my Javascript in .js files and include them using
script tags so JSLint does not check my HTML, it checks my JavaScript.

SeanK

On Tue, Jan 31, 2012 at 3:47 PM, cse_html_validator <alhome@...>wrote:

> **
>
>
>
> Also, what if the comment is a server macro or something that will be
> processed by the server so it doesn't show up to the end user? Is JSLint
> useless for this case? I would hope not.
>
> >
> > Thanks for the information on using comments before the DOCTYPE.
> >
> > However, it seems there is no solution to this if one decides they want
> or need to use comments before the DOCTYPE? Is there anyway to tell JSLint
> to accept it?
> >
> > Albert
> >
>
>
>


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

It is less effective to lint minified or processed code as anything you discover
usually can't be repaired in its current format.  Also note that JSLint's CSS
support is pretty rudimentary.  Csslint.net is a similar tool for CSS.

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Doc Emmett Splendid
Sent: Wednesday, February 01, 2012 2:46 PM
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] Ending CSS block with semicolon



This is a difference between maintainable CSS (which should follow a very strict
format) and ~minified~ CSS. Just as JSLint won't pass minified JS (which would
also be written with a missing semicolon in the same essential location), it
won't, and should not, pass minified CSS.

-- DES

________________________________
From: cse_html_validator <alhome@... <mailto:alhome%40wiersch.com> >
To: jslint_com@yahoogroups.com <mailto:jslint_com%40yahoogroups.com>
Sent: Wednesday, 1 February 2012, 11:02
Subject: [jslint] Ending CSS block with semicolon




JSLint wants CSS blocks to end in semicolons, like this:

<style type="text/css">
#eid{color:navy}
</style>

It's perfectly OK to not have a semicolon in "{color:navy}".

I don't see an option for this? Is there an option to stop this check?

And if not, can such an option be added?

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

Hi,
I approached a whitespace issue. I have a code that it's impossible to
refactor so it's ok for jslint - I can resign from checking whitespace
but I don't want to do that.Generic example:
var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
omeFunction);
This shows: Problem at line 3 character 85: Line too long. Let's move
then part of the code to new line:
var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
omeFunction);
Now we have: Problem at line 4 character 1: Expected '(' at column 5,
not column 1. and Problem at line 4 character 1: Unexpected space
between ')' and '('.
If I indent second line as first message suggests:
var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)
(someFunction)(someFunction)(someFunction);
Still I got: Problem at line 4 character 5: Unexpected space between ')'
and '('. so it turns out it's impossible to make that code valid.
In my opinion following should be valid:
var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
omeFunction);
Is there anything that can be done about that ?
Cheers!-- Mariusz
Nowakhttps://github.com/medikoohttp://twiiter.com/medikoo





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

--- In jslint_com@yahoogroups.com, "mariuszn3" <medikoo.yahxo.com@...> wrote:
>
> Hi,
> I approached a whitespace issue. I have a code that it's impossible to
> refactor so it's ok for jslint - I can resign from checking whitespace
> but I don't want to do that.Generic example:
> var someFunction = function () { 'use strict'; };
> someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
> omeFunction);
> This shows: Problem at line 3 character 85: Line too long. Let's move
> then part of the code to new line:
> var someFunction = function () { 'use strict'; };
> someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
> omeFunction);
> Now we have: Problem at line 4 character 1: Expected '(' at column 5,
> not column 1. and Problem at line 4 character 1: Unexpected space
> between ')' and '('.
> If I indent second line as first message suggests:
> var someFunction = function () { 'use strict'; };
> someFunction()(someFunction)(someFunction)
> (someFunction)(someFunction)(someFunction);
> Still I got: Problem at line 4 character 5: Unexpected space between ')'
> and '('. so it turns out it's impossible to make that code valid.
> In my opinion following should be valid:
> var someFunction = function () { 'use strict'; };
> someFunction()(someFunction)(someFunction)(someFunction)(someFunction)(s\
> omeFunction);
> Is there anything that can be done about that ?

You may be going overboard on the function chaining thing.

When you break a line after '(', JSLint expects to see an open configuration. So


var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)(
     someFunction
)(someFunction)(someFunction);

Or you can break compactly before ')'.

var someFunction = function () { 'use strict'; };
someFunction()(someFunction)(someFunction)(someFunction
     )(someFunction)(someFunction);

The thing you can't do is break between ')' and '(' because of the semicolon
insertion hazard.

Thanks, somehow I didn't think about writing it that way, it indeed makes sense.


--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> Or you can break compactly before ')'.
>
> var someFunction = function () { 'use strict'; };
> someFunction()(someFunction)(someFunction)(someFunction
>     )(someFunction)(someFunction);
>
> The thing you can't do is break between ')' and '(' because of the semicolon
insertion hazard.
>

Hi

If I run the following code (properly indented) through JSLint at jslint.com
with all options cleared, it validates. If I run the exact same code through
JSLint locally, with no options, using jslint.js downloaded today from
jslint.com, it errors with “Bad HTML string”.

/*jslint sloppy: true */
function quote(s) {
     return '"' + s + '"';
}

Any ideas as to the difference?

/Jakob

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