Re: Free source code diagramming programs [message #48430 is a reply to message #48304] |
Fri, 14 April 2006 11:50  |
Al Balmer
Messages: 3 Registered: April 2006
|
Junior Member |
|
|
On 14 Apr 2006 07:40:59 -0700, "mitch grunes" <idlwizard-1@yahoo.com>
wrote:
>> I wouldn't ask a pretty printer to format anything that won't compile.
>> Count your parentheses and braces. Check the definition of strcmp().
>
> You win. My keyboard made minor errors.
>
Darn cheap Chinese keyboards!
> The idea is still the same.
But remains to be demonstrated. In the example given, I could have
corrected the code sufficiently that reformatting was possible (the
unbalanced braces and parens) but you could legitimately claim that
the result wasn't what you intended.
I did, in fact, balance the code and run the beautifier. It left the
comments (which you seemed to be concerned about) in the same relative
position, but the formatting of the last line depended on where I put
the balancing parens.
> When a programmer formats his/her code
> and/or comments carefully, pretty printers destroy it. Here is another
> example, FORTRAN only, in which you have a useful comment table that
> explains things (again, you need a fixed width font).
>
> c variable Initial Value Meaning Permanence
> c --------- ------------- ------------------ ----------
> a = 5 ! Happiness quotient Transitory
> b = 17 ! Unhappiness factor Changeable
> garbage = 3 ! Time differential Irrelevant
> silly = 5.23 ! Semantics Who cares?
> example = 18 ! Meaningfulness A lifetime
> ohmy = 999 ! Wizard of Oz Forever
>
Unfortunately, I don't have a pretty-printer for FORTRAN, but I
believe that indent would process this without destroying the layout.
Perhaps someone else could try it.
> Again, a pretty printer will kill all this extremely useful
> information. If you casually apply a pretty printer to tens of
> thousands of lines of code, and that gets passed on to the next
> benighted programmer, you will lose something he/she will need to
> understand.
>
No, what will happen, in the usual case, is that the program will
become much easier to read, and the maintenance programmer will take
less time and make fewer mistakes.
Been there, done that. For over 30 years.
> Enough.
If you say so.
--
Al Balmer
Sun City, AZ
|
|
|