I hope this conversation leads to nothing. We all love JS is because It is a language built for everyone. Since we can use whatever the style we wish. That's why JS is so popular.
Choose a style for you and your team. That seems enough for me. On Fri, May 4, 2012 at 11:57 PM, Bradley Meck <[email protected]>wrote: > First and foremost, this is a pretty printing problem, something that > absolutely must reverse correctly. Initial implementations should focus on > that more than the complexity of heuristics. Ideally it would not change > any order of tokens as then it would cause reversal to be non-trivial. If > the tool makes a line comment at end of line from comma last to comma > first, it should not move the comment in terms of tokens. If it looks ugly > from the pretty printer it is still significantly better than causing the > chaos of errors in reversing pretty printing due to moving tokens. > > As for the line break issue, if you are breaking lines up, the > determination of where the lines end is a complex choice that can be > determines after a basic algorithm is in place. Ideally all the > possibilities you mentioned would end up as configuration options. > Backtracking should not be terrible since lengths of subtrees can be > examined rather than on a token level: > > x + (y + z) + 1 > > Could be configured to be treated as: > > x + a + 1 > > Still, the basic algorithms I mention are starting points. Much like > JSHint, configuration is king in this area not having overly complex > heuristics (unless you want to add that yourself plus the configuration > options, in which case more power to you). > > On Friday, May 4, 2012 8:56:26 AM UTC-5, Thom Blake wrote: >> >> >> >> On Thursday, May 3, 2012 11:57:14 AM UTC-4, Bradley Meck wrote: >>> >>> AST Generation w/ Comments : http://esprima.org/ >>> >>> Awesome. Will check that out posthaste. >> >> >>> Line breaks: >>> - if indent < length >>> - - indent or no indent on line break (configurable / amount) >>> - - operator at end of line (to avoid ASI confusion / make the >>> formatting easier to generate) >>> - if indent + minimal text > length >>> - - throw warning, treat same as above >>> >>> >> One problem with this is that there isn't an obvious place to break >> really long lines. For example, if you have a line like >> apple().banana().carrot().**donkey().elephant().frog().** >> grape().hornet().igloo().**javascript().kitkat().lemur().**monkey().nero() >> , you might choose to recursively break it at the most parent operator >> until the lines are short enough, in which case you have one really long >> line followed by a bunch of short ones, or you might choose to recursively >> break it at the most child operator, in which case you have a bunch of >> short lines followed by one really long one, or you might choose to break >> it in "the middle" of the text line (say, about 40 characters), but then >> you run into problems if the operators are nested differently and you've >> thus chosen an unintuitive place to break the line. For example, the >> following seems to confuse order-of-operations: >> >> apple() * banana() * (carrot() + donkey() * >> elephant() + frog()) + grape() >> >> Also, depending on indentation style, it might be difficult to figure out >> how much to indent until you've actually broken the line, and so the >> algorithm will probably have to try and backtrack a bunch of times to get >> it right, unless information about indentation style can somehow be >> represented as part of the main line-breaking algorithm. >> >> And insisting operators go at the end of lines doesn't work either, as >> one of the style options I'd like to have configurable is whether operators >> go at the beginning or end of lines. Personally, I'd default to beginning. >> >> >>> End of line comments: >>> - Place them at same place token wise. >>> - Treat same as comments inside of lines. >>> >>> >> There are a couple of problems with that. Since pretty-printing the code >> might change the positions of tokens, the position of the comment might not >> end up at the end of the line. It might be okay to just turn it into a >> multiline comment and leave it in-place, but it strikes me as probably the >> wrong thing to do in most cases. Also, there are some cases where they >> obviously should *not* stay in the same place in terms of tokens. For >> example, if you have comments after items in a comma-separated list, and >> change from comma-first to comma-last or vice-versa, the obvious thing to >> do is invert the order of the comma and the comment, so that the comment >> stays on the same line as the list item. But since that's a special case >> that breaks that rule, it's not obvious that there are not myriad other >> special cases. >> >> You could solve this, as some do, by just not using end-of-line comments >> like that, but that's a style restriction and the point of the tool was to >> *stop* style bikeshedding. >> >> -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Arunoda Susiripala @arunoda <http://twitter.com/arunoda> <http://gplus.to/arunoda>https://github.com/arunoda http://www.linkedin.com/in/arunoda -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
