On 14/12/09 13:24, samckayak wrote:
> When an array or object contains functions:
>
> var aFunct=[];
> aFunct[0]=fnMyFunction;
>
> What are the pros and cons of invoking the function using either of the
following:
>
> aFunct[0]();
>
> or
>
> (aFunct[0])();

Technically, both versions are correct, but since the parentheses around
aFunct[0] are redundant, and there are no ambiguities in aFunct[0](), I
can't see any advantage to the second version.
Back on topic: JSLint is fine with both.


regards,
stefan

When an array or object contains functions:

var aFunct=[];
aFunct[0]=fnMyFunction;

What are the pros and cons of invoking the function using either of the
following:

aFunct[0]();

or

(aFunct[0])();

Hello Aseem.

I agree with your post, except for one nitpick:

On 04/12/09 19:09, Aseem wrote:
> Incidentally, it's vulnerable to breaking if the function declaration is
tweaked:
>
> bar();
> var bar = function () {
>     // ...
> };

That isn't a function declaration, so it won't be hoisted, and it won't
be available at runtime. It's a function *expression*.

ACK, otherwise.

cheers,
stefan

Dear Sam,

I've got no idea what's happening with the site reports, i can not reproduce
this, a screenshot would be nice then i can look into it further.
Next to that you are so right about the multiple click anoyance.

Toolbar button will be in the next release.
I'm working on another project right now, so it will have to wait till january,
but i will fix it.

--- In jslint_com@yahoogroups.com, "samckayak" <samc@...> wrote:
>
> Martin,
>
> Two more wish-list items for the Dreamweaver JSLint extension:
>
> I've docked the JSLint "site reports" in the right-column of Dreamweaver in
the "Files and Assets" group.  Now, when the JSLint results appear, I don't need
to minimize the report to see all my code again.
>
> When the "Files and Assets" group is resized, the "Site Reports" becomes white
text on white background.  Not a big deal, but I thought you should know.
>
> If the "Site Reports" had an ICON to re-run the site reports, it would be much
easier to edit code, then nenew the JSLint results.  What now takes three
complete mouse clicks would be reduced to one mouse click.  A savings of 66%!
>

Good post, I agree. Just a quick note --

> > In this case, bar() will never be called before it's truly defined.
>
> Nor will it in the first example. Function declarations are hoisted,
> which means that 'bar' is guaranteed to be available before the first
> statement in a script is executed.

Yes, this will work:

bar();
function bar () {
     // ...
}

But I said it "feels" wrong, because in terms of readability, it's not obvious
that it works. A new Javascript developer might consider it a bug and try to
"fix" it.

Incidentally, it's vulnerable to breaking if the function declaration is
tweaked:

bar();
var bar = function () {
     // ...
};

That's why I understand the intent of the option, but in general, I agree with
you that it's a very inconvenient warning that often makes scripts *harder* to
read.

I was mainly differentiating between my two examples because if bar() is called
from within another function, it no longer seems "wrong" in any language, to any
developer, because it's clear that bar() isn't being called immediately. I.e.
it's no longer top-down programming.

Aseem

On 03/12/09 21:32, Aseem wrote:
> But I've been meaning to ask (and this is a good time to), what's
> really wrong with referencing functions *inside* a function body?
>
> I can see why this feels wrong:
>
> bar();
> function bar () {
>     // ...
> }
>
> But I don't see why this is wrong:
>
> function foo () {
>     bar();
> }
> function bar () {
>     // ...
> }
>
> In this case, bar() will never be called before it's truly defined.

Nor will it in the first example. Function declarations are hoisted,
which means that 'bar' is guaranteed to be available before the first
statement in a script is executed.

> In a way, it's backwards to require declarations before references.

It can be inconvenient, too. I've had a few situations where circular
dependencies between functions caused JSLint to emit "used before
defined" warnings, but there was no way to resolve it by reordering
function declarations alone. In the end, I used a function expression
('var foo = function () {...}') to break the cycle and work around the
warnings, but it did make the script harder to read. It could be argued
that circular dependencies aren't good style, but they're pretty common
in event-based systems with more than one point of entry.

Another problem with requiring a certain order for function declarations
is that this often reverses the logical flow. For example:

   function fetchFoo() {
     ajaxGet("abc", receiveFoo);
   }

   function receiveFoo(response) {
     return response.foo;
   }

Logically, "receive" follows "fetch", but the "undef" option requires
the declaration order to be inverted. In the same way, "undef" can
sometimes prevent the grouping or clustering of similar functions in a
script.
pauanyu's "Allow using a function before it was defined" would be nice
to have, but I'm not sure if's feasible to add it. Unless I'm missing
something, it would effectively require JSLint to

   a) do two consecutive runs in each scope, or
   b) to "remember" any calls to undeclared functions, and issue the
      warning at the end.


cheers,
stefan

That will definitely work for the meantime.

But I've been meaning to ask (and this is a good time to), what's really wrong
with referencing functions *inside* a function body?

I can see why this feels wrong:

bar();
function bar () {
     // ...
}

But I don't see why this is wrong:

function foo () {
     bar();
}
function bar () {
     // ...
}

In this case, bar() will never be called before it's truly defined.

In a way, it's backwards to require declarations before references. We went past
strict top-down programming a long time ago.

Just curious what your thoughts are. Thanks,

Aseem

--- In jslint_com@yahoogroups.com, Tim Beadle <tim.beadle@...> wrote:
>
> 2009/12/3 pauanyu <pcxunlimited@...>
> > How about changing the "Disallow undefined variables" to "Allow using
> > a function before it was defined"? That would handle Aseem's use-case
> > while still forbidding undefined variables.
>
> That sounds like a good idea - it would help people transition (I've
> done some of that to scripts I've taken over from someone else) in a
> similar way to the original option.undef.
>
> Cheers,
>
> Tim
>

2009/12/3 pauanyu <pcxunlimited@...>
> How about changing the "Disallow undefined variables" to "Allow using
> a function before it was defined"? That would handle Aseem's use-case
> while still forbidding undefined variables.

That sounds like a good idea - it would help people transition (I've
done some of that to scripts I've taken over from someone else) in a
similar way to the original option.undef.

Cheers,

Tim

How about changing the "Disallow undefined variables" to "Allow using a function
before it was defined"? That would handle Aseem's use-case while still
forbidding undefined variables.

--- In jslint_com@yahoogroups.com, "Aseem" <aseem.kishore@...> wrote:
>
> I think the intention is right, but to be honest, I've turned it off on a few
occasions as a workaround to allow code to be in a different order.
>
> By default, JSLint requires variables to be declared before they're used. That
makes sense in general, but there are times where helper functions are better
off lower in the file, physically.
>
> function SomeClass() {
>     // ...
>     helperFunction1();
>     helperFunction2();
> }
>
> function helperFunction1() {
>     // ...
> }
>
> function helperFunction2() {
>     // ...
> }
>
> To me, that code is just fine and readable. But it fails JSLint with undef set
to true.
>
> In this case, we could simply order the functions differently. If the helper
functions are purely stand-alone, sure. But in many cases, they depend on the
semantics of SomeClass, e.g. its properties. So it makes more sense to put them
below the SomeClass logic.
>
> Another way of writing it, aside from ordering it differently, to not fail
would be something like this.
>
> var helperFunction1, helperFunction2;
>
> function SomeClass() {
>     // ...
>     helperFunction1();
>     helperFunction2();
> }
>
> helperFunction1 = function () {
>     // ...
> }
>
> helperFunction2 = function () {
>     // ...
> }
>
> But I haven't seen any added benefit to that style. If you're nitpicking, that
in fact increases code size. But more importantly, I don't think it increases
readability or anything like that.
>
> So as a temporary workaround, I've been setting undef to false after verifying
that I'm not referencing any truly undefined variables.
>
> Aseem

I've updated my jslint wrapper:

    - Now supports the "predef" option.
    - Uses jslint 2009-11-24, which adds the "devel" option.

As usual, it's available from http://code.google.com/p/jslint4java/.

-Dom


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

I think the intention is right, but to be honest, I've turned it off on a few
occasions as a workaround to allow code to be in a different order.

By default, JSLint requires variables to be declared before they're used. That
makes sense in general, but there are times where helper functions are better
off lower in the file, physically.

function SomeClass() {
     // ...
     helperFunction1();
     helperFunction2();
}

function helperFunction1() {
     // ...
}

function helperFunction2() {
     // ...
}

To me, that code is just fine and readable. But it fails JSLint with undef set
to true.

In this case, we could simply order the functions differently. If the helper
functions are purely stand-alone, sure. But in many cases, they depend on the
semantics of SomeClass, e.g. its properties. So it makes more sense to put them
below the SomeClass logic.

Another way of writing it, aside from ordering it differently, to not fail would
be something like this.

var helperFunction1, helperFunction2;

function SomeClass() {
     // ...
     helperFunction1();
     helperFunction2();
}

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

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

But I haven't seen any added benefit to that style. If you're nitpicking, that
in fact increases code size. But more importantly, I don't think it increases
readability or anything like that.

So as a temporary workaround, I've been setting undef to false after verifying
that I'm not referencing any truly undefined variables.

Aseem

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I am thinking to remove the Disallow undefined variables. I added the option
originally to make the transition easier for people with sloppy code. But that
was years ago, and it is clear that disallowing undefined variables is simply
the right thing. Would anyone be bothered by losing the ability to turn it off?
>

On Wed, Dec 2, 2009 at 9:24 PM, Douglas Crockford <douglas@...>wrote:

> I am thinking to remove the Disallow undefined variables. I added the
> option originally to make the transition easier for people with sloppy code.
> But that was years ago, and it is clear that disallowing undefined variables
> is simply the right thing. Would anyone be bothered by losing the ability to
> turn it off?
>

I'm not bothered by this — it seems like a very sensible idea.

-Dom


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

I am thinking to remove the Disallow undefined variables. I added the option
originally to make the transition easier for people with sloppy code. But that
was years ago, and it is clear that disallowing undefined variables is simply
the right thing. Would anyone be bothered by losing the ability to turn it off?

--- In jslint_com@yahoogroups.com, "samckayak" <samc@...> wrote:
>
> JSLint warns: unexpected /*member
>
> when I add a new function to an object.  What is this warning about?

You have a /*member */ comment that lists all of the allowed member names, and
you are declaring a member name that is not on the list.

JSLint warns: unexpected /*member

when I add a new function to an object.  What is this warning about?

Sam

Martin,

Two more wish-list items for the Dreamweaver JSLint extension:

I've docked the JSLint "site reports" in the right-column of Dreamweaver in the
"Files and Assets" group.  Now, when the JSLint results appear, I don't need to
minimize the report to see all my code again.

When the "Files and Assets" group is resized, the "Site Reports" becomes white
text on white background.  Not a big deal, but I thought you should know.

If the "Site Reports" had an ICON to re-run the site reports, it would be much
easier to edit code, then nenew the JSLint results.  What now takes three
complete mouse clicks would be reduced to one mouse click.  A savings of 66%!

I added an Assume console, alert, ... (devel) option. It predefines globals that
are useful in browser development that should be avoided in production. It is
equivalent to

/*global alert: false, confirm: false, console: false, Debug: false, opera:
false, prompt: false */

What about alert() ?

2009/11/16 sks0001010 <simon.shepard@...>:
>
>
> Hmmm, not that I can think of off the top of my head, those 3 are the only
ones that get reused repeatedly for JS debugging in the different browsers.
>
> In another topic, I've been trying to use JSLint to validate HTML fragments,
but the templating system being used relies on having files with backend blocks
in it like <% print(someValue); %>
> it would be awesome, if there was a switch for tags with different starting
and ending delimeters that could be filtered out of the validation process, but
I don't know whether this becomes a bit out of the scope of the software ;-)
>
>
>
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>>
>> --- In jslint_com@yahoogroups.com, Simon Kenyon Shepard wrote:
>> > I was wondering whether there are any plans to bring in the option to
>> > be able to flag console.log statements in JSLint.
>>
>> That is a great suggestion. Perhaps there could be an option that determines
whether console, Debug, and Opera are predefined. You would turn it on for
development, and off for deployment.
>>
>> Are there other useful development time globals?
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
Toby Maxwell-Lyte
07816 836300
01443 449003

Hmmm, not that I can think of off the top of my head, those 3 are the only ones
that get reused repeatedly for JS debugging in the different browsers.

In another topic, I've been trying to use JSLint to validate HTML fragments, but
the templating system being used relies on having files with backend blocks in
it like <% print(someValue); %>
it would be awesome, if there was a switch for tags with different starting and
ending delimeters that could be filtered out of the validation process, but I
don't know whether this becomes a bit out of the scope of the software ;-)




--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, Simon Kenyon Shepard wrote:
> > I was wondering whether there are any plans to bring in the option to
> > be able to flag console.log statements in JSLint.
>
> That is a great suggestion. Perhaps there could be an option that determines
whether console, Debug, and Opera are predefined. You would turn it on for
development, and off for deployment.
>
> Are there other useful development time globals?
>

--- In jslint_com@yahoogroups.com, Simon Kenyon Shepard wrote:
> I was wondering whether there are any plans to bring in the option to
> be able to flag console.log statements in JSLint.

That is a great suggestion. Perhaps there could be an option that determines
whether console, Debug, and Opera are predefined. You would turn it on for
development, and off for deployment.

Are there other useful development time globals?

Hi,

apologies if this has already been covered.
I was wondering whether there are any plans to bring in the option to
be able to flag console.log statements in JSLint.
I often find console.log's in javascript where someone has been using
them for debugging in firebug but then it breaks in IE (or firefox
without firebug) but have failed to remove them for production code.
Ideally I would like to fold this into my CI checks with JSLint, I was
hoping someone might be able to point me in the right direction...

Cheers

Simon

> Changelog 1.0.0.4
> -Clicking "OK" in the JSLint configuration window closes the window
> -JSLint is now available from the "Site Reports"
> -Multiple file selection via "Site Reports"
> -DWlint now uses the "Site Reports" tab on the "Result" pane of
> dreamweaver to show results.
> -Double-clicking the error/warning in the results pane will scroll to
> the offending line of code.

These are great updates.  It is much more streamlined now.  I don't miss the
control character much.  It might be better if a jslint ICON could be place on
the COMMON toolbar.

The Results pane is the right place.  It is much more convenient there and the
double-click to find the line of code is great.

One thing I'd like to see in DW is a JavaScript formatter.  Even a good external
formatter for JS would be a help if you have any recommendation.

Thanks for this fine product.  You might want to post it in some other DW
forums.

Sam

Sam i tried to address some of your suggestions.
Could not find how to do a keyboard shortcut yet, so that remains on the
wishlist for now.

Changelog 1.0.0.4
-Clicking "OK" in the JSLint configuration window closes the window
-JSLint is now available from the "Site Reports"
-Multiple file selection via "Site Reports"
-DWlint now uses the "Site Reports" tab on the "Result" pane of
dreamweaver to show results.
-Double-clicking the error/warning in the results pane will scroll to
the offending line of code.

Download version 1.0.0.4 from http://dwlint.abisvmm.nl
<http://dwlint.abisvmm.nl/>


--- In jslint_com@yahoogroups.com <mailto:jslint_com@yahoogroups.com> ,
"samckayak" <samc@...> wrote:
>
> This extension has so improved my jslint/JavaScript workflow.
>
> Some suggestions:
>
> 1 - Single key (CTRL-J maybe?) to launch the validator.
>
> 2 - Launching the results pane should close the jslint control pane
automatically.
>
> 3 - Double-clicking the error/warning in the results pane should
scroll-to and highlight the offending line of code.
>
> 4 - Once Edits are made, how about a refresh button on the results
pane?  That would save a few steps.
>
> 5 - A Resizable results pane would let it fit nicely on the side or
bottom so the code edit window isn't covered.
>
> So... when will all this be done ;-)
>
> Sam
>



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

Hi all!  I'd like to let you know that I've released a new version of my
jslint wrapper, jslint4java.  The new features are:

  * Upgrade to JSLint 2009-10-04.
  * Add an ability to use an external copy of jslint.js, rather than the
bundled one.

As usual, it's available from:

   http://code.google.com/p/jslint4java/

Thanks,
-Dom


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

>
> Turn on the "Disallow undefined variables" option.
>
I will, and thank you.

Isn't it a jslint anomaly that "of" was not flagged as a global variable by
jslint?  I found that renaming "of" to "ox" resulted in a proper declaration of
"ox" as a global.

--- In jslint_com@yahoogroups.com, "samckayak" <samc@...> wrote:
>
> I'm working on a bookmarklet for ie6 which I hope explains the lack of
comments, short variables, and single-lined nature of the function.
>
> jslint seems to miss the global variable "of" in this function.  The semicolon
preceeding "of" should be replaced with a comma.  The variable "of" is not
reported as local or global.  Is "of" a keyword conflict?
>
> function(){var
o=document.body.style,oz=(o.zoom===''?'1':o.zoom);of=parseFloat(oz,10);o.zoom=(o\
f>3)?'1.':of*1.33;}


Turn on the "Disallow undefined variables" option.

I'm working on a bookmarklet for ie6 which I hope explains the lack of comments,
short variables, and single-lined nature of the function.

jslint seems to miss the global variable "of" in this function.  The semicolon
preceeding "of" should be replaced with a comma.  The variable "of" is not
reported as local or global.  Is "of" a keyword conflict?

function(){var
o=document.body.style,oz=(o.zoom===''?'1':o.zoom);of=parseFloat(oz,10);o.zoom=(o\
f>3)?'1.':of*1.33;}

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Brook" <mrprogguy@> wrote:
> > Given
> >
> > var b = javaApplet.Connect("javascript:OnConnect()");
> >
> > as the target of investigation, I inevitably see the "Script URL" complaint
from JSLint.  Since the method in question is by nature asynchronous, and the
interior Java cannot directly call script methods, this is the only method
available.  It would be nice to be able to suppress this since the warning is
visual static in the response.
>
>
>
> I don't recommend the use of javascript:urls in any context.
>

I don't think that's really in question.  The problem is that there aren't any
other mechanisms available for use.  One would hope that JSLint would be
adaptable to practical needs as well as ideals.