|Approaches to code formatters pioter@terramail.CUTTHIS.pl (Piotr Zgorecki) (2002-12-01)|
|Re: Approaches to code formatters firstname.lastname@example.org (Alex K. Angelopoulos) (2002-12-03)|
|Re: Approaches to code formatters email@example.com (Nils M Holm) (2002-12-03)|
|Re: Approaches to code formatters firstname.lastname@example.org (Ira Baxter) (2002-12-03)|
|Re: Approaches to code formatters email@example.com (2002-12-07)|
|From:||"Ira Baxter" <firstname.lastname@example.org>|
|Date:||3 Dec 2002 00:40:50 -0500|
|Posted-Date:||03 Dec 2002 00:40:50 EST|
We have formatters that work by parsing the source language.
Yes, they have trouble with badly placed preprocessor directives.
However, we accept (parse) preprocessor directives in the places
they tend to be used, so this isn't quite as bad as it might first sound.
We've found that only a little bit of editing to get rid of the truly
ugly ones is generally necessary, and IMHO, the source code
readability is often directly improved as a consequence of just
this editing anyway. The additional payoff is really nice formatting,
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com
"Piotr Zgorecki" <pioter@terramail.CUTTHIS.pl> wrote in message
> Did anybody write a code formatter for C-like languages ? I'm writing
> one at the moment, and the farther I go, the more I dislike the
> approach I have taken. I decided not to have any parser, instead I
> merely take the tokens that lexer feeds me, and try to format "by
> hand", which means lots of scans through a token buffer. Now this is
> good for a simple paren or bracket indentation, but get's ugly with
> anything less trivial.
Return to the
Search the comp.compilers archives again.