dal@midgard.Midgard.MN.ORG (Dale Schumacher) (12/20/88)
In article <17082@dhw68k.cts.com> allan@dhw68k.cts.com (Alan Perry) writes: [talking about indentation depth...] |I always thought 4 with the correct answer. Ever since I first starting |writing in C I have used 4-space indentation. I started doing it this |way because all of the C code written by others where I went to school |was indented by 4. | |I don't know where this indent by a full tab came from, but I have a |problem controlling my gag reflex whenever I see it. Gack! There are many other things in reading other people's C code that should bother you more the differences in tab size. I have ported code from all sorts of sources, and it's rarely the coding style that gets in the way (a former employer wrote C with NO indentation). Now a proposal... one that I'm sure many of you have thought about in the past. Given, each of us has a coding style that we prefer to use, be it adaptation to local coding standard, "baby-duck" syndrome (see above) or personal rationalization. Given, this style is rarely the same (sometimes not even similar) to the style used by a reader of your code. Given, a huge amount of time is "wasted" reformatting code that you didn't write just so you can understand it. Proposed, what is needed is a program which understands C syntax and can use a template to reformat C source into a form described by that template. I know, this is DEFINATELY a non-trivial task. Comments are one of the biggest problems, for example. However, with all of the resources touched by this newsgroup, it would seem that this could be accomplished. It's value is, at least to me, obvious. I would suggest looking into things like the processing that 'tbl' or 'eqn' use to treat this as a page formatting problem with the comments (hanging comments, that is) being column align text. Even if the comments AREN'T handled nicely, just getting the format of the code itself into reasonable shape is a big head start. So far, the 'cb' type programs I've seen have the major disadvantage that the formatting rules are hard coded and even at that, don't seem to do a very good job of fully converting to a consistent style. I'd be glad to work on something like this, but I don't think I want to do it alone.
eric@snark.UUCP (Eric S. Raymond) (12/21/88)
In <519@midgard.midgard.mn.org>, dal@midgard.Midgard.MN.ORG (Dale Schumacher) writes: >[Let's build a powerful C beautifier to solve the multiple-formats problem] Such tools already exist. Try ESC-C-q in gnumacs C-mode; or get your hands on the PD indent(1) that was on the 4.2BSD user-supported software tape. If you know what you're doing with either of these you can make the output come out in almost any reasonable variation of the major coding styles. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
bradb@ai.toronto.edu (Brad Brown) (12/22/88)
In article <519@midgard.Midgard.MN.ORG> dal@midgard.Midgard.MN.ORG (Dale Schumacher) writes: ... >Proposed, what is needed is a program >which understands C syntax and can use a template to reformat C source >into a form described by that template. I know, this is DEFINATELY a >non-trivial task. Comments are one of the biggest problems, for example. >However, with all of the resources touched by this newsgroup, it would >seem that this could be accomplished. It's value is, at least to me, >obvious. I would suggest looking into things like the processing that >'tbl' or 'eqn' use to treat this as a page formatting problem with the >comments (hanging comments, that is) being column align text. Even if >the comments AREN'T handled nicely, just getting the format of the code >itself into reasonable shape is a big head start. So far, the 'cb' type >programs I've seen have the major disadvantage that the formatting rules >are hard coded and even at that, don't seem to do a very good job of >fully converting to a consistent style. I'd be glad to work on something >like this, but I don't think I want to do it alone. I've seen two commercial programs that go part of the way toward what you are looking for. Both run on PCs but the vendors may have Unix implementations as well. cb from Polytron can be given flags that tell it when to break lines. This handles many (though not all) of the stylistic differences that pertain to placement of braces and when a newline is inserted during a function declaration. The C-DOC package from Software Blacksmith's Inc. is a complete documentation package that handles reformatting and cross references and a whole bunch of things. They have flexible control over what reformatted programs look like, and they have options for handling reformatting of comments. I don't have much experience with comment reformatting because I do it in my editor and the C-DOC package doesn't do *everything* right, but it is nice. If you'd like addresses for Polytron or C-DOC, send me mail and I'll look them up. However, I think more work needs to be done in this area... (-: Brad Brown :-) bradb@ai.toronto.edu bradb@ai.utoronto.ca
chris@mimsy.UUCP (Chris Torek) (12/23/88)
>In article <519@midgard.Midgard.MN.ORG> dal@midgard.Midgard.MN.ORG >(Dale Schumacher) writes: >>... the 'cb' type programs I've seen have the major disadvantage that >>the formatting rules are hard coded and even at that, don't seem to do >>a very good job of fully converting to a consistent style. In article <88Dec21.213900est.10762@ephemeral.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes: >cb from Polytron can be given flags that tell it when to break lines. ... > >The C-DOC package from Software Blacksmith's Inc. is a complete documentation >package that handles reformatting and cross references and a whole bunch of >things. ... C-DOC may do more; but there is a program supplied with 4.3BSD called `indent' that (while it has some nontrivial bugs) does a fairly good job. It has over 15 boolean options alone: Boolean: ( on | off ) (if on) -bad | -nbad force blank line after block of declarations -bap | -nbap force blank line after procedure body -bbb | -nbbb force blank line before block comment -bc | -nbc force newline after each comma in declarations -ce | -nce force `} else {' format (vs }\nelse) -dj | -ndj left-justify declarations -ei | -nei handle `else if' as a unit (vs else\n\tif) -fc1 | -nfc1 enable formatting comments starting in col 1 -ip | -nip do indent parameter declarations -lp | -nlp line up continuations under unclosed parentheses -pcs | -npcs put space after procedure call: `fn (arg1, arg2)' -ps | -nps put spaces around `->': `p -> field' -psl | -npsl put procedure names on col 1 (int\nfoo()) -sc | -nsc put stars `*' at left edge of multi-line comments -sob | -nsob swallow (eat) certain optional blank lines (this is basically to undo -bad above) -v | -nv be verbose (to stderr) Numeric: (name) (function) -c column for comments on code lines -cd column for comments on declaration lines -ci continuation line (extra) indentation -cli case label indent (in `tab stops'; can be 0.0<n<1.0) -d comment dedentation (in tab stops) -di identifier (extra) indent after decl keyword (in chars) -i width of a tab (also affects, e.g., -cli) -l max output line length (soft; may sometimes exceed it) Other: -br | -bl brace style (needs more options) -cdb | -ncdb block comment style (`delimited' or not) -npro ignore ./.indent.pro and ~/.indent.pro -st read stdin, write stdout -T typename make `typename' a type keyword a la int, long, etc -troff generate troff commands to pretty-print a la vgrind And, from the `bugs' section of the manual: Indent has even more switches than \fIls\fR. (Indent is *not* public domain: it carries a copyright notice from the University of Illinois Board of Trustees. I imagine it is redistributable, but it would be wise to ask UI first.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris