edski@phx.mcd.mot.com (Ed Skinner) (10/11/90)
Do you have a trick or two for polishing and/or debugging "C"
code using typical Unix(tm) tools? I am interested in anything that
helps locate coding errors, particularly those techniques that use
programs available on run-of-the-mill Unix-based systems.
I am making a collection and will post it to the net. Please mail
your submissions instead of posting them to this group.
Here is an example of what I'm looking for;
I use cb(1) and diff(1) to catch what I'll call grouping or indentation
problems. I fall into this trap when my first version of code has a single
statement inside an if-statement's true clause and then I later go back and
add another line or two of code.
fragment()
{
if (moveit(datap, dev) == 0)
assert(dvcp->c_res == 0); <----- ADDED LINE
if (dvcp->c_flags & ASYNC) {
status = q_send(dvcp->c_id, &end);
assert((status == E_NOERR) || (status == E_OBJDEL));
}
}
Both versions will compile and lint(1) (in the full version, not the
fragment I've shown above) without detecting the error. Visually, the
second if-statement version is within the first if-statement's true clause.
However, the compiler ignores indentation and generates the second
if-statement code completely outside of the first.
I recently spent two days tracking down one of these errors!
"Fool me once, shame on you [the compiler]. Fool me twice, shame on me!"
Using cb(1) and diff(1), I developed a quick check that will find
this type of error.
Briefly, the source file is "beautified" and compared to the original.
Any differences, such as in the amount of indentation I think is necessary
versus what cb(1) thinks is needed are pointed out by diff(1).
cb $f | diff - $f
One drawback, of course, is that the source file must be coded in
a cb(1) format in order to use cb(1) to "find" differences between what
I mean and what the compiler will understand. This format may not conform
with your favorite style, nor that of your employer. However, I am willing
to change my habits (and style) when I find something that will help me
generate better code in less time.
--
"Wisdom is the absence of ideals." Chinese proverb
#include <disclaimer.h>
Ed Skinner, Technical Training, Motorola Inc., MicroComputer Division
2900 S Diablo Way, Tempe Az 85282, USA (602)438-3956
Internet: edski@phx.mcd.mot.com, UUCPnet: noao!asuvax!mcdphx!edskijad@hpcndnm.cnd.hp.com (John Dilley) (10/12/90)
In article <13785@mcdphx.phx.mcd.mot.com> edski@phx.mcd.mot.com (Ed Skinner) writes: > One drawback, of course, is that the source file must be coded in >a cb(1) format in order to use cb(1) to "find" differences between what >I mean and what the compiler will understand. This format may not conform >with your favorite style, nor that of your employer. However, I am willing >to change my habits (and style) when I find something that will help me >generate better code in less time. I find that GNU emacs allows me to generate better code in much less time than I was able to generate before. In general, GNU emacs lets me be more effective overall (generating code is maybe 20% or 30% of what my job entails over extended periods of time). Specifically, to address the issue of having to write code in cb(1) format -- emacs has c-mode, which is highly extensible so that I can define what *my* c-mode should look like. As long as my co-workers and I can read it easily, my employer should have no problem with it. Plus, as I enter the code initially an emacs function bound to a key will adjust (beautify) an arbitrary region of C program text (or C++, lisp, nroff, Tex, FORTRAN (eww! :-) or straight ASCII text as you see here). Basically I can catch that before I even write the file out. I could go on for quite a while -- and start an editor war I am not prepared to wage -- but won't. My message for you is that you should not have to change your ways to accomodate the computer ... the computer should change its ways to accomodate your style. I think Apple was the first company to really embrace this philosophy. Emacs helps me, personally, to do this. -- jad -- John Dilley Hewlett-Packard Colorado Networks Division UX-mail: jad@cnd.hp.com Phone: (303) 229-2787 -- This is not an official statement from Hewlett-Packard Corp., and does not necessarily reflect the official position of HP. The information above is provided in good faith but completely without warranty of any kind.
jat@xavax.com (John Tamplin) (10/18/90)
This is sortof off the subject, but one problem I have always had when working on team projects was differences in coding style. Typically each person wrote in their own style, so you wound up with a mess of different styles which really makes the code hard to read. Sometimes, people would reformat bits of code (usually fixes applied by someone else) to their own style, something that especially trashes RCS-type programs, since there are a lot of changes to lines in the program that aren't changes as far as the compiler is concerned. A tool I have always wanted to build, but have never had (made) time for is this: a version of RCS which canonicalizes (is that a word?) the source as it is checked in. When a user checks out a ocpy of the file, the program checks an environment variable or some ~/.xxx file to discover the user's style preferences. That way, each person can inspect code in their favorite style, without impacting any other team members' ability to do the same. The file could be stored as a normal program, or the version control system might choose to store it in some kind of tokenized form to ease reassembly into different styles. Maybe one of these days I will actually write it. -- John Tamplin Xavax jat@xavax.COM 2104 West Ferry Way ...!uunet!xavax!jat Huntsville, AL 35801
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/19/90)
In article <1990Oct17.183455.12233@xavax.com> jat@xavax.com (John Tamplin) writes: >A tool I have always wanted to build, but have never had (made) time for is >this: a version of RCS which canonicalizes (is that a word?) the source as >it is checked in. When a user checks out a ocpy of the file, the program >checks an environment variable or some ~/.xxx file to discover the user's style >preferences. It seems like you could build this with the normal RCS and "indent". As long as the programmer's style can be represented by indent options you're in luck. "indent" it in one style and stuff it in RCS. When it is checked out, "indent" it in the programmers style. The only real work necessary might be a few changes to indent to fit your exact desires. Anybody done this? I'm tempted because people around here indent w/spaces. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif