Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: A GNU Makefile (was: ... header files **and** inline management) Message-ID: <4321@lupine.NCD.COM> Date: 10 Mar 91 02:00:29 GMT References: <1991Feb20.083327.2028@eua.ericsson.se> <4187@lupine.NCD.COM> <1991Mar4.085153.13371@eua.ericsson.se> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 71 In article <1991Mar4.085153.13371@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes: +rfg@NCD.COM (Ron Guilmette) writes: + +>In article <1991Feb20.083327.2028@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes: +At LOOK '91 in Denmark recently I listened to Steven Weiss, and he pointed +out that "A quality system is a system that is easy to maintain". My bitter +experience is that hacking may seem to give quality software, but if you +look at it from the maintenance point of view, it's not. I'm paid to do +quality software, and will do so carefully my way, since I'm not a hacker, +nor a specially good programmer (I'm still looking at the Andrew Koenig +paper on Function Objects in The C++ Journal * summer 1990, since my mind +just refuses to grasp how this rediculously short piece of code actually +works :-! ). My use of the terms "hacker" and "hacking" were perhaps unfortunate, since they undermined the point I myself was trying to make. What I meant to say was "rapid prototyping". (1/2 :-) I believe that I (and some others) can write good quality code, and that such code can be developed (by some people) both quickly and in an evolutionary way. You need not necessarily plan every tiny detail of your trip in advance in order to arrive at a good place (in the end). +>All I know is that my own experience of developing new C++ code led me +>to feel that it would often be that case that I would need to make some +>change which would need to be reflected in *both* the interface part and +>in the implementation part. I found myself repeatedly doing: + +> start editor to edit .C file +> modify .C file +> exit editor (saving changes) +> start editor to edit corresponding .h file +> modify .h file +> exit editor (saving changes) +> start editor to edit .C file +> . +> . +> . + +I think you can justify to the money department at your company, that +they will make money if they buy you a larger monitor since you will be +more efficient that way. I have a VERY LARGE monitor, thank you. (NCD makes terrific X-terminals after all.) I also have Emacs (even though I prefer not to use it most of the time.) That's not the point. The point is that I'm a damn slow typist, and no matter how big you screen, and no matter how many windows your editor can keep open at a time, you have still got to type in another filename each time you need to edit another (related) header file. That's what my scheme allowed you to avoid. Now I guess that you could get yourself a 32" monitor and have a script or a mock-lisp routine (for Emacs) which you could execute once each morning (when you fisrt came into work) which would bring up 82 windows (one for each .h or .C file in the system you are working on now) and then you would never have to open another window on another file, but I for one think that it makes more sense to just keep my interface and implementations parts in single individual files. That cuts down on the typing I do, and (perhaps even more importantly) I find this to be a wonderful organizing principal. It basically forces you into a certain style of coding where you are forced to keep everything which is directly related to a given class type (e.g. `foo') within one single source file. You can then call the file `foo.C'. Now, when some other `maintainer' gets stuck with your code, and when he finds out that `foo' objects are malfunctioning, he knows exactly where to look. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.