#PrettyPrint.c
32 messages in this thread
Ben,
But what if I like UNIX formatting? <grin>
I'll have to look at it, I like bracing like this:
if (….) {
do_this();
}
rather than:
if (…)
{
do_this();
}
I must admit I thought I'd like the 2nd method more when I first
started with C, but the folks I was working with had started out with the first
method and so I had to use it…and learned to like it. Now when I see code
the other way (2nd example)…it seems real awkard. Plus, I am doing alot of
programming under UNIX and all their example code is like example 1.
Don
No problem. "I've always done it that way" <grin>. IT's a hrad thing, trying to
improve the lot of programmers everywhere, but… oh, well. –Ben–
Interesting, different strokes again. I stay consistent by ALWAYS having my
open/close braces in exactly the same column for each level of indention
(indenture? 8). Thusly:
short walk()
{ char broiled; long time_coming;
do_something(); if(finished_doing_something)
{
do_something_else();
do_some_more_stuff();
} grab_a_nap(); return(to_sender); }
This makes it easier to keep straight in my feeble mind. But as I've said
before, whatever wanks yer cookies.
Rick
That's even harder to read than Ben's version! I'll stick with K&R. Different
strokes.
Rick,
Different strokes…etc. Actualy, your formatting got re-formatted by
CIS, but it looks like you had it:
if (something)
{
do_this();
and_that();
}
and so on. Geeze…do a little indenting anyway <grin>!
Really, I think CIS ate your indentions there…but even if they
didn't, if it's readable to you, and those to whom you distribute it.. then
that's all that matters.
Don
Don,
His indentations looked fine here, except for the last line, which had a few
statements after the right brace. Interesting.
Regards, Larry.
Larry,
Humm….the way I read it (and I'll go back…I'm using a different
term program now) while the if statement was indented from the 'main()'
statement, the statements that got executed if the 'if' was true were not
indented from the 'if' as I displayed in my message (I hope…I'll check it
also).
The way I saw Rick's example:
if (…)
{
do_this();
and_this();
}
My message was expressing that I would have hoped he meant:
if (…)
{
do_this();
and_this();
}
If he did mean the first example above (and that's the way you read it
also and feel it's correctly indented)…then I felt that that particular style
wasn't very readable for me…but if it's readable for you or him…then so be
it.
Don
Don,
It came throygh here as:
if (blah)
{
some(stuff);
more(stuff);
}
Regards, Larry.
Larry, howcum you got curly brackets into your message? All I ever get is
nice square ones. Is it my lifestyle, or does CIS show preferences to the
sysops? Huh? How come? Whyizzit, hey?
Curious User Person,
Doug
{Doug} {it must be CIS showing preference to sysops} or it could be SHIFT-[
SHIFT-]. {GRIN}
I am the shifty type, but CIS insists I go straight. Doug
Ahh… I always suspected Doug was shiftless, and now i know! <grin>
Regards, Larry.
See the repost; I blew it because I was depending on the term program to suppl
the dots (silly me). Your second example is close, except the braces are
indented to the level of the block they enclose, NOT to the level of the block
outside them. I am hopeful that the new posting came through correctly… I
put in my OWN dots on this one. 8)
Rick
Since we're all doing this <grin> and since I started the thread,
I wanted to put in my 2 pfennigs on this. I want to show how
we write our source here (not the rotal we, the company we),
and why. Here's a code fragment:
int oTheFuture(with,me)
BYTE with,*me;
{
int oTrouble;
BYTE it;
it = with;
for (; it < *me; it++)
{
switch(with)
{
case CLOSED:
{
DoGoodStuff(it);
break;
}
case THEJOINT:
{
LookAround(with,*me);
DoGoodStuff(it);
break;
}
default:
{
ForCloseOn(it);
break;
}
}
}
return((int)with+(*me));
}
–
Now – the reason for all the brackets, and the indentation;
because you can look at the code as you write it and immediatly
determine two important things. First (like any other good indent
style) you can tell if code is in the the right atomic group;
second, and this is unique to this style, you can tell if you've
missed a brace anywhere; because code exists ONLY every 8 char
positions – and braces too – only THEY show up on a set of 8
that is four off from the code; If code shows up at a brace level,
You Screwed Up!
Continued –
-continued- Next, we have to look at the atomic structure concepts
that 'c' uses, and how well (or not so well) it fits in with braces
as formatting/understanding tools. The braces are program statements;
they perform the function of making a group of statements an ATOMIC
operation… The language allows you to do a lot of things that are
inherently cryptic and/or hard to maintain. Like goto's. We don't
_like_ goto's… so we don't use them. Like this:
if (I=0; I < You; I=increment(Me))
switch(tracks)
{
case CLOSED:
break;
}
and(SoOn);
Now, you _don't_ want to do this! Because if you were to add a line
at the end of the switch, say next month, especially if the switch
was 30 lines long, it would NOT be clear that the if() ended there
except by studying the code; and you'd need to reformat the code
anyway to brace it, assuming you want the benefits I outlined due
to our bracing style… and of course, besides having to add braces
anyway if you want more than that 1 statement to work in there at
some future time, you wouldn't have those positioning cues with a
standard (read braces not having their own level) indentation
style. Another reason to use this is a reason that I specifically
brought into being – and is the title of the thread.
PrettyPrint. If you DO use this bracing style, then PP will take
your code and make SURE that the positioing is right; If it's NOT,
You can simply look through quickly with an editor (I use uedit,
and make it TELL me if I've screwed up) and see if there is a
boo-boo. It makes for a very open, clearly defined style. Now, I
don't _like_ things like this:
if (YouWantTo) ThenDoIt();
but – it's clearly defined, and IF you follow the rule that
an atomic if written underneath MUST use braces, then it's
easy to maintain, and not confusing to deal with and/or update.
"BUt c allows you to go line-to-line," I hear you cry;
-continued-
-continued- It's a language where c/rs and white space are under the
cruel heel of the semi-colon; well, it's another thing about the
language that works against you in this case; It's a boon for an
atomic statement; and according to the language definition, that
if (YouWantTo) ThenDoIt();
IS an atomic statement… but not according to me, it isn't…
Because I have taken the formatting to be an integral part of the
code – not some arbitrary thing that you throw in differently
with every function you write, and not something you'll have to
change because you forgot a statement; also not something you'll
have to change, or _feel_ like changing if you go from two
or more statements back to one. There's more to this discussion,
actually a lot more, but those two points are sufficient,
ESPECIALLY if you're going to (A) share the code or write modules
that someone else will have to interface to, and may need to
modify; (B) ever have to change it, especially 6 months later when
you not only don't remember the code, you can't reacall the name
of the program! <grin> <Clink!> (Sound of pfennig hitting bottom
of deep, dry, well) –Ben–
Ben,
Though (in case you didn't know) i am not a C coder, I rather like your style
as outlined, and for the reasons you gave. The only drawback I can see to it is
the extra verbosity, normally eschewed by C people.
One thing strikes me though, and that is that your prettyPrint porgram is, as
you said, meant to TELL YOU when you screwed up. (or was it UEDIT?, No matter)
Anyway, this smack of Pascalism, Mosula-2ism, and COMALism. Shouldn't you
really, for the sake of all other C programmers, bite the bullet and write the
code as K&R (praise be) meant 'er to be writ, with arcane indents, blocks of
punctuation and single character variables unspoiled by the verbose traces of
other languages?
Seriously, typos are the bane of programmers, yet need not be. C is helped by
afterthoughts… programs like lint, Cdecl, and prettyPrint abound to do the
things that a Modula-2 compiler does when you compile.
Regards, Larry.
Larry – I guess the reason that I like 'c' so much is that it's a language with
_enormous_ power, and it had the flexibility to be turned into one with a nice
syntax. I think the syntax and requirements of M2 are awkward and unreasonable;
I think that the K&R syntax isn't a hell of a lot better… IBM internal syntax
I can hardly talk about and remain coherent…. hehehe. PrettyPrint will do
_nothing_ to my source _unless_ I screw up. It doesn't change my indents, it
doesn't move my brackets… because I code that way anyhow. <grin> Unless, as I
say, I screw up. –Ben–
Come on, Larry, you're still attributing things to the LANGUAGE which are the
fault of the programmers:
"Shouldn't you… for the sake of… C PROGRAMMERS… write the code… with
arcane indents, blocks of punctuation and simple character variables unspoiled
by verbose traces of other languages?" Sheesh, gimme a break. Scr*w what K&R
might want. Write CLEAN, READABLE, MAINTAINABLE CODE! 8)
"Typos are the bane of programmers… C is helped by afterthoughts." Har. In
lots of cases C is better off than other languages. Try typing INRQO when you
meant INRQ0 in FORTRAN or BASIC or yes, even assembly language and see what
happens. The compiler/interpreter/assembler won't complain, but neither will
your code run. C will inform you that you have used an undeclared variable.
I have seen some TERRIBLE code written in FORTRAN and BASIC, but I've seen some
pretty good stuff too. Nearly everyone hates COBOL, but a lot of that is from
the shortcuts: I've seen COBOL from crackerjack programmers that is really well
done and almost looks structured. Even assembly language can be used or
abused. C is no exception, and I doubt Pascal, Modula, or Ada are either.
Let's be fair to ALL the languages. It's a poor workman who blames his tools.
If programmer "x" writes unreadable code in language "y", which one is REALLY
at fault?
Rick
Well, I rather like it. I has a good structure, and it's easy to read. I'd
give it a 92. 8)
Seriously, it's VERY close to the style I use. You "atom" a few more things
than I do, but you've explained why, your reasons are valid, and the extra
braces don't hurt a thing in the world, so they should be there.
<Sigh> What is the world coming to? Only the 11th day of the year and I've
already agreed with Ben once? Arrrrg!
Rick
As long as we're sharing… Here's my style of indents
{
int oTrouble;
BYTE it;
it = with;
for (; it < *me; it++) {
switch(with) {
case CLOSED: {
DoGoodStuff(it);
break;
}
case THEJOINT: {
LookAround(with,*me);
DoGoodStuff(it);
break;
}
default: {
ForCloseOn(it);
break;
}
}
}
return((int)with+(*me));
}
Putting the opening braces on the same line as a command allows my C mode mods
for MicroEmacs to give me some useful information from the opening of a block
when I'm at the closing brace. And I alternate between tabs and 4 spaces.
Normally I don't put braces around the case : statements, but it looks like a
good idea.
andy
I'm glad if you picked up something useful from my approach; Quite pleased,
actually. I'm very convinced about my bracing style, so I'll not say any more
than that about yours :*) hehehe But it looks a LOT better than _some_ I've
seen. Here. In the Dls. _Recently_. –Ben–
Always nice to pick up tricks; My C indenting style developed along the lines
of the tools I used… (never fight your tools if you can help it)
andy
Rick:
I like yours better also but for some reason the final closing brace
came out just after the semi-colon when I captured the message.
73, bill
<Sigh> That's what I get for relying on a computer to do what I know *I* should
do.
I'm using an alpha of a comm program that puts dots at the start of lines that
are supposed to be preserved; I *THOUGHT* it would handle source code;
obviously I was all wet. Let's try again.
short walk()
{
char broiled;
long time_coming;
do_something();
if(finished_doing_something)
{
do_something_else();
do_some_more_stuff();
}
grab_a_nap();
return(to_sender);
}
The point I'm trying (again 8) to illustrate is twofold: 1) the braces for a
given block are always at the same level of indention as the block itself, not
to the left (this goes against most standards I've seen, but it helps me), and
2) I also use vertical white space (blank lines) to seperate blocks as well.
Assuming that came through correctly… does that look any better, Steve et al?
Rick
Rick:
Of course the only thing that really counts is do you like it and can
others read it without too much trouble (the former counts for more than the
latter). Anyway, I like it. I think that it is easy to see where program
segments start and stop and how they are related.
73, bill
Rick,
Well the formatting came thru…and it's worse than I thought…for ME
that is. Obviously if you're happy with it, that's the part that matters. I'd
have written it like this:
cooking()
{
char broiled;
long time_cooking;
if (dinner_time) {
cook_meal();
serve_meal()
}
switch (meal_time) {
case BREAKFAST :
stack_dishes();
break;
case LUNCH :
rinse_dishes();
break;
case DINNER :
wash_dishes();
break;
default :
GoOut4Dinner();
break;
}
NapTime();
}
Again…to each his own.
Don
Now THAT'S readable!
Absolutely to each his own… you apparently "grew up" around people with a
Unix mentality. And nothing wrong with that, I might add.
I'm the first to admit that my style is non-standard (unless someone beats me
to it); I've seen no one else put the braces at the indention level of the
block, and a couple of other things I do are weird. Style, I suppose, is a
VERY personal thing.
Rick
Amen on K&R formatting. RJ and I go on and on about this one. I really upset
him once when I reformatted the Programmer's Suite to my indent style, during
the beta of it. He was pleased that my C code has picked up on longer,
Amiga-style identifiers, with mixed capitals and no underscores.