Catch Source Code Errors - Tricks Wanted

John Dilley jad at hpcndnm.cnd.hp.com
Fri Oct 12 07:32:40 AEST 1990


In article <13785 at mcdphx.phx.mcd.mot.com> edski at 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 at 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.



More information about the Comp.unix.programmer mailing list