Comments on: “prettyPrint” for JavaScript

By: Nuri Akman

Nuri Akman — Wed, 01 Jul 2009 13:55:01 +0000

Nice work! very useful! Great! Great!

By: Elijah Grey

Elijah Grey — Mon, 08 Jun 2009 22:47:10 +0000

I forgot to mention, but I think that when prettyPrint detects a function using implicit returns, it should prepend "return " to the body, as a normal function with a body of 1 is the same as a function without a body at all. For example, in SpiderMonkey, (function(){1}).toString() === (function(){}).toString().

By: Elijah Grey

Elijah Grey — Mon, 08 Jun 2009 22:32:45 +0000

James, JavaScript and ECMAScript are not the same thing. My code is valid JavaScript, not ECMAScript. JavaScript is just what SpiderMonkey and Rhino implement, as it's owned by Mozilla. ECMAScript is a standard based on Mozilla's JavaScript. Object destructuring in part of JavaScript 1.7 and implicit returns are part of JavaScript 1.8. Afaik, Opera supports basic object destructuring so things like [a, b] = [b, a] work but not advanced stuff. If you want to see some destructuring documentation (it's pretty lacking though), refer to New in JavaScript 1.7 on MDC. I also have another bug report: prettyPrint throw errors when it is passed E4X XML objects. Unlike the other stuff I have mentioned, E4X actually is part of an Ecma standard (specifically, ECMA-357). Stuff like prettyPrint(<foo><bar/><baz/></foo>) should work after you fix the bug. This can be easily fixed by using the native prettyPrinting in E4X using XML.prettyPrinting, XML.prettyIndent, and XML.prototype.function::toXMLString. It would involve temporarily changing the two prettyPrinting preferences temporarily and reverting them if needed. An alternative option for if you don't want to support JavaScript: You could just fix only the last bug I mentioned and just rename this library to prettyPrint for ECMAScript.

By: James

James — Sun, 07 Jun 2009 12:07:40 +0000

@Elijah, please forgive my ignorance but is that even “real” JavaScript? Glancing at the Rhino book and the ECMAScript specification I don’t see any mention of nested types as arguments in function definitions. I’ve never seen anything like function([a, b], {”(”:c, d}) { return a+b+c+d } in the wild… Could you link to some documentation or perhaps a specification detailing this?

As for your first issue (function() 1), I’ve fixed this as best I can.

Btw, you can force a function to be printed as an object like so:

prettyPrint( myFunction, { forceObject: true } );

By: Berny Cantos

Berny Cantos — Sun, 07 Jun 2009 07:45:46 +0000

Awesome! This script goes directly to my debugger toolbox.
A tool like this is a must in a coder’s daily routine, thanks!

By: Eric Schulman

Eric Schulman — Sat, 06 Jun 2009 21:37:59 +0000

Thanks James, great job!

By: Elijah Grey

Elijah Grey — Sat, 06 Jun 2009 20:33:22 +0000

prettyPrint throws errors if the function body is not wrapped in curly braces. Please fix this. For example, prettyPrint(function() 1) won't work. Also, the whole thing gets messed up when there is are any parenthesis in the arguments. The arguments are also removed from their destructuring context. For example, prettyPrint(function([a, b], {"(":c, d}) { return a+b+c+d }) puts a, b, c in the arguments cell and c}) { return a + b + c; in the body cell. If I remove the { return and }, it puts nothing in the arguments cell and ')': b}) b + 1; in the body cell. If the "(":c argument is replaced with ")":c, then prettyPrint thinks the arguments are a, b,, including that extra comma. Arguments can be very complex, so if there is any destructuring, it should be shown just like any object being passed to prettyPrint.

By: Donovan

Donovan — Sat, 06 Jun 2009 17:11:28 +0000

Cool. I did this a while ago, but not pretty. I found it useful to include flags for ‘hasOwnProperty’ and ‘keys only’ (variable names)

It’s really helped.

By: James

James — Sat, 06 Jun 2009 16:43:38 +0000

Thanks for the comments! :) @Sebastian & @Mert, The editor is E-textEditor. The theme is "iPlastic". @Mandrake, Are you using Chrome v.2? Older versions (<2) of Chrome don't support canvas.toDataURL; if this is the case then it should work now, please try it and let me know. (I would test it myself but my version of Chrome is too new)

By: Maverick

Maverick — Sat, 06 Jun 2009 16:13:19 +0000

seems to be a very useful thing.

thanks for that