Re: JSLint and JavaScript: The Good Parts.
- From: Lex Hider <lex lists gmail com>
- To: gnome-shell-list gnome org
- Subject: Re: JSLint and JavaScript: The Good Parts.
- Date: Sat, 13 Mar 2010 13:21:00 +1100
On 13 March 2010 05:38, Dan Winship
<danw gnome org> wrote:
On 03/12/2010 07:04 AM, Lex Hider wrote:
> I ran the attached perl script to get around errors reported for: let,
> const, and multiple variable assignment (e.g. [a,b] = callFunc();),
> which appear to be mozilla specific features.
yeah, there's a bug in bugzilla (against gjs) about trying to get jslint
working with the moz extensions
Just found another alternative I'm investigating:
It appears to have the ability to enable/disable different classes of errors.
> Would a patch for any of the following be worthwhile?
>
> * missing terminal semi-colons.
yes
> * if statement's with single statement but no braces.
no, our style allows that (although if there are places where one branch
has braces and the other doesn't, you can fix that).
> * unused variables.
yes
> * changing use of == and != to === and !== .
> if (foo != null) // should be: if (foo !== null)
> Crockford is strong on this, referring to == and != as the evil twins to
> ===/!== .
Changing them blindly would break some things. (Eg, I know there are
places where people have taken advantage of the fact that 0 != null but
undefined == null; changing != to !== would make both 0 and undefined
compare as not equal.) You could argue that doing that is bad style and
should be written differently. But at any rate, this isn't something you
can change without examining the code carefully.
I'm aware that many of these suggestions are somewhat trivial formatting issues.
However, this one (== vs ===) does seem to be a very worthwhile change to the style guide to consider.
Wouldn't it be clearer if code depending on (0 != null but undefined ==null) be made explicit?
> //changing this
> if (fee && fi
> && foe && fum)
> //to
> if (fee && fi &&
> foe && fum)
So, I prefer the latter style anyway, but this is a bad example since it
wouldn't be valid for the interpreter to put a semicolon in there anyway...
-- Dan
diff --git a/js/ui/panel.js b/js/ui/panel.js
index 6cce4c6..1715050 100644
--- a/js/ui/panel.js
+++ b/js/ui/panel.js
@@ -39,7 +39,7 @@ const TRAY_BORDER_WIDTH = 0;
const HOT_CORNER_ACTIVATION_TIMEOUT = 0.5;
-const STANDARD_TRAY_ICON_ORDER = ['keyboard', 'volume', 'bluetooth', 'network', 'battery']
+const STANDARD_TRAY_ICON_ORDER = ['keyboard', 'volume', 'bluetooth', 'network', 'battery'];
const STANDARD_TRAY_ICON_IMPLEMENTATIONS = {
'bluetooth-applet': 'bluetooth',
'gnome-volume-control-applet': 'volume',
@@ -130,7 +130,7 @@ TextShadower.prototype = {
child.allocate(childBox, flags);
}
}
-}
+};
/**
* AppPanelMenu:
@@ -256,10 +256,10 @@ AppPanelMenu.prototype = {
// If the currently focused app hasn't changed and the current
// startup sequence hasn't changed, we have nothing to do
- if (focusedApp == this._focusedApp
- && ((lastSequence == null && this._activeSequence == null)
- || (lastSequence != null && this._activeSequence != null
- && lastSequence.get_id() == this._activeSequence.get_id())))
+ if (focusedApp == this._focusedApp &&
+ ((lastSequence == null && this._activeSequence == null) ||
+ (lastSequence != null && this._activeSequence != null &&
+ lastSequence.get_id() == this._activeSequence.get_id())))
return;
this._focusedApp = focusedApp;
@@ -301,7 +301,7 @@ AppPanelMenu.prototype = {
this.emit('changed');
}
-}
+};
Signals.addSignalMethods(AppPanelMenu.prototype);
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]