You are right, but this is our destiny with javascript. "great power comes with great responsibility" haha.
We just should to learn 2-3 different styles and use the one of the library. If the library isn't using one of the popular styles, don't use it and bitch the author. Best, Oleg github.com/kof On May 5, 10:02 pm, Mark Volkmann <[email protected]> wrote: > 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
