AST Generation w/ Comments : http://esprima.org/

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

End of line comments:
- Place them at same place token wise.
- Treat same as comments inside of lines.

On Thursday, May 3, 2012 10:25:54 AM UTC-5, Thom Blake wrote:
>
> It's a great idea, but making JS style computable isn't exactly easy. 
>  There are a lot of tradeoffs to navigate, especially when dealing with 
> concerns like maximum line length limit.  Tools like minifiers can do some 
> wonderful things by parsing the JS and creating an AST, but in doing so 
> they discard comments, which are one of the really tricky things to retain 
> when parsing.  uglify.js, for example, discards comments.  Beautifiers 
> often work directly on the source code without understanding it, which 
> works if you use certain really simplistic styles, and that allows you to 
> retain comments pretty much where they should go, but it's not a fully 
> general solution.
>
> That said, if anyone *does* have one of these, please let me know:
>
>  - a tool that solves this problem entirely
>  - a completely general algorithmic description of how to break long lines 
> for each coding style
>  - a JS parser that somehow stores comments on the AST so that you can put 
> them back roughly where they go
>  - a conceptual design for such a parser (note that comments can (pretty 
> much) go between any two tokens, and end-of-line comments are particularly 
> pernicious).
>  - an algorithmic description of where to put end-of-line comments when 
> the structure of the lines changes due to various sorts of beautification.
>
> -Thom
>
> On Thursday, May 3, 2012 8:45:29 AM UTC-4, Mark Volkmann wrote:
>>
>> One way to end the debates about JS style preferences, or at least 
>> reduce them, would be to write a really good JS code formatter. It 
>> could use a config file to specify preferences like: 
>>
>> - use ASI or don't 
>> - comma-first or comma-last 
>> - maximum line length or no limit 
>> - indentation (2, 3, 4 spaces or tabs) 
>> - force braces on if statements and loops or don't 
>> - allow single-line if statements and loops or don't 
>> - remove trailing whitespace 
>> - function comment style 
>> - and more 
>>
>> Maybe this could be used in conjunction with Git hooks to 
>> automatically format code in your preferred style on checkout or pull 
>> and automatically format code in the preferred style of the repo. 
>> owner on push or pull request. 
>>
>> -- 
>> R. Mark Volkmann 
>> Object Computing, Inc. 
>>
>

-- 
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

Reply via email to