bukys (10/24/82)
Sigh. Another one of those never-ending battles. I would have kept
my opinion to myself, except that there appears to be only one other
defender of the one true indentation style out there.
if (condition)
{
statements...
}
My reasons, in brief:
- symmetry
- syntactically intuitive
- incorrect usage easy to spot
- correct usage easy to ignore
- minimum of clutter
What I mean by the last point is this: it is easier to read
if ...
{
subordinates
}
while ...
etc.
than
if ... {
subordinates
}
while ...
etc.
because these low-content '}' lexemes are hogging the visual space,
distracting me from those high-content 'if' and 'while' lexemes.
I believe Whitesmith's, Inc. uses this as part of its corporate standard.
Liudvikas Bukys
rochester!bukysswatt (10/25/82)
The current discussion is a perennial one, and I thought the following
might be of interest. Please note the disclaimer.
- Alan S. Watt
>From swatt Sun Jun 7 13:29:28 1981
To: decvax!chico!teklabs!tekmdp!stevenm
Subject: C Beautification
Cc: swatt
From decvax!duke!chico!teklabs!tekmdp!stevenm Sat Jun 6 23:05:10 1981
C Beautification : NET.general,net.general
Does anyone out there have a C indenter/paragrapher/beautifier
which is smarter than 'cb'? I have resurrected an old one
from U. Illinois at Urbana which accepts V6 C, and I don't feel
like trying to upgrade it. I need something that will move
comments around, deal intelligently with definitions, etc.
respond to 'duke!chico!teklabs!tekmdp!stevem'
Steve:
Long time no see. How is dear old TEK anyway? I really don't
have any information on C beautifiers for you, but TTI* has a management
philosophy that might be applicable to the problem. Or you can simply
tell people who write C code what indenting practices to use and cut
off the hands of the ones who don't listen.
- Alan
-------------
* TTI is a ficticious company. It stands for "Transcendental
Telecommunications Industries" and is a multi-national conglomorate.
Any resemblance between TTI and any real company is purely coincidental.
-------------
1) Convene a committee to determine the standards. It is not
required that any members of the committee have any C
programming experience. In fact, members are chosen by the
political considerations of which groups, companies, countries,
etc. might be offended if they were left out of the decision
process.
2) Just because you have a committee doesn't mean you can actually
meet. Next get funding. This process involves filing a "PAR",
which has to list all the expected costs, all the expected
benefits, and must show how TTI will profit from this
endeavor. This has to go to World Headquarters in NY for
discussion. Now the composition of the committee really proves
its worth because if you had left anyone out who had any means
of retaliation, the PAR would either get sent back on some
technicality or die quietly in someone's office.
2) The above composition of the committee will help insure that any
standard that is produced will be late, imprecise, and quite
probably incomprehensible as well. It is expected that during
the definition of the C formatting standard many members of the
committee will raise the point "But all these problems would
just go away if we used {PASCAL|ADA|CHLL|PL/1...}". This is
all to the good as it practically guarantees there will be
sections in the final document like:
"Indentation Standards for 'COMMON' Statements"
which will help in the review process (more on that later).
3) Regardless of how long the definition of the standard takes, it
is imperative that every month the manager in charge of the project
produce a monthly report showing the projected milestone dates and
the actual milestone dates. This report is incorporated in turn
into the monthly report of the managers in charge of projects
actually using C, to show how their project delivery schedule will
slip if the formatting standard isn't delivered when promised.
4) Another important activity is the preparation of slides, foils,
charts, etc., for use at various TTI management meetings. This
activity will probably account for most of the actual
expenditures. After all, anyone can scribble some words on
paper but color artwork is EXPENSIVE. The purpose of these
various talks and presentations is to show how "the
industry-wide trend is towards common definition of programming
language source code bulk entry standards." This is also an
excellent opportunity to discuss possible uses of
state-of-the-art graphic input technology. Above all, leave
everyone with the impression that TTI is at least even with
the Bell System in this area.
5) By this time, the original committee will have hired additional
personnel, mostly secretarial. Somewhere between 8 months and
a year will have passed. The volume of work in preparing foils
for presentations will have almost certainly have outgrown
whatever computer system you started working on. Now is the
time to start pushing for your own system. The choice will
probably come down to VAX or IBM. The process of making this
decision will take another 4 months.
6) After sufficient secretarial personnel have been hired, the idea
will occur to someone to hire some programmers. By this time a
hiring freeze will be in effect, so the monthly reports will all
cite the hiring freeze as the reason publication of the standard
will be delayed. Similarly, the units awaiting the standard to
write C code will be delayed. There will be talk about abandoning
the use of C and switching to PASCAL.
7) By this time, the original request for a VAX-11/780 will have
been denied because of a budget crunch related to the hiring
freeze. There is also some suspicion that supporters of IBM
worked behind the scenes to get it killed. Productivity is
really suffering now; the production rate of foils and slides
is way down and the travel budget to go to the meetings and
present them has also been cut. Some of the members of the
committee will have declared the impossibility of getting any
work done with totally inadequate resources and have stopped
attending meetings. The production of memos should continue at
the normal rate however.
8) The hiring freeze is still in effect but it is now summer and
you can manage to hire a couple of students as summer interns.
They will probably have no experience with C, but have used
some PASCAL, and besides they'll do anything for the money.
9) The idea will certainly occur to someone that a program to format
C programs would be a nifty idea, as well as "sellable".
Debate immediately insues as to what language to write it in.
Here is where the IBM stalwarts get even for the DEC supporters
having slipped the recommendation for a VAX past them. It is
decreed that the C beautifier program will run on an IBM 4341
under VM/CMS/SPF and will be written in PL1.
10) The original project using C, a microprocessor-based field
communications system for the military, is now late and the
contractor responsible decides to give up on C and code in
assembly. This decision is quick to implement because the
military agency reponsible for overseeing the contract approved
this particular assembler for use by this particular company
for the last project. As stipulated in the contract, all
development is done on a machine donated to the company for
that purpose from military surplus stores. It is a ruggedized
NOVA and doesn't run VM/CMS/SPF or support PL1.
11) The summer student interns, after reading some C manuals
will have written the bulk of the formatting standard and a
prototype of the formatting program in about a week of
all-nighters.
12) Now some additional budget resources have become available and
production of high-quality presentation materials resumes its
former level. The standard is carefully edited to remove any
references or phrases that might offend somebody. For example,
the description of C as a "Structured Programming Language" will
have been stricken from the report because of objections of
PASCAL and ALGOL adherents who are real sticklers for the use
of the term "structured".
13) The proposed standard is now submitted for review. Now the
wisdom of including sections on the proper indenting of
COMMON statements is manifested. The reviewers will have no
more knowledge of C than did most of the committee members
at the outset of the whole affair. Giving them something to
which they can relate greatly eases the review process. You
must have been very careful, however, to cite references to
publications that have discussed this issue.
14) During the review process, someone who really does know C will
have gotten ahold of a copy of the standard and will produce
a memo showing that the standard is largely inapplicable to
the C language in its current definition (the committee used
documents for a version of the language several versions old),
and the C doesn't now have and never has had a COMMON statement,
and that the proposed standard is at variance with just about
all the C code produced by long-time C users. He will be told
that:
a) the version skew isn't important because it
describes the version of C that TTI is currently not
using anyway. This is also the reason TTI cannot start
not using a newer version because it would conflict
with the proposed formatting standard.
b) the lack of a COMMON statement cannot be mentioned
because one of the most important reviewers only
approved the standard because it adopted his view of
the proper indentation of COMMON statements. If he
finds out there isn't one he will insist that the
language be modified to include it.
c) the formatting practices of long-time C users have
been found by the committee to be "poor practice". And
besides, they couldn't be produced by the formatting
program.
15) In due course the proposed standard will be approved, with some
modifications and incorporated into the "TTI Programming
Procedures Manual". All programmers hired by TTI will be told
they must conform to the standards defined here. The manual
itself, made up of 8 volumes and totalling 3478 pages collected
over a period of 18 years, is so expensive to print that the
only copies of it are kept in designated TTI reference
libraries. It is therefore very difficult for TTI programmers
to get a copy. This is just as well because TTI in general
underpays programmers and the tenure of a programmer at TTI is
well below the industry average, so reading the entire procedures
manual would take up most of his employment span with the company.
16) The fact that no possible use of the standard will expose its
flaws has made the whole project a huge success. Everyone is
working overtime to take as much credit as possible (except the
summer interns; they are back in school trying to take as few
credits as possible). Even the ones who stopped attending the
committee meetings will be producing memos and foils showing
how their single-minded dedication to the task was what really
got it done. There will probably be promotions for everyone.
At least one more round of presentations will take place to show
what kind of disaster would have occurred if TTI hadn't moved
"significantly ahead of the rest of the industry" to define this
standard.stevenm@sri-unix (10/26/82)
Alan's humor certainly puts the argument in perspective. On a more serious
tone, however, I should note to the net that my query of a year or more ago
was answered. The University of Illinois 'indent' program (this is the
same program that is distributed with EMACS, by the way) - has been
updated for V7 C. The program is not perfect - it stills barfs if you put
spaces after your preprocessor '#' signs, and it has a few other problems
which escape my mempory currently. All things considered, however, it is
an extremely useful tool. Coupled with:
1) a locally written program which moves comments around;
2) a tool which someone wrote which fixes Bourne-style ALGOL-isms; and
3) a simple tool which I wrote which expands and contracts tabstops
These tools allow me to take an arbitrarily formatted C program and format
it the way that I want it. 'Indent' has options for both of the prevelent
styles of C brace placement, and a slew of other options. I am including
the manual page at the bottom of this note.
Now the sticker. I got this program from someone at the University of
Illinois. All you net news readers out there can do one of two things:
1) Wait until I ask the person that I got it from whether it
is OK to redistribute it; or
2) Sit on your thumb.
PLEASE! Do not send me mail asking me for a copy. Simply 'watch this space'.
At some point in the future I either will or will not post the sources
to 'net.sources'.
S. McGeady
Tektronix, Inc.
----------------------------------------------------------------------------
INDENT(1T) UNIX Programmer's Manual INDENT(1T)
NAME
indent - indent and format a C program source
SYNOPSIS
indent ifile [ ofile ] [ args ]
DESCRIPTION
The arguments that can be specified follows. They may appear
before or after the file names.
ifile Input file specification.
ofile Output file specification.
If omitted, then the indented formatted file will
be written back into the input file, and there
will be a "back-up" copy of ifile written in the
current directory. For an ifile named
"/blah/blah/file", the backup file will be named
".Bfile". (It will only be listed when the `-a'
argument is specified in ls.) If ofile is speci-
fied, indent checks to make sure it is different
from ifile.
-lnnn Maximum length of an output line. The default is
75.
-cnnn The column in which comments will start. The
default is 33.
-cdnnn The column in which comments on declarations will
start. The default is for these comments to start
in the same column as other comments.
-innn The number of spaces for one indentation level.
The default is 4.
-dj,-ndj -dj will cause declarations to be left justified.
-ndj will cause them to be indented the same as
code. The default is -ndj.
-v,-nv -v turns on "verbose" mode, -nv turns it off.
When in verbose mode, indent will report when it
splits one line of input into two or more lines of
output, and it will give some size statistics at
completion. The default is -nv.
-bc,-nbc If -bc is specified, then a newline will be forced
after each comma in a declaration. -nbc will turn
off this option. The default is -bc.
-dnnn This option controls the placement of comments
Printed 5/1/82 5/1/82 Local 1
INDENT(1T) UNIX Programmer's Manual INDENT(1T)
which are not to the right of code. Specifying
-d2 means that such comments will be placed two
indentation levels to the left of code. The
default -d0 lines up these comments with the code.
See the section on comment indentation below.
-br,-bl Specifying -bl will cause complex statements to be
lined up like this:
if (...)
{
code
}
Specifying -br (the default) will make them look
like this:
if (...) {
code
}
You may set up your own `profile' of defaults to indent by
creating the file `$HOME/.indent.pro' (where $HOME is your
home directory) and including whatever switches you like.
If indent is run and a profile file exists, then it is read
to set up the program's defaults. Switches on the command
line will always over-ride profile switches. The profile
file must be a single line of not more than 127 characters.
The switches should be seperated on the line by spaces or
tabs.
Indent is intended primarily as a C program indenter.
Specifically, indent will:
> indent code lines
> align comments
> insert spaces around operators where necessary
> break up declaration lists as in "int a,b,c;".
It will not break up long statements to make them fit within
the maximum line length, but it will flag lines that are too
long. Lines will be broken so that each statement starts a
new line, and braces will appear alone on a line. (See the
-br option to inhibit this.) Also, an attempt is made to
line up identifiers in declarations.
Multi-line expressions
Indent will not break up complicated expressions that extend
over multiple lines, but it will usually correctly indent
such expressions which have already been broken up. Such an
Printed 5/1/82 5/1/82 Local 2
INDENT(1T) UNIX Programmer's Manual INDENT(1T)
expression might end up looking like this:
x =
(
(Arbitrary parenthesized expression)
+
(
(Parenthesized expression)
*
(Parenthesized expression)
)
);
Comments
Indent recognizes four kinds of comments. They are straight
text, "box" comments, UNIX-style comments, and comments that
should be passed thru unchanged. The action taken with
these various types is as follows:
"Box" comments: The DSG documentation standards specify
that boxes will be placed around section headers. Indent
assumes that any comment with a dash immediately after the
start of comment (i.e. "/*-") is such a box. Each line of
such a comment will be left unchanged, except that the first
non-blank character of each successive line will be lined up
with the beginning slash of the first line. Box comments
will be indented (see below).
Unix-style comments: This is the type of section header
which is used extensively in the UNIX system source. If the
start of comment ('/*') appears on a line by itself, indent
assumes that it is a UNIX-style comment. These will be
treated similarly to box comments, except the first non-
blank character on each line will be lined up with the '*'
of the '/*'.
Unchanged comments: Any comment which starts in column 1
will be left completely unchanged. This is intended pri-
marily for documentation header pages. The check for
unchanged comments is made before the check for UNIX-style
comments.
Straight text: All other comments are treated as straight
text. Indent will fit as many words (separated by blanks,
tabs, or newlines) on a line as possible. Straight text
comments will be indented.
Comment indentation Box, UNIX-style, and straight text com-
ments may be indented. If a comment is on a line with code
it will be started in the "comment column", which is set by
the -cnnn command line parameter. Otherwise, the comment
will be started at nnn indentation levels less than where
Printed 5/1/82 5/1/82 Local 3
INDENT(1T) UNIX Programmer's Manual INDENT(1T)
code is currently being placed, where nnn is specified by
the -dnnn command line parameter. (Indented comments will
never be placed in column 1.) If the code on a line extends
past the comment column, the comment will be moved to the
next line.
DIAGNOSTICS
Diagnostic error messsages, mostly to tell that a text line
has been broken or is too long for the output line, will be
printed on the controlling tty.
FILES
$HOME/.indent.pro - profile filervpalliende (11/05/82)
Is absolutely everybody happy indenting with one tab equivalent to eight blanks? I think that then my lines get too short too fast. I would prefer indenting four blanks, and using a tab for two indents. A related question: How do people feel about lines longer than 80 chars? I don't like them, but in net.sources you can often see very long lines. Not afraid not to indent my name: Pablo Alliende.
john (11/08/82)
I always use both tabstops of 4 and indent of 4 with my original C creations,
via the vi configuration commands in .exrc:
.se ts=4 (set tab stops to 4)
.se sw=4 (set shift width to 4)
Although I am not compatible with the rest of the world, I find it to
be much easier to read lines that do not wrap around on the terminal when
the nesting depth exceeds four. Actually, I prefer tabs of four for text
processing also. Of course this means I need to alias all my commands to
conform to this, for example:
alias lpr expand -4 !* | lpr
John P. Nelson (decvax!genradbolton!john)jwp (11/09/82)
I also would much prefer tabstops set at intervals of four rather than eight. Does anyone know why in the dim dark past eight was decided on as the standard? John Pierce, Chemistry, UC San Diego ucbvax!sdcsvax!sdchema!jwp
mem (11/10/82)
c
8 characters per stab top was used, presumably, because it is the closest
binary power to a useful separation between assembler fields. Binary
powers, natch, because tab stop computation is simpled by add/shift/or.
I like 3 chars per c-stob myself. It's nice to befuddle binary
machines with ternary usage, if nothing else.
And speaking of ternary logic-- wouldn't it be really nice to have
such an animal in a compiler. There is often a necessity for
three-state logic, each state being:
- Not applicable
- False
- True
The 3-state nature of flags is ALREADY built into all hardware designs
(combinations of Z and M). A typical situation? A temporary flag
used to override a global flag, where normal interpretation requires:
if (temporary-flag-is-significant)
if (temporary-flag-value) then action;
else alternate-action;
else /* temporary-flag is not-significant */
if (global-flag-value) then action;
else alternate-action;
where ternary logic simply would combine the product of the temporary
(three-state) flag with the global (two-state) flag.
Yours in generality,
Mark Mallettmcewan (11/11/82)
#R:ittvax:-46900:uiucdcs:27600003:000:141 uiucdcs!mcewan Nov 10 22:31:00 1982 As this would appear to be my version-7 version of Wilcox' indenter, I give my blessing to the suggestion to distribute it. Scott McEwan
mikeb@inset.UUCP (Mike Banahan) (05/13/86)
In article <797@bentley.UUCP> kwh@bentley.UUCP writes: (I just pull out the bit that interests me) >In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>I have ranted about C using a one statement model for its control >>statements instead of an explicit end statement. Compound statements are >>bounded by braces instead. Yuk! > >Ah yes, there are two major types of language in the structured family; >f77 with "endif" (some members use "end" for all of "endif", "endwhile", >etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I >presume this is what you dislike. (If it's the spelling that bothers you, >I'm sure you're aware that you can define "begin" and "end" as macros.) > >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) Sorry, you're wrong. Occam uses indentation to show nesting. You *can't* write an incorrectly indented program, because different indent is a different program! (Occam is the parallel language for the Inmos Transputer; it's good fun but boy do you have to re-think those old ideas about sequential execution.) -- Mike Banahan, Technical Director, The Instruction Set Ltd. mcvax!ukc!inset!mikeb
kwh@bentley.UUCP (KW Heuer) (05/16/86)
In article <995@inset.UUCP> inset!mikeb (Mike Banahan) writes: >In article <797@bentley.UUCP> kwh@bentley.UUCP writes: >>Yet another convention, not endorsed by any language I know, is to dispense >>with the braces... > >Sorry, you're wrong. Occam uses indentation to show nesting. ... No, I was right. Occam is not "a language I know". Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Okay, maybe I should've added a "that".)