@Gordon, in regard to JS's CR LF behavior: I'm aware of some, of which the worst is a line ending with a blank return statement and - for what ever reasons - the value to return on the following line. Doing JS since shortly after its inception, I learned to live quite well with that and - for my own sanity - I go even further also for other things that the strict syntax is not asking for. For example, in (multi termed) logical expressions, returning of expressions, etc., I use extra parentheses with never ever having had regrets abot. If the runtime has issues with that, let's fix it there. (The last sentence may though lead to a regret(s), because I do not know what I'm talking about in respect of Espruino, even though I built multiple VMs and JIT (execution) code generators for custom / tech / business domain languages incl. garbage collection in all kinds of environments, from main frame 'down' to single chip computers - some of them now running 30+ years and still going - deep buried in all kinds of apps.)
To me, it does not matter if the compiler can 'read' it or not - of course I do, because if the compiler cannot, there is a syntax error and never useful execution. To me it matters that I can read it, and that I quickly understand what's (obviously) going on, even when just glancing over it. It matters to me that the style of writing conveys as much of the underlaying semantics as possible so that a human can read it like a good novel. Coding is an art - and hard work: only the fifth to tenth (refactored) version is worth 'hanging on walls' (even though it is still true that 'good looking' things are not necessarily good, but good things do look good... because the inner beauty shines through).
A major part of good coding is choosing the right names for the 'things' - even with space constraints and thus shortened names. I'm aware of minification which can take care of drawback of long names and lots of comments... but how many pieces of code do really go all the way through that final step? If is not done in a JIT - just in time - way, then then JS's delivered promise of quickest round trip gets 'lost in translation'.
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.
@Gordon, in regard to JS's CR LF behavior: I'm aware of some, of which the worst is a line ending with a blank return statement and - for what ever reasons - the value to return on the following line. Doing JS since shortly after its inception, I learned to live quite well with that and - for my own sanity - I go even further also for other things that the strict syntax is not asking for. For example, in (multi termed) logical expressions, returning of expressions, etc., I use extra parentheses with never ever having had regrets abot. If the runtime has issues with that, let's fix it there. (The last sentence may though lead to a regret(s), because I do not know what I'm talking about in respect of Espruino, even though I built multiple VMs and JIT (execution) code generators for custom / tech / business domain languages incl. garbage collection in all kinds of environments, from main frame 'down' to single chip computers - some of them now running 30+ years and still going - deep buried in all kinds of apps.)
To me, it does not matter if the compiler can 'read' it or not - of course I do, because if the compiler cannot, there is a syntax error and never useful execution. To me it matters that I can read it, and that I quickly understand what's (obviously) going on, even when just glancing over it. It matters to me that the style of writing conveys as much of the underlaying semantics as possible so that a human can read it like a good novel. Coding is an art - and hard work: only the fifth to tenth (refactored) version is worth 'hanging on walls' (even though it is still true that 'good looking' things are not necessarily good, but good things do look good... because the inner beauty shines through).
A major part of good coding is choosing the right names for the 'things' - even with space constraints and thus shortened names. I'm aware of minification which can take care of drawback of long names and lots of comments... but how many pieces of code do really go all the way through that final step? If is not done in a JIT - just in time - way, then then JS's delivered promise of quickest round trip gets 'lost in translation'.