So JS is popular because every team can write their code differently? That sounds ridiculous to me! I'd bet that many people have backed off of contributing to some open source JS libraries partially because they find the coding style of the author annoying. That's a loss for all of us!
The polite thing to do is contribute code that follows the conventions of the author. To do that for many libraries, you have to code in several styles. That does nothing but slow us down for no gain. R. Mark Volkmann Object Computing, Inc. On May 5, 2012, at 1:22 PM, Arunoda Susiripala <[email protected]> wrote: > 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 > 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 -- 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
