Not necessarily related to the new code completion feature is the fact that after detecting too many (leading comma) warnings, the IDE gives completely up with code analysis / JSLINT. It gives up to the point to not even anymore point out real errors. This makes you believe your code has no errors. When you upload such code, it will make your Web IDE command pane to hang without any comment or (clear) indication. The (send-completed) prompt '>' is not showing and the command pane becomes unresponsive.
Warnings - nota bene - should not make the code analyzer / LINT to quit and leave the user in the dark about the presence of actual errors further along in the code. What makes it worse, even the lowest warning, such as 'Mixed spaces and tabs' count and are the straw breaking the camel's back. Warnings should not go into the error count threshold - they should have a count on their own. Not that I'm not sympathetic to 'nudging' to write good code - but when it goes to this extent, it takes more away from JS' freedom than it contributes to 'being helpful'. (Strict) formatting rules can help detect bad code... and I subdue myself to such rules - and they are a great help. Unfortunately,the commonly applied formatting does it (for me) the wrong way: it goes (only) for the syntax instead of reflecting the semantics.
In my case, a few line after the last indicated warning I missed a closing bracket in an array element reference. Uploading the code just 'freezes everything'. I figured it out by playing 'Mystery Murder Game': exclusion and inclusion of code section until I got my prompt back, and then honing in ont the missing ']'... ;-)
This is the code section of a larger program that gave me some grief because of the code analyzer's / LINT's short breath. Line 1. in below code is line 104 in the larger program (see http://forum.espruino.com/conversations/127039/ - Exploring 2.8" Color TFT Touch LCD by PacMan Game attempt)
var B = // board
{ g: null
, ini: function(g) { this.g = g; }
, v: function(c,a) {
var v = c.charCodeAt(0) - 64; v = (v < 32) ? v : 32 - v;
return (v * P.w);
}
, bs: // borders "XY[Steps Right|steps left]..." filled polygons
// [ "M@MMann","@@Mannam","M]MoAPN","@]MANPA"
[ "AACBC","FADBD","LaADA","OADBD","UACBC"
, "AECAC","FEACcACcA","IEGACcACc","REAGACcAC","UECAC"
, ">HFDACe",">LEadBa","UHFDACe","ULEadBa"
, "IKBAAcA","NKBDACa","JNEAE"
, ">NFDACe",">REadBa","FNADA","RNADA","UNFDACe","UREadBa"
, "IQGACcACc"
, "ATCDACb","FTDAD","OTDAD","UTCABcA"
, "?WBAB","FWACcAIAE","IWGACcACc","RWACeAIAC","XWBAB"
, ">LAmMan","LaNMano",">RAKmAN","L]NkALO"
]
, d: function() { G.c(); this.dbs(); } // draw
, dbs: function() { var _this = this; // draw borders
G.sClr(2);
this.bs.forEach(function(b){ _this.db(b); });
}
, db: function(b) { var d = 0, v = 0; // draw border
var bs = b.split(""), x = 0, y = 0, l = 1, ll = bs.length - 1;
var vs = // vertices
[ (x = Math.round(this.v(bs[0]) + 2.5 * P.w))
, (y = Math.round(this.v(bs[1]) + 2.5 * P.w))
];
while (l < ll) { l++; v = this.v(bs[l]);
if (v >= 0) { d++; } else { d--; v = 0 - v; }
d = (d > 3) ? d - 4 : (d < 0) ? d + 4 : d;
if/*sel*/ (d == 0) { y -= v; // N
} else if (d == 1) { x += v; // E
} else if (d == 2) { y += v; // S
} else { x -= v; // W
} vs.push(x); vs.push(y);
}
this.g.fillPoly(vs);
}
};
setTimeout(function(){
G.ini(g);
P.ini(g);
B.ini(g);
B.d();
},1500);
As you can take from screenshot attached at the bottom of this post, code analyzer / LINT gave up at line 115 and my (real) syntax error was in line 131. The code draws the static part of the PacMan game board - as 'cheated' from a prototype shot I found on the Web.
Click and watch the clip - EspPMBpardDraw.mp4 - to enjoy the drawing speed. - Little detail I noticed with the .fillPoly(): More than one concave gon makes some of the poly of the gon gone... that's why - for example - the 'home' of the ghosts in the center is made from three pieces. #fillpoly#draw#polygon
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Not necessarily related to the new code completion feature is the fact that after detecting too many (leading comma) warnings, the IDE gives completely up with code analysis / JSLINT. It gives up to the point to not even anymore point out real errors. This makes you believe your code has no errors. When you upload such code, it will make your Web IDE command pane to hang without any comment or (clear) indication. The (send-completed) prompt '>' is not showing and the command pane becomes unresponsive.
Warnings - nota bene - should not make the code analyzer / LINT to quit and leave the user in the dark about the presence of actual errors further along in the code. What makes it worse, even the lowest warning, such as 'Mixed spaces and tabs' count and are the straw breaking the camel's back. Warnings should not go into the error count threshold - they should have a count on their own. Not that I'm not sympathetic to 'nudging' to write good code - but when it goes to this extent, it takes more away from JS' freedom than it contributes to 'being helpful'. (Strict) formatting rules can help detect bad code... and I subdue myself to such rules - and they are a great help. Unfortunately,the commonly applied formatting does it (for me) the wrong way: it goes (only) for the syntax instead of reflecting the semantics.
In my case, a few line after the last indicated warning I missed a closing bracket in an array element reference. Uploading the code just 'freezes everything'. I figured it out by playing 'Mystery Murder Game': exclusion and inclusion of code section until I got my prompt back, and then honing in ont the missing ']'... ;-)
#warnings #errors #sentfaultycode #syntaxerror
This is the code section of a larger program that gave me some grief because of the code analyzer's / LINT's short breath. Line 1. in below code is line 104 in the larger program (see http://forum.espruino.com/conversations/127039/ - Exploring 2.8" Color TFT Touch LCD by PacMan Game attempt)
As you can take from screenshot attached at the bottom of this post, code analyzer / LINT gave up at line 115 and my (real) syntax error was in line 131. The code draws the static part of the PacMan game board - as 'cheated' from a prototype shot I found on the Web.
Click and watch the clip - EspPMBpardDraw.mp4 - to enjoy the drawing speed. - Little detail I noticed with the .fillPoly(): More than one concave gon makes some of the poly of the gon gone... that's why - for example - the 'home' of the ghosts in the center is made from three pieces. #fillpoly #draw #polygon
4 Attachments