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
