*** evil topposting and overlong lines repaired ***
David said:
I was thinking about improving my C2F -- C to Fortran translator
tool by inserting a "off-the-shelf" braces insertion tool in its
"front end" processing (it already invokes a old DOS CPP
pre-processor to remove macros).
But since a Google search doesnt reveal a braces insertion tool,
I am currently inclined to start a project to write one.
With the existing input parsing code provided by C2F to give me
a start, I shud be able to provide a "cbraces.exe" tool for
testing (and feedback) by anyone interested..
In a few days, try looking in my index of files at:
http://home.cfl.rr.com/davegemini
Please do not toppost.
I suggest that your whole idea is flawed (or requires much more
detail). The expression of an algorithm or section of code
should not usually be forced into such a limited arrangement. As
an example, I will frequently code as follows:
if (conditiona) docondastuff();
else if (conditionb) docondbstuff();
else if (conditionc) docondcstuff();
....
else dodefaultstuff();
which is compact, closely allied to a table, and easily
maintained. It is extremely easy for the reader to follow the
flow of control. Such a 'table' may occupy a single screenful,
but if passed through your filter will become inscrutable. Use
of indent will probable foul it also, but it will only double the
line count, while your filter would quadruple it.
I will concede that there can be other reasons for such
reformatting, such as convenient setting of debugger
breakpoints. These still do not require the addition of multiple
sets of braces. It amazes me that people who often squeal about
the use of redundant clarifying parentheses in logical, return,
sizeof expressions also often insist on such redundant
obscurative braces.
All this is worth an observation or two, but should not
degenerate into a style war.