On Fri, Dec 31, 2010 at 9:49 PM, Rob Richardson <erobrich@...>
wrote:
> If you put var f = function () {... before function callback(... then
> JSLint would likely be fine.

No, the opposite is true. See the second example in my original post.
That works fine with JSLint. Changing the order would make JSLint
complain about "callback" not being defined.

But that's not really the issue.

> The secondary concern is that you're passing in a flag that says
> whether you should use a follow-up function.

The code is more complicated in reality. There is a lot happening in
"f", and whether to send another request to the server is determined
based not just on the state of "moreToDo".

The code chains XHRs, to download server generated data.

> Passing the function to run into callback() instead of a flag makes
> callback() more generic, and makes this point a bit more clear, and
> that was the focus of Erik's thoughts.

Erik's code would just generate an infinite loop, because it evaluates
to:

   f = function () {
       sendToServer('xyz', f);
   };

But that's *all* besides the point. My question, I think, can be
summarized to:

   For the sake of consistency, and thus readability, should I always
   define functions as:

     var f;

     // ...

     f = function () {
         // ...
     }

   instead of the short form:

     function f() {
         // ..
     }

   ?

Furthermore, can this be enforced with JSLint?

On Sat, Jan 1, 2011 at 11:59 AM, Felix E. Klee <felix.klee@...>
wrote:
> There is a lot happening in "f"

Sorry, that should be:

  There is a lot happening in "callback"

Ah, I see I may have misunderstood.  You're proposing the following:

var a,b;

a = function () {
// ...
b();
// ...
}

b = function () {
// ...
a();
// ...
}

Is this the dilemma at hand?

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Felix E. Klee
Sent: Saturday, January 01, 2011 3:59 AM
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] Circular Function Definitions

On Fri, Dec 31, 2010 at 9:49 PM, Rob Richardson <erobrich@...>
wrote:
> If you put var f = function () {... before function callback(... then
> JSLint would likely be fine.

No, the opposite is true. See the second example in my original post.
That works fine with JSLint. Changing the order would make JSLint
complain about "callback" not being defined.

But that's not really the issue.

> The secondary concern is that you're passing in a flag that says
> whether you should use a follow-up function.

The code is more complicated in reality. There is a lot happening in
"f", and whether to send another request to the server is determined
based not just on the state of "moreToDo".

The code chains XHRs, to download server generated data.

> Passing the function to run into callback() instead of a flag makes
> callback() more generic, and makes this point a bit more clear, and
> that was the focus of Erik's thoughts.

Erik's code would just generate an infinite loop, because it evaluates
to:

   f = function () {
       sendToServer('xyz', f);
   };

But that's *all* besides the point. My question, I think, can be
summarized to:

   For the sake of consistency, and thus readability, should I always
   define functions as:

     var f;

     // ...

     f = function () {
         // ...
     }

   instead of the short form:

     function f() {
         // ..
     }

   ?

Furthermore, can this be enforced with JSLint?

On Sun, Jan 2, 2011 at 4:54 AM, Rob Richardson <erobrich@...> wrote:
> var a,b;
>
> a = function () {
> // ...
> b();
> // ...
> }
>
> b = function () {
> // ...
> a();
> // ...
> }
>
> Is this the dilemma at hand?

Yes.

To me it seems reasonable to - for consistency - avoid the short form:

   function f() {
       // ...
   }

And I would like to enforce that in the entire project, with JSLint.
However, as JSLint does not offer a corresponding option, I wonder if I
am on the wrong track, overdoing things.

My apologies. My code was written too hastily. I thought you were using a
Boolean to indicate whether to make the return call to f.

The point I was trying to get across is that you don't need the circularity.

There are many ways to solve this. Here's one: Any time you want something
to happen after the callback, pass the call to the callback in an anonymous
function:

f = function() {
___// do stuff
___xhr(params, callback); // plain call to cb func
___xhr(params, function() {callback(); f();}); // circular call back to f
}

Or pass the after-callback function as a parameter to the callback function
(again through use of an anonymous function).

or: `callback.returnfn = f; // now check property in that function and call
if needed

Or use a library like jquery and define a custom event, then bind all the
handlers to the event you want, and trigger it any time.

Circularity isn't required.

Erik

On Fri, Dec 31, 2010 at 12:12 PM, Felix E. Klee <felix.klee@...> wrote:

>
>
> On Fri, Dec 31, 2010 at 7:21 PM, Erik Eckhardt
<erik@...<erik%40eckhardts.com>>
> wrote:
> > function callback(morefn) {
> > // do something ...
> > if (typeof(morefn) === 'function') {
> > moref();
> > }
> > }
> >
> > f = function () {
> > sendToServer('xyz', callback ? f : null);
> > };
>
> Are you sure this makes sense? The second last line will always evaluate
> to:
>
> sendToServer('xyz', f);
>
> And I don't see how this solves the issue I raised:
>
> var f;
>
> function callback(moreToDo) {
> // ...
> }
>
> f = function () {
> // ...
> };
>
> That's inconsistent, and thus confusing. Of course one could write:
>
> var callback, f;
>
> callback = function (moreToDo) {
> // ...
> };
>
> f = function () {
> // ...
> };
>
> Now things are consistent. But is that the way to go?
>
>


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

On Tue, Jan 4, 2011 at 7:53 AM, Erik Eckhardt <erik@...> wrote:
> I thought you were using a Boolean to indicate whether to make the
> return call to f.

No, that was correct. In the example code, I *was* using a boolean. Only
in the real code, things are more complex:

Based on what the XHR returns some calculations are performed, and - if
needed - another XHR is made.

> The point I was trying to get across is that you don't need the
> circularity.

What's bad about the circularity?

> xhr(params, function() {callback(); f();}); // circular call back to f

That would again be an infinite loop. The body of the anonymous function
would need to be at least slightly more complex. I don't think this is
increases readability.

Can I suggest there should not be allowed to be a line break between a
function and invoking it?

I had something like the following code

var a = b && (c || d)
(e || f).push(g);

where I had mistakenly missed a semi-colon and it was not picked up by
JSLint.

it causes an error because the result of "b && (c || d)" is a boolean and it
is being run as a function.

Would it ever be valid (or good practice) to have a newline before a
function execution or is there some other way to pick this up in JSLint?


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

If your example isn't the full story, please post an example of the full
story!

One thing that's wrong with the circularity is the cross-dependence as
JSLint is showing you. It's not a huge deal, but an annoying one, perhaps.

In any case I thought you might find it useful to use some of the techniques
I mentioned, where if a function determines that an additional step is
needed, it manages it within the function rather than making the callback
function have a hard coded reference back. The scheme you're using now seems
to make sense but as your application grows you may find that it becomes
unworkable. For example, what if you eventually have two functions that may
or may not need to be called after an xhr? Are you going to pass two
booleans? Or God forbid, a code indicating which functions to run? If from
the start you simply passed around single callback functions (which
themselves could be a string of functions) this problem would be solved.

function myxhr(url, params, callback) {
___//do stuff;
    doXhr(function() {myxhrreturn(xmlhttp, callback):});
}

function myxhrreturn(xmlhttp, callback) {
___//process xmlhttp object into a result
___callback(result);
}

function getsomething() {
___myxhr('http://example.com', 'a=1', function(result) {
______if (result.blah === 'gorp') {
_________dosomething;
______} else {
_________dosomethingelse();
______}
___}
}

Now your getsomething function controls everything and all your xmlhttp
requests can be handled the same way without having to make a hardcoded
call. If you want the logic in the myxhrreturn function, you can put it
there, but it's not required. Here's another way to do it:

function getsomething() {
      var cb;
      if (somecondition) {
______cb = function(result) {dosomething(result)};
___} else {
______cb = function(result) {dosomethingelse(result);};
___}
___myxhr('http://example.com', 'a=1', cb}
}

See how versatile this is? You only need a single callback, no extra Boolean
parameter is needed to indicate whether to call a hard-coded function name.
Any time you want more stuff to happen, you can load it into the passed
callback function somehow.

Erik

On Tue, Jan 4, 2011 at 1:47 AM, Felix E. Klee <felix.klee@...> wrote:

>
>
> On Tue, Jan 4, 2011 at 7:53 AM, Erik Eckhardt
<erik@...<erik%40eckhardts.com>>
> wrote:
> > I thought you were using a Boolean to indicate whether to make the
> > return call to f.
>
> No, that was correct. In the example code, I *was* using a boolean. Only
> in the real code, things are more complex:
>
> Based on what the XHR returns some calculations are performed, and - if
> needed - another XHR is made.
>
>
> > The point I was trying to get across is that you don't need the
> > circularity.
>
> What's bad about the circularity?
>
>
> > xhr(params, function() {callback(); f();}); // circular call back to f
>
> That would again be an infinite loop. The body of the anonymous function
> would need to be at least slightly more complex. I don't think this is
> increases readability.
>
>


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

In popular javascript libraries like jQuery that use chaining, line breaks
are common:

$('#id').appendChild(div)
___.css('background-color', 'blue')
___.show();

On Tue, Jan 4, 2011 at 5:50 AM, Luke Page <luke.a.page@...> wrote:

>
>
> Can I suggest there should not be allowed to be a line break between a
> function and invoking it?
>
> I had something like the following code
>
> var a = b && (c || d)
> (e || f).push(g);
>
> where I had mistakenly missed a semi-colon and it was not picked up by
> JSLint.
>
> it causes an error because the result of "b && (c || d)" is a boolean and
> it
> is being run as a function.
>
> Would it ever be valid (or good practice) to have a newline before a
> function execution or is there some other way to pick this up in JSLint?
>
> [Non-text portions of this message have been removed]
>
>
>


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

yes and I don't think that should be stopped, but would it make sense to
have

$('#id').appendChild
     (div).css
     ('background-color', 'blue').show();

I think that would always be a mistake?

On 4 January 2011 18:37, Erik Eckhardt <erik@...> wrote:

> In popular javascript libraries like jQuery that use chaining, line breaks
> are common:
>
> $('#id').appendChild(div)
> ___.css('background-color', 'blue')
> ___.show();
>
> On Tue, Jan 4, 2011 at 5:50 AM, Luke Page <luke.a.page@...> wrote:
>
> >
> >
> > Can I suggest there should not be allowed to be a line break between a
> > function and invoking it?
> >
> > I had something like the following code
> >
> > var a = b && (c || d)
> > (e || f).push(g);
> >
> > where I had mistakenly missed a semi-colon and it was not picked up by
> > JSLint.
> >
> > it causes an error because the result of "b && (c || d)" is a boolean and
> > it
> > is being run as a function.
> >
> > Would it ever be valid (or good practice) to have a newline before a
> > function execution or is there some other way to pick this up in JSLint?
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


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

Hi

Sorry if these ideas have been proposed before.
If they have been proposed, then they have not been implemented so I would
like to propose them again

I don't like to implement any third-party javascript (ie any code not
written by me) without gauging its quality with jslint.
In so doing I come across some constructions which may be questionable in
terms of style, but are unquestionably legal javascript.
Because at the moment jslint reports these constructions as  errors I
subsequently run into the "too many errors" limitation.

Three of these constuctions are:
1)
condition && func()
which only calls func if condition is true, perhaps a more normal
construction would be:
if (condition)
   func()

2) x = new constructorfunc
calling a constructor function which does not have parameters does not
require parens after the name of the constructor functions
This is another of those cases when the advantages of saving two characters
might be weighed against the possible confusion and decreased clarity, but
nevertheless this construction is very widely used and is legal so it would
be nice to have a tolerate option

3)
if (condition)
   action
I understand the reasons behind reporting non curly bracketed actions as an
error, but they are legal and they are used, so it would be nice to have an
option to tolerate them so that code not written by ourselves can be
analysed

Thanks


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

Most certainly a mistake, since a function invocation requires the opening
parenthesis right after the function name.

So even if the function returned a function which was immediately executed,
putting it on the next line would be a mistake. I for one vote for your
suggestion to flag the line breaking you suggested as invalid.

function fnReturningFn() {
    return function() {alert('Hello World!');};
}

fnReturningFn()(); // not sure if this is valid, but why not?

fnReturningFn()
___(); // I'm sure this isn't right

On Tue, Jan 4, 2011 at 11:14 AM, Luke Page <luke.a.page@...> wrote:

>
>
> yes and I don't think that should be stopped, but would it make sense to
> have
>
>
> $('#id').appendChild
> (div).css
> ('background-color', 'blue').show();
>
> I think that would always be a mistake?
>
>
> On 4 January 2011 18:37, Erik Eckhardt
<erik@...<erik%40eckhardts.com>>
> wrote:
>
> > In popular javascript libraries like jQuery that use chaining, line
> breaks
> > are common:
> >
> > $('#id').appendChild(div)
> > ___.css('background-color', 'blue')
> > ___.show();
> >
> > On Tue, Jan 4, 2011 at 5:50 AM, Luke Page
<luke.a.page@...<luke.a.page%40gmail.com>>
> wrote:
> >
> > >
> > >
> > > Can I suggest there should not be allowed to be a line break between a
> > > function and invoking it?
> > >
> > > I had something like the following code
> > >
> > > var a = b && (c || d)
> > > (e || f).push(g);
> > >
> > > where I had mistakenly missed a semi-colon and it was not picked up by
> > > JSLint.
> > >
> > > it causes an error because the result of "b && (c || d)" is a boolean
> and
> > > it
> > > is being run as a function.
> > >
> > > Would it ever be valid (or good practice) to have a newline before a
> > > function execution or is there some other way to pick this up in
> JSLint?
> > >
>


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

I like noting that a function execution without a function name is an error,
but how do we know it was a function execution and not parentheses for the
purpose of insuring math order of precedence?

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Erik Eckhardt
Sent: Tuesday, January 04, 2011 10:04 PM
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] Error Suggestion

Most certainly a mistake, since a function invocation requires the opening
parenthesis right after the function name.

So even if the function returned a function which was immediately executed,
putting it on the next line would be a mistake. I for one vote for your
suggestion to flag the line breaking you suggested as invalid.

function fnReturningFn() {
    return function() {alert('Hello World!');};
}

fnReturningFn()(); // not sure if this is valid, but why not?

fnReturningFn()
___(); // I'm sure this isn't right

On Tue, Jan 4, 2011 at 11:14 AM, Luke Page <luke.a.page@...> wrote:

>
>
> yes and I don't think that should be stopped, but would it make sense to
> have
>
>
> $('#id').appendChild
> (div).css
> ('background-color', 'blue').show();
>
> I think that would always be a mistake?
>
>
> On 4 January 2011 18:37, Erik Eckhardt
<erik@...<erik%40eckhardts.com>>
> wrote:
>
> > In popular javascript libraries like jQuery that use chaining, line
> breaks
> > are common:
> >
> > $('#id').appendChild(div)
> > ___.css('background-color', 'blue')
> > ___.show();
> >
> > On Tue, Jan 4, 2011 at 5:50 AM, Luke Page
<luke.a.page@...<luke.a.page%40gmail.com>>
> wrote:
> >
> > >
> > >
> > > Can I suggest there should not be allowed to be a line break between a
> > > function and invoking it?
> > >
> > > I had something like the following code
> > >
> > > var a = b && (c || d)
> > > (e || f).push(g);
> > >
> > > where I had mistakenly missed a semi-colon and it was not picked up by
> > > JSLint.
> > >
> > > it causes an error because the result of "b && (c || d)" is a boolean
> and
> > > it
> > > is being run as a function.
> > >
> > > Would it ever be valid (or good practice) to have a newline before a
> > > function execution or is there some other way to pick this up in
> JSLint?
> > >
>


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

Would it not be something like if the line above was an expression not
ending in an operator or semi colon? In a similar way to jslints existing
warning about invalid line break if you have

a
+b

Where jslint requires

a+
b
On 5 Jan 2011 06:54, "Rob Richardson" <erobrich@...> wrote:
> I like noting that a function execution without a function name is an
error,
> but how do we know it was a function execution and not parentheses for the
> purpose of insuring math order of precedence?
>
> Rob
>
>
> -----Original Message-----
> From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
> Behalf Of Erik Eckhardt
> Sent: Tuesday, January 04, 2011 10:04 PM
> To: jslint_com@yahoogroups.com
> Subject: Re: [jslint] Error Suggestion
>
> Most certainly a mistake, since a function invocation requires the opening
> parenthesis right after the function name.
>
> So even if the function returned a function which was immediately
executed,
> putting it on the next line would be a mistake. I for one vote for your
> suggestion to flag the line breaking you suggested as invalid.
>
> function fnReturningFn() {
> return function() {alert('Hello World!');};
> }
>
> fnReturningFn()(); // not sure if this is valid, but why not?
>
> fnReturningFn()
> ___(); // I'm sure this isn't right
>
> On Tue, Jan 4, 2011 at 11:14 AM, Luke Page <luke.a.page@...> wrote:
>
>>
>>
>> yes and I don't think that should be stopped, but would it make sense to
>> have
>>
>>
>> $('#id').appendChild
>> (div).css
>> ('background-color', 'blue').show();
>>
>> I think that would always be a mistake?
>>
>>
>> On 4 January 2011 18:37, Erik Eckhardt
> <erik@...<erik%40eckhardts.com>>
>> wrote:
>>
>> > In popular javascript libraries like jQuery that use chaining, line
>> breaks
>> > are common:
>> >
>> > $('#id').appendChild(div)
>> > ___.css('background-color', 'blue')
>> > ___.show();
>> >
>> > On Tue, Jan 4, 2011 at 5:50 AM, Luke Page
> <luke.a.page@...<luke.a.page%40gmail.com>>
>> wrote:
>> >
>> > >
>> > >
>> > > Can I suggest there should not be allowed to be a line break between
a
>> > > function and invoking it?
>> > >
>> > > I had something like the following code
>> > >
>> > > var a = b && (c || d)
>> > > (e || f).push(g);
>> > >
>> > > where I had mistakenly missed a semi-colon and it was not picked up
by
>> > > JSLint.
>> > >
>> > > it causes an error because the result of "b && (c || d)" is a boolean
>> and
>> > > it
>> > > is being run as a function.
>> > >
>> > > Would it ever be valid (or good practice) to have a newline before a
>> > > function execution or is there some other way to pick this up in
>> JSLint?
>> > >
>>
>
>
> [Non-text portions of this message have been removed]
>
>


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

On Tue, Jan 4, 2011 at 7:35 PM, Erik Eckhardt <erik@...>
wrote:
> no extra Boolean parameter is needed to indicate whether to call a
> hard-coded function name.

There may be a misunderstanding.

Thus, for your pleasure, below a more real-life example. Asides from
being more verbose, the only difference to my original example is the
addition of the parameter "liveCommentary". Together with the flag
"matchIsStillRunning" (formerly: "moreToDo") it forms the data returned
from the server.

   var sendToServer; // defined elsewhere

   function onCommentaryReceived(commentary, matchIsStillRunning) {
       // write live commentary: ...
       if (matchIsStillRunning) {
           requestCommentary();
       }
   }

   function requestCommentary() {
       sendToServer('Berlin:Munich', onCommentaryReceived);
   }

Naturally, one could rewrite this:

   var sendToServer; // defined elsewhere

   function requestCommentary() {
       sendToServer('Berlin:Munich',
                    function (commentary, matchIsStillRunning) {
                       // write live commentary: ...
                       if (matchIsStillRunning) {
                           requestCommentary();
                       }
                   });
   }

The second form avoids the circular function definition, but is it more
readable?

I think the confusion here is that you shouldn't be using the "circular
function" pattern you are using. In addition, you are using function
declarations rather than assigning a function statement to a variable.

What you want to do, it seems, is immediately run requestCommentary after a
matchIsStillRunning response comes back from the server.

What I can think of off the top of my head is:

var onCommentaryReceived = function (commentary, matchIsStillRunning) {
// write live commentary: ...
if (matchIsStillRunning) {
sendToServer('Berlin:Munich', onCommentaryReceived);
}
},
requestCommentary = function () {
return onCommentaryReceived(null, true);
};

Alternatively, and with less refactoring:
var onCommentaryReceived, requestCommentary;
onCommentaryReceived = function (commentary, matchIsStillRunning) {
// write live commentary: ...
if (matchIsStillRunning) {
requestCommentary();
}
};
requestCommentary = function () {
sendToServer('Berlin:Munich', onCommentaryReceived);
};

--- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
>
> On Tue, Jan 4, 2011 at 7:35 PM, Erik Eckhardt <erik@...>
> wrote:
> > no extra Boolean parameter is needed to indicate whether to call a
> > hard-coded function name.
>
> There may be a misunderstanding.
>
> Thus, for your pleasure, below a more real-life example. Asides from
> being more verbose, the only difference to my original example is the
> addition of the parameter "liveCommentary". Together with the flag
> "matchIsStillRunning" (formerly: "moreToDo") it forms the data returned
> from the server.
>
>   var sendToServer; // defined elsewhere
>
>   function onCommentaryReceived(commentary, matchIsStillRunning) {
>       // write live commentary: ...
>       if (matchIsStillRunning) {
>           requestCommentary();
>       }
>   }
>
>   function requestCommentary() {
>       sendToServer('Berlin:Munich', onCommentaryReceived);
>   }
>
> Naturally, one could rewrite this:
>
>   var sendToServer; // defined elsewhere
>
>   function requestCommentary() {
>       sendToServer('Berlin:Munich',
>                    function (commentary, matchIsStillRunning) {
>                       // write live commentary: ...
>                       if (matchIsStillRunning) {
>                           requestCommentary();
>                       }
>                   });
>   }
>
> The second form avoids the circular function definition, but is it more
> readable?
>

On Thu, Jan 6, 2011 at 6:27 AM, Jordan <ljharb@...> wrote:
> I think the confusion here is that you shouldn't be using the
> "circular function" pattern you are using.

The question is: Why? Is that considered bad practice? If so, a
reference please.

> In addition, you are using function declarations rather than assigning
> a function statement to a variable.

See my original post. There I mentioned that I would like to enforce
that convention for the whole project using JSLint. Only I wonder why
there is no such option.

> What I can think of off the top of my head is:
>
> [...]
> requestCommentary = function () {
> return onCommentaryReceived(null, true);
> };

That would work, but it's confusing to read. At least the function name
"onCommentaryReceived" should be changed.

> Alternatively, and with less refactoring:

See my original post. It's there already.

I started working on JSLint 10 years ago. It started as a demonstration of a
parsing technique [http://javascript.crockford.com/tdop/tdop.html]. I intended
to then create a JavaScript engine with the compiler and other components
written in JavaScript, but the language contained so many design errors that I
could not bring myself to replicate them all.

So instead I turned the parser into a code quality tool. I thought that
syntactic analysis would be sufficient, so I pulled out the code that created
the parse tree on the theory that that would make it faster. Such thinking is
almost always wrong, as it was indeed in this case. There was no noticeable
performance improvement, and I later discovered that a tree could make JSLint
even more useful.

So I have put the tree back in. You can see the tree by clicking on the [Tree]
button. It displays the tree that was produced by the most recent [JSLint] run.
I plan to completely change the way JSLint handles line breaking and indentation
using that tree. Someday I might also use the tree to write JSMax, the inverse
of JSMin.

So at the moment, JSLint does not consider indentation or line breakage. That
will come later. The only breakage that is checked currently are the cases that
are required because of the dreaded semicolon insertion. Breaking with style is
a surprisingly difficult problem.

Three options are dropped from the new edition. option.immed and option.eqeqeq
are now always on. There have proved to be very good practices, so continuing to
make them optional is not ultimately beneficial. option.lax is no longer needed.

JSLint is now smarter about code paths, so

     switch (exp) {
     case 1:
         if (blah) {
             return null;
         } else {
             return undefined;
         }
     case 2:
         x = 0;
         break;

does not require a break for case 1, but it does require a break for case 2. It
is now better able to detect strange loops and other convolutions.

This is a big change. All of my code looks good on the new edition, but I
haven't tested with yours. If I broke something, please report it. Thank you.

On Fri, Dec 31, 2010 at 6:33 PM, Felix E. Klee <felix.klee@...>
wrote:
> If I write code such as the following

Just figured that this is akin to:

   http://en.wikipedia.org/wiki/Mutual_recursion

And I checked: The latest version of JSLint, 2011-01-06, still
complains about an undefined function.

--- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
>
> If I write code such as the following, then JSLint complains that "f" is
> not defined.
>
>   var sendToServer;
>
>   function callback(moreToDo) {
>     // do something ...
>     if (moreToDo) {
>       f();
>     }
>   }
>
>   function f() {
>     sendToServer('xyz', callback);
>   }
>
> What's the most elegant solution to get rid of the error message?


`   var sendToServer;
`
`   function f() {
`       sendToServer('xyz', function (moreToDo) {
`           // do something ...
`           if (moreToDo) {
`               f();
`           }
`       });
`   }

On Sat, Jan 8, 2011 at 1:17 AM, Douglas Crockford
<douglas@...> wrote:
> at the moment, JSLint does not consider indentation

In fact that's a very good omission. The last version would report that
the following code is not properly indented. Reason: the return
statements are not positioned on a multiple of 4 spaces, if that is the
indentation depth.

   f(x,
     function() {
         return 1;
     });
   f2(x,
      function() {
          return 2;
      });

But:

1. The fix is strange to read:

   f(x,
     function() {
       return 1;
     });
   f2(x,
      function() {
       return 2;
      });

2. Specifying this indentation rule to auto-indenting editors is
   impossible or at least non-trivial.

> This is a big change. All of my code looks good on the new edition,
> but I haven't tested with yours. If I broke something, please report
> it. Thank you.

Seems to work great over here, thanks! I only had to correct the
placement of some curly braces. But I understand that this is necessary
for avoiding trouble with automatic semicolon insertion. Example:

   if (x == 1 &&
       y == 2)
   { // <-- better readable here, but to be avoided due to JS limitations

On Sat, Jan 8, 2011 at 4:05 PM, Douglas Crockford
<douglas@...> wrote:
> `   var sendToServer;
> `
> `   function f() {
> `       sendToServer('xyz', function (moreToDo) {
> `           // do something ...
> `           if (moreToDo) {
> `               f();
> `           }
> `       });
> `   }

Thanks for the suggestion! I guess I'll take this approach and put the
lengthy "do something" into a separate function.

Just thinking about it: I assume that having JSLint to *not* report an
error on circular function definitions is non-trivial. That is, if one
still wants to be warned about cases were an undefined function would be
called, such as:

   function f() {
       g();
   }

   f();

   function g() {
       // do something
   }

There's a new version of my Yahoo! Widget Tester Widget with JSLint Edition
2011-01-06 at http://tinyurl.com/5unocx  . It's also been submitted as an update
to the Yahoo! Widget Gallery.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
> So I have put the tree back in. You can see the tree by clicking on the [Tree]
button. It displays the tree that was produced by the most recent [JSLint] run.
>

I've not yet done anything with the tree, as I doubt most users would want to
see it. Perhaps a context menu item to display it would suffice.

> Three options are dropped from the new edition. option.immed and option.eqeqeq
are now always on. There have proved to be very good practices, so continuing to
make them optional is not ultimately beneficial. option.lax is no longer needed.

I've removed these.

> This is a big change. All of my code looks good on the new edition, but I
haven't tested with yours. If I broke something, please report it. Thank you.
>

Nothing important broke with my code, apart from having to reformat where I had

}
else

on successive lines.

--- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
>
> On Sat, Jan 8, 2011 at 1:17 AM, Douglas Crockford
> <douglas@...> wrote:
> > at the moment, JSLint does not consider indentation
>
> In fact that's a very good omission. The last version would report that
> the following code is not properly indented. Reason: the return
> statements are not positioned on a multiple of 4 spaces, if that is the
> indentation depth.
>
>   f(x,
>     function() {
>         return 1;
>     });
>   f2(x,
>      function() {
>          return 2;
>      });
>
> But:
>
> 1. The fix is strange to read:
>
>   f(x,
>     function() {
>       return 1;
>     });
>   f2(x,
>      function() {
>       return 2;
>      });
>
> 2. Specifying this indentation rule to auto-indenting editors is
>   impossible or at least non-trivial.
>
> > This is a big change. All of my code looks good on the new edition,
> > but I haven't tested with yours. If I broke something, please report
> > it. Thank you.
>
> Seems to work great over here, thanks! I only had to correct the
> placement of some curly braces. But I understand that this is necessary
> for avoiding trouble with automatic semicolon insertion. Example:
>
>   if (x == 1 &&
>       y == 2)
>   { // <-- better readable here, but to be avoided due to JS limitations
>

I'm aware of two beautifiers:  JSBeautifier.org and jsutility.pjoneil.net  Your
style looks like the style pjoneil uses.

What tools /  do you use to quickly fix JS code up to satisfy JSLint's warnings
and errors?

First I test the code's parsability, if I can get to the end of the code without
an error, it's good to go.  This is much harder to do these days, with more
stopping errors.

Without concern for code formatting:
I use closure compiler whitespace + pretty print mode to fix missing brackets. 
The drawback is that it eats empty constructor brackets, optional semicolons,
breaks up else if the hard way (becomes } else { if), and completely reformats
the code.  One advantage of this is that it reformats quotation marks for
consistency and precomputes some math constants.

I then fill the missing semicolons with jsutility.pjoneil.net (JSLint derived). 
The drawback here is that it also completely reformats your code.

I beautify it with jsbeautifier, and hunt down the less noisier warnings.

With concern for formatting:
I have JSLint parse the code and look for missing semicolons, and fill those in
by hand.

I have jsbeautifier beautify the code with indentation to match the document's
formatting and preserve lines.  This makes if\for\while (\(.*\)) (\w.*;)$ ->
if\for\while \1 {\2} a fast bracket fix with another beautification.  Then
targeting the other warnings.

I think i'll grab a previous version of JSLint since there are now so many error
stops over what were previously simple issues.

On Sun, Jan 9, 2011 at 9:46 AM, aceblchboy <aceblchboy@...> wrote:
> What tools / do you use to quickly fix JS code up to satisfy JSLint's
> warnings and errors?

None. But I run JSLint directly from my IDE:

   http://www.emacswiki.org/emacs/FlymakeJavaScript

This allows me to quickly jump to errors and fix them manually. I have
tweaked "jslint-for-wsh" to also warn about unused variables.

--- In jslint_com@yahoogroups.com, "aceblchboy" <aceblchboy@...> wrote:
>
> What tools /  do you use to quickly fix JS code up to satisfy JSLint's
warnings and errors?
>
> First I test the code's parsability, if I can get to the end of the code
without an error, it's good to go.  This is much harder to do these days, with
more stopping errors.
>
> Without concern for code formatting:
> I use closure compiler whitespace + pretty print mode to fix missing brackets.
The drawback is that it eats empty constructor brackets, optional semicolons,
breaks up else if the hard way (becomes } else { if), and completely reformats
the code.  One advantage of this is that it reformats quotation marks for
consistency and precomputes some math constants.
>
> I then fill the missing semicolons with jsutility.pjoneil.net (JSLint
derived).  The drawback here is that it also completely reformats your code.
>
> I beautify it with jsbeautifier, and hunt down the less noisier warnings.
>
> With concern for formatting:
> I have JSLint parse the code and look for missing semicolons, and fill those
in by hand.
>
> I have jsbeautifier beautify the code with indentation to match the document's
formatting and preserve lines.  This makes if\for\while (\(.*\)) (\w.*;)$ ->
if\for\while \1 {\2} a fast bracket fix with another beautification.  Then
targeting the other warnings.
>
> I think i'll grab a previous version of JSLint since there are now so many
error stops over what were previously simple issues.


I think you would do better to fix your code.

I don't recommend automating correction because of the likelihood of automatic
bug insertion. Using JSLint with an IDE seems to be the best alternative.

I think it is a shame to loose the eqeqeq option :

We have inherited an extremely large JS codebase. On all new code we use
eqeqeq, but old code we do not apply it - It is far more difficult to look
at someone elses code and convert == to === than it is add curly braces,
correct semi colons, line breaks and indentation. In fact we
don't recommend it because of the potential for inserting bugs, until that
code is being re-written or significantly re factored.

The change makes it impossible for us to convert old code to be nicer in
incremental steps using JSLint.

On 8 January 2011 00:17, Douglas Crockford <douglas@...> wrote:

>
>
> I started working on JSLint 10 years ago. It started as a demonstration of
> a parsing technique [http://javascript.crockford.com/tdop/tdop.html]. I
> intended to then create a JavaScript engine with the compiler and other
> components written in JavaScript, but the language contained so many design
> errors that I could not bring myself to replicate them all.
>
> So instead I turned the parser into a code quality tool. I thought that
> syntactic analysis would be sufficient, so I pulled out the code that
> created the parse tree on the theory that that would make it faster. Such
> thinking is almost always wrong, as it was indeed in this case. There was no
> noticeable performance improvement, and I later discovered that a tree could
> make JSLint even more useful.
>
> So I have put the tree back in. You can see the tree by clicking on the
> [Tree] button. It displays the tree that was produced by the most recent
> [JSLint] run. I plan to completely change the way JSLint handles line
> breaking and indentation using that tree. Someday I might also use the tree
> to write JSMax, the inverse of JSMin.
>
> So at the moment, JSLint does not consider indentation or line breakage.
> That will come later. The only breakage that is checked currently are the
> cases that are required because of the dreaded semicolon insertion. Breaking
> with style is a surprisingly difficult problem.
>
> Three options are dropped from the new edition. option.immed and
> option.eqeqeq are now always on. There have proved to be very good
> practices, so continuing to make them optional is not ultimately beneficial.
> option.lax is no longer needed.
>
> JSLint is now smarter about code paths, so
>
> switch (exp) {
> case 1:
> if (blah) {
> return null;
> } else {
> return undefined;
> }
> case 2:
> x = 0;
> break;
>
> does not require a break for case 1, but it does require a break for case
> 2. It is now better able to detect strange loops and other convolutions.
>
> This is a big change. All of my code looks good on the new edition, but I
> haven't tested with yours. If I broke something, please report it. Thank
> you.
>
>
>


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

On 9 January 2011 00:46, aceblchboy <aceblchboy@...> wrote:

>
>
> What tools / do you use to quickly fix JS code up to satisfy JSLint's
> warnings and errors?
>
> I use lintswitch (https://github.com/grahamking/lintswitch) to watch my
code, run jslint in the background, alert me of any errors, and display
warnings on the root window. It's a bash script that wires together inotify,
jslint, and imagemagick for output. Only tested on Ubuntu / Gnome. I'm lucky
enough not to have any legacy JS to maintain, so I fix the errors by hand.


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

Is it purposeful or a bug that when the onevar option is off it is
complaining about vars needing to be moved to the top of the function if
they appear in a for loop declaration, but not if they don't. e.g.


var func = function() {
  while(true) {
    alert("test 1");
  }
   var i = 0;  // no error
   i++;
};

var func = function() {
  while(true) {
    alert("test 2");
  }
   for(var i = 0; i < 9; i++) {  //line 13 - error
    alert("test3");
   }
};

*Error:*

Problem at line 13 character 7: Move all 'var' declarations to the top of
the function.

for(var i = 0; i < 9; i++) {

Problem at line 13 character 7: Stopping, unable to continue. (81% scanned).

If it is now a problem to use var in a for declaration, could the error be
more specific?

Also JSLint now seems to be stopping on a lot of errors rather than
continuing so more than one error can be fixed at once.Is it possible to
change JSLint to the way it used to work, so that if(a) b; (e.g. missing
curly brackets) is not a stopping error?


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