gaspar@almsa-1.arpa (Al Gaspar) (12/02/88)
I am looking for the latest public domain version of indent. I seem
to have a number of versions around. On our Vax running 4.3 mt. xinu
(binary only) we have a version without a -bg option which breaks an
'else if (test)' construct onto two separate lines. We have two public
domain versions running under System V and 4.3. Both of these have
the -bg option. One breaks up the 'else if (test)' construct, the
other does not. Neither have a number of options available under the
version from mt. xinu (including -ce, -nce, -ei, and -nei). And, both
claim that they have problems with #else preprocessor directives
following an if statement.
What I want is... everything :-). I would like the latest version
that will handle the -bg argument, which formats braces like this:
if (test)
{
whatever;
whatever;
}
(Of course, I don't want to give up the -bl and -br formats in the
process). I would prefer a version that had some kind of an option
on the 'else if (test)' construct, and I would like as many of the
options that are under the 4.3 version as possible. I don't want
any problems with the preprocessor. (Actually, a version identical
to our 4.3 version with the addition of -bg would do the trick). Is
there somewhere that I could pick up such an animal? An ftp site
would be great. Thanks.
Cheers--
Al
--
Al Gaspar <gaspar@almsa-1.arpa>
USAMC CSDA, ATTN: AMXAL-OW, Box 1578, St. Louis, MO 63188-1578
COMMERCIAL: (314) 263-5118 AUTOVON: 693-5118
uunet.uu.net!almsa-1.arpa!gasparmaart@cs.vu.nl (Maarten Litmaath) (12/03/88)
gaspar@almsa-1.arpa (Al Gaspar) writes:
\... which formats braces like this:
\ if (test)
\ {
\ whatever;
\ whatever;
\ }
What a DISGUSTING format!
I've included Henry Spencer's `Ten Commandments for C Programmers';
special attention to point 8, please.
----zip----zip----zip----zip----zip----zip----zip----zip----zip----zip----
The Ten Commandments for C Programmers
Henry Spencer
1 Thou shalt run _l_i_n_t frequently and study its pronounce-
ments with care, for verily its perception and judge-
ment oft exceed thine.
2 Thou shalt not follow the NULL pointer, for chaos and
madness await thee at its end.
3 Thou shalt cast all function arguments to the expected
type if they are not of that type already, even when
thou art convinced that this is unnecessary, lest they
take cruel vengeance upon thee when thou least expect
it.
4 If thy header files fail to declare the return types of
thy library functions, thou shalt declare them thyself
with the most meticulous care, lest grievous harm
befall thy program.
5 Thou shalt check the array bounds of all strings
(indeed, all arrays), for surely where thou typest
``foo'' someone someday shall type ``supercalifragilis-
ticexpialidocious''.
6 If a function be advertised to return an error code in
the event of difficulties, thou shalt check for that
code, yea, even though the checks triple the size of
thy code and produce aches in thy typing fingers, for
if thou thinkest ``it cannot happen to me'', the gods
shall surely punish thee for thy arrogance.
7 Thou shalt study thy libraries and strive not to re-
invent them without cause, that thy code may be short
and readable and thy days pleasant and productive.
8 Thou shalt make thy program's purpose and structure
clear to thy fellow man by using the One True Brace
Style, even if thou likest it not, for thy creativity
is better used in solving problems than in creating
beautiful new impediments to understanding.
9 Thy external identifiers shall be unique in the first
six characters, though this harsh discipline be irksome
and the years of its necessity stretch before thee
seemingly without end, lest thou tear thy hair out and
go mad on that fateful day when thou desirest to make
thy program run on an old system.
10 Thou shalt foreswear, renounce, and abjure the vile
heresy which claimeth that ``All the world's a VAX'',
and have no commerce with the benighted heathens who
cling to this barbarous belief, that the days of thy
program may be long even though the days of thy current
machine be short. ------------
--
fcntl(fd, F_SETFL, FNDELAY): |Maarten Litmaath @ VU Amsterdam:
let's go weepin' in the corner! |maart@cs.vu.nl, mcvax!botter!maartgwyn@smoke.BRL.MIL (Doug Gwyn ) (12/04/88)
In article <1748@solo3.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >gaspar@almsa-1.arpa (Al Gaspar) writes: >\ if (test) >\ { >\ whatever; >\ } >What a DISGUSTING format! Most programmers I know that have tried vertical alignment of braces for a while have come to prefer that to the style in K&R. With "sam" the K&R style becomes acceptable because it is easy to find the matching brace. In any case, when modifying existing code we use the same style as in the existing code, whatever it may be (unless the code is totally misformatted, in which case we beautify it first). >I've included Henry Spencer's `Ten Commandments for C Programmers'; >special attention to point 8, please. Henry is a nice enough guy, but he's not God (in fact the first attribute probably precules the second).
jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/05/88)
In article <9063@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1748@solo3.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >>gaspar@almsa-1.arpa (Al Gaspar) writes: >>\ if (test) >>\ { >>\ whatever; >>\ } >>What a DISGUSTING format! > >Most programmers I know that have tried vertical alignment of braces >for a while have come to prefer that to the style in K&R. With "sam" >the K&R style becomes acceptable because it is easy to find the >matching brace. I have one MAJOR gripe with the above { } scheme. Consider: main () { if (expr) { while (cond) { }; } /* possible missing } on this line??? */ } This is UGLY UGLY UGLY. It is also counter-intuitive. You go from one nesting level to TWO??? Which is why I generally include the following rule to my list of bracketing rules - ALWAYS use brackets on an outer level if they are used on an inner level. As it helps show the structure which may not be visible above the top of the screen. This particular formatting scheme lies about the structure. The alternative is to place all statements inside the function body starting in column 0. Which is, IMHO, totally gross. For example - if (test) while (cond) { state1; state2; } is worse than if (test) { while (cond) { state1; state2; } } >In any case, when modifying existing code we use the >same style as in the existing code, whatever it may be (unless the >code is totally misformatted, in which case we beautify it first). Here I agree 100%. One of our vendors uses the above mentioned horrible bracketing style and as little white space as possible. The first thing I do now is beautify the code. I don't even waste time deciding if it is ugly or not. >Henry is a nice enough guy, but he's not God (in fact the first >attribute probably precules the second). Henry is too god. You're just jealous ;-) -- John F. Haugh II +-Cat of the Week:--------------_ /|- VoiceNet: (214) 250-3311 Data: -6272 |Aren't you absolutely sick and \'o.O' InterNet: jfh@rpp386.Dallas.TX.US |tired of looking at these damn =(___)= UucpNet : <backbone>!killer!rpp386!jfh +things in everybody's .sig?-------U---
ok@quintus.uucp (Richard A. O'Keefe) (12/05/88)
In article <9063@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1748@solo3.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >>gaspar@almsa-1.arpa (Al Gaspar) writes: >>\ if (test) >>\ { >>\ whatever; >>\ } >>What a DISGUSTING format! > >Most programmers I know that have tried vertical alignment of braces >for a while have come to prefer that to the style in K&R. I have to agree with Maarten Litmaath. I suggest that people who care about layout in their programs should read Professional Software Volume II Programming Practice Henry Ledguard with John Tauer Addison-Wesley 1987 The use of braces in C is discussed on pages 111 and 117. I use the "comb" style of layout (Ledgard's preference) because it makes sense in all the languages I use. Ledgard is no more God than Henry Spencer, but I need a good reason to disagree with either of them.
pokey@well.UUCP (Jef Poskanzer) (12/05/88)
In the referenced message, jfh@rpp386.Dallas.TX.US (The Beach Bum) wrote: >I have one MAJOR gripe with the above { } scheme. Consider: > >main () >{ > if (expr) > { > while (cond) > { > }; > } >/* possible missing } on this line??? */ >} > >This is UGLY UGLY UGLY. It is also counter-intuitive. No, silly. Here's how you do it: main () { if (expr) { while (cond) { }; } } This style is common among ex Pascal programmers. --- Jef Jef Poskanzer jef@rtsg.ee.lbl.gov ...well!pokey "Wow! Ginger! The spice that makes rotten meat taste good!"
vfm6066@dsacg3.UUCP (John A. Ebersold) (12/05/88)
In article <7837@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes: >In the referenced message, jfh@rpp386.Dallas.TX.US (The Beach Bum) wrote: > >No, silly. Here's how you do it: NO, THIS IS HOW YOU DO IT. It's the only way :-) ! > main (argc, argv) int argc; char *argv[]; { int foo; char bar; if (expr) { while (cond) { } } } -- John A. Ebersold, Defense Logistics Agency, DSAC-FM Autovon 850-5923 of 3990 E Broad St Commercial 1-614-238-5923 Unify Corporation at Columbus, Ohio 43216-5002 osu-cis!dsacg1!dsacg3!vfm6066 lll-tis/
gpasq@picuxa.UUCP (Greg Pasquariello X1190) (12/06/88)
In article <1230@dsacg3.UUCP> vfm6066@dsacg3.UUCP (John A. Ebersold) writes: -In article <7837@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes: ->In the referenced message, jfh@rpp386.Dallas.TX.US (The Beach Bum) wrote: -> ->No, silly. Here's how you do it: -NO, THIS IS HOW YOU DO IT. It's the only way :-) ! -> ARGHHHH!!!! In reality, _THIS_ is the only way :-) :-) main(argc, argv) int argc; char **argv; { register int foo; register char bar; if (expr) { while (cond) ; } } -- ============================================================================= By the time they had diminished from Greg Pasquariello AT&T PMTC 50 to 8, the dwarves began to suspect Hungry. att!picuxa!gpasq =============================================================================
gregg@ihlpb.ATT.COM (Wonderly) (12/06/88)
From article <9125@rpp386.Dallas.TX.US>, by jfh@rpp386.Dallas.TX.US (The Beach Bum): > In article <9063@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In any case, when modifying existing code we use the >>same style as in the existing code, whatever it may be (unless the >>code is totally misformatted, in which case we beautify it first). > > Here I agree 100%. One of our vendors uses the above mentioned > horrible bracketing style and as little white space as possible. > The first thing I do now is beautify the code. I don't even waste > time deciding if it is ugly or not. One of the most frustrating things for me is that so many people insist on using a mixture of spaces and tabs for indentation. It seems obvious that editors like vi(1) have commands like ":set tabs=4 sw=4" for some reason! How many vi(1) users know that '[[' and ']]' can be used to get to the top of the previous/current or next C function providing you follow the standard coding scheme and place the opening '{' at the beginning of the line? This is very handy while writing a C function. You get down into the middle of the function, and need a new variable so you say, "oh, better go declare 'foo' now". Just type "[[" while in command mode and back you go. Do the declaration, and then type "''" and you are back on the line that you were on before. WoW!!! The other thing is the use of bracing. PLEASE always use braces around any block that contains more than two lines. Just because for (i=1; i < MAXVAL; ++i) switch (foobar (i)) { case 1: case 2: case 40 jillion: } is legal doesn't mean you have to exploit the language just to be clever or lazy. I religously use the '%' command in vi(1) to skip over blocks of code that are not of any interest, and it greatly improves my productivity to not have to scroll over 100 lines just to get to the part that interests me. Those braces also make it easy to use ">%" and "<%" to alter block indentation to add or remove a flow control statement. And, yes I do always avoid using braces as part of the program just so that I don't confuse vi(1) (i.e. #define LBRC '{', #define RBRC '}' ). Your editor will help you program if you will just let it... -- It isn't the DREAM that NASA's missing... DOMAIN: gregg@ihlpb.att.com It's a direction! UUCP: att!ihlpb!gregg
lm@snafu.Sun.COM (Larry McVoy) (12/07/88)
In article <9149@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes: >One of the most frustrating things for me is that so many people insist >on using a mixture of spaces and tabs for indentation. It seems obvious >that editors like vi(1) have commands like ":set tabs=4 sw=4" for some >reason! [unix-wizards in not approrpiate for this, followup to unix questions] sw=4 is cool. ts=4 is not. What happens when I do "lpr $.c" after some boy genius has missused the ts=4 feature? Yeah, I know about expand, but that is a hack and screws up other code. Larry McVoy (lm%snafu@sun.com)
jdchrist@watcgl.waterloo.edu (Dan Christensen) (12/08/88)
In article <9149@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes: >And, yes I >do always avoid using braces as part of the program just so that I don't >confuse vi(1) (i.e. #define LBRC '{', #define RBRC '}' ). > >Your editor will help you program if you will just let it... Why would using braces confuse vi? ---- Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu
dan@lclark.UUCP (Dan Revel) (12/10/88)
In article <1748@solo3.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >gaspar@almsa-1.arpa (Al Gaspar) writes: >What a DISGUSTING format! >I've included Henry Spencer's `Ten Commandments for C Programmers'; >special attention to point 8, please. :8 Thou shalt make thy program's purpose and structure : clear to thy fellow man by using the One True Brace : Style, even if thou likest it not, for thy creativity : is better used in solving problems than in creating : beautiful new impediments to understanding. OK, just what does the 'One True Brace Style' look like? Is there a formal specification for OTBS? And was it included in ANSI C? (No really, I'm serious, inquiring minds want to know!) -- dan@lclark tektronix!reed!lclark!dan Dylsexics untie! (-|
Dave Lawrence (12/10/88)
peter@ficc.uu.net (Peter da Silva) wrote: >If I find a program that's got indentations less than a tabstop, it goes >through 'cb' first thing... and to hell with the pretty comments. I prefer the GNU Emacs way of doing things. o If I forgot a semicolon, I know immediately. o Closing braces, brackets or parentheses finds the matching pair. o TAB indents two spaces for each new level. This means: - At my fifth level of indentation, I've only lost ten characters. - At _c_b(1)'s fifth level, it's lost half of a line. fprintf's, long conditionals and other lengthy statements get split across lines that might not normally be that way. (Normally to me, at any rate.) I've run my code through _c_b(1) and all it does is indent things a huge amount. Maybe that's because that is all it supposed to do. Two spaces is enough for me to see the offset of a level. Additionally, _e_x_p_a_n_d(1) is pretty useless against C code from GNU Emacs as it contains precious few tabs. I'm a little confused as to what Peter means about "the pretty comments." Is that the programmer's comments or comments from the net? Programmer's commments (and those from the net) can be very helpful. Finally, as long as I'm at it, I'd like to register my preference for the following indentation form: main() { do { expr; expr; } while (); } Dave -- tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <366@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes: >OK, just what does the 'One True Brace Style' look like? Is there >a formal specification for OTBS? And was it included in ANSI C? >(No really, I'm serious, inquiring minds want to know!) Presumably the One True Brace Style refers to that used by K&R 1st Ed. But note that K&R are not dogmatic about it.. ANSI C does not dictate style.
allbery@ncoast.UUCP (Brandon S. Allbery) (12/12/88)
As quoted from <810@quintus.UUCP> by ok@quintus.uucp (Richard A. O'Keefe): +--------------- | In article <9063@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | >In article <1748@solo3.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: | >>gaspar@almsa-1.arpa (Al Gaspar) writes: | >>\ if (test) | >>\ { | >>\ whatever; | >>\ } | >>What a DISGUSTING format! | > | >Most programmers I know that have tried vertical alignment of braces | >for a while have come to prefer that to the style in K&R. +--------------- A small comment here: "vertical alignment" can also mean: if (test) { whatever; } Which might be preferable to some people. +--------------- | (book reference deleted) | The use of braces in C is discussed on pages 111 and 117. I use the "comb" | style of layout (Ledgard's preference) because it makes sense in all the | languages I use. | | Ledgard is no more God than Henry Spencer, but I need a good reason to | disagree with either of them. +--------------- Actually, the indent format I find clearest is: if (test) { whatever; } It works in most languages I've used (including Lisp, in many cases), and shows by indent level exactly what's going on. The main problems I have with it are (1) unless you use a very short indent (like 2 spaces above), lines start wrapping or disappearing off the end of the screen rather quickly; and (2) Jove isn't quite smart enough to handle it. (On the other hand, I have a patch to enable the C-indent hook in Jove; maybe I'll find the time to get the Jove sources back onto ncoast and patch them.) If this is what the above poster was referring to, my apologies; I don't have much access to technical books, alas. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
beres@cadnetix.COM (Tim Beres) (12/15/88)
In article <9135@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Presumably the One True Brace Style refers to that used by K&R 1st Ed. >But note that K&R are not dogmatic about it.. > >ANSI C does not dictate style. Neither are we dogmatic (Cadnetix). We have coding guidelines, but these do not attempt to dictact the OTBS. When I first joined the graphics group, I noticed that everyone was using the OTWBS (one true WRONG brace style); it seems that it had carried over from the dawn of graphics code (about 4 years ago, for C). Well, being the do-gooder that I am, I went and indented (1) a couple of modules. Upon discovery of this good deed, I was asked to show what changes I had made to the modules, via RCS diff. Uh-oh. I now use existing style wherever appropriate. Naturally, I use my vastly superior (-: style when writing new code. BTW, I use: if (detroit_lions_ever_win){ /* * This path almost never exercised, but it did happen in 1957. */ joyous_celebration = 1; } Tim ------>MY SOAPBOX (I speak not for Cadnetix nor any enjoined entity) OK, one more time: This is a frying pan.....this is an egg.... this is an egg in a frying pan....JUST SAY OVER EASY Tim Beres beres@cadnetix.com {uunet,boulder,nbires}!cadnetix!beres
gordon@sneaky.TANDY.COM (Gordon Burditt) (12/16/88)
Before anyone gets too enthusiastic about running all code in sight
through indenter/beautifier programs so they conform to THE correct
brace style, be very sure you aren't destroying code in the process.
If you are using a source code control system, and you must run code
through an indenter, it would be an excellent idea to check in all the
code, compile it, save the result, check out the code, beautify it,
compile it, and compare the object files and/or executables. When you
finally manage to get a match, check in the beautified source (and the
source to the beautifier!) without further changes. Then check it
out and continue development. (Some System V compilers put time-stamps or
other variable information in object headers that won't be the same each
time you compile. These differences don't count.)
Beautifiers can destroy code. I'm not entirely convinced that it is
possible to write a beautifier that properly handles sufficiently
obscure code. For example:
char *rcfile = "/usr/foobar/RCFILE; { char *basedir = LIBDIR/rn";
where, unknown to the beautifier, this code is normally compiled with
cc '-DRCFILE=.foorc"' '-DLIBDIR="/usr/spool/news' ...
so that's TWO declarations, not one, and that brace in the middle
is not inside the string. Yes, this depends on Reiser CPP operation that
is not standard. If you want to beautify this code, fix stuff like this
and forget about brace styles.
Few indenters will tolerate code written in this obnoxious outdented style,
especially since it only sees one close brace in the whole program, and
that one is first:
# define END \
\
} \
\
void doit(foo, bar) {
if (foo == bar) {
bark();
if(2 + 2 != 4) {
printf("assert error!");
END
printf("this code is ugly");
END
END
For a less extreme example, how about:
# ifdef BSD
if (write(socketfd, buffer, length) != length) {
# else
if (sndmsg(msgid, buffer, length, NO_WAIT) == NULL) {
# endif
...
}
I tried using a beautifier called "indent" a few years ago. This may or
may not have anything to do with any program you know of by the same
name. It broke things. The first thing that got mangled was multi-line
# defines, because it didn't know it had to use backslashes on the
continuation lines. Someone fixed it. Then it decided to turn
"x= -y;" into "x-=y;" because it thought it was cleaning up old-style
assignment operators. That took several hours to find. Someone fixed it.
Then it decided that *a/*b was the beginning of a comment, and it was free
to insert line breaks at white space inside that quoted string inside the
so-called comment. Someone fixed it. Then the program acted strange.
Well, this time it was a bug in the program, but how could I have any
confidence it wasn't the indenter?
Now, what does that pre-ANSI indenter do to programs written for your
new ANSI compiler?
Gordon L. Burditt
...!texbell!sneaky!gordonconsult@osiris.UUCP (Unix Consultation Mailbox ) (12/20/88)
In article <5428@sneaky.TANDY.COM> gordon@sneaky.UUCP (Gordon Burditt) writes: >Before anyone gets too enthusiastic about running all code in sight >through indenter/beautifier programs so they conform to THE correct >brace style, be very sure you aren't destroying code in the process. Yup. The last time I tried running an example file through one of our vailable versions of cb (under the SysV side of Pyramid OSx), using a certain option (-j, I think), it decided that my "->"s were all two consecutive tokens and split some of them across newlines. My compilers were NOT amused, making the problem easier to find than Gordon's suggestions indicated, but any programmer who thinks that just because a file passes cc means it's correct should be [insert favorite method of painful public execution here]... Phil Kos uunet!pyrdc!osiris!phil The Johns Hopkins Hospital