Xref: utzoo comp.misc:8431 comp.sys.ibm.pc:45920 Path: utzoo!utgpu!watserv1!watmath!att!cbnewsc!dritchey From: dritchey@cbnewsc.ATT.COM (don.ritchey) Newsgroups: comp.misc,comp.sys.ibm.pc Subject: Re: The *ART* of Computer Programming Summary: need more context Message-ID: <14203@cbnewsc.ATT.COM> Date: 7 Mar 90 17:35:38 GMT References: <1990Mar3.065257.13674@wolves.uucp> Organization: AT&T Bell Laboratories, Naperville, Il. Lines: 75 in article <1990Mar3.065257.13674@wolves.uucp>, ggw@wolves.uucp (Gregory G. Woodbury) says: > In article <1990Feb26.234217.23251@aucs.uucp> 861087a (Andreas Pikoulas) writes: >> From Paul Tom's book "Computer Information Systems" page 169 >> >> " Not only do organizations standarize programming languages, they also >>develop coding styles so that programs written by different programmers >>all follow good coding conventions. While SOME consider programming a >>"creative activity", a programmer should be as creative as a bricklayer >>following a blueprint for building a wall on a house. Creative programming, >>like accounting, can only get the user into trouble. " >> > Despite the note about e-mail elaboration, I think this really needs > to be aired publicly. Here is my response.... > > There are two main problems with this attitude. > 1) It assumes that computer programming is dealing with some exact problem > that has exactly one correct solution. > 2) It assumes that the bricklayer reading a blueprint for a building wall > will have nothing inexact or creative to do. > I read this quote and the response to it a little differently. The main problem that I have seen in maintaining other people's software is excessive creativity where it is not appropriate (which is what I think the author probably intended to say). When the plan calls for simple "brickwork" with no need for fancy, convoluted "creative" code, then the programmer should write simple, non-creative code. When the time comes for the programmer to have to work around the "windows" and "doors" of the code, where the "brickwork" gets more complex, then the need arises for finding creative solutions to complex problems. What I suspect we need is what I would call "disciplined programming", which is not a blanket condemnation of "creativity", but a knowledge of when creativity is necessary. A well disciplined programmer knows how to use the conventions of coding style that places the punctuation in the expected places, follows the project guidelines for indentation and commenting, and rejects the desire to show off when the need simply isn't there. For example: If space is not a critical resource, then there is no need for fancy data packing and unpacking functions that consume run time and may actually use more memory (due to the size of the function) than they save. Similar analogies can be made for other cases. On the other hand, when creativity is essential (to overcome some limitation such as process run time, lack of heap space, or whatever) the well disciplined programmer writes the "creative code" as clearly and as cleanly as possible. The more creative and convoluted the code must be to overcome the obstacle, the greater the need for explanations and in-progress comments to let the maintenance programmer figure out what was done and how. It also helps the programmer figure out what he or she was doing when the inevitable requirement comes in to add some enhancement to that same creative code that was written 6 months ago. If the problem is sufficiently complex, the programmer may have to start from scratch to figure out "What did I do, and why did I do it THAT way." I don't think that the author of the book intended for the programmer to write code while within a straight jacket, but instead for the programmer to develop a sense of discipline of how to follow the rules of the project, and know when and how to successfully break the rules. Just like the Burger King commercial, "Sometimes you just got to break the rules!". That doesn't mean you have to break the rules all the time. For whatever that was worth, there it is. #include Don Ritchey dritchey@ihlpb.att.com or don.ritchey@att.com AT&T Bell Labs, Room IH 1D-409, Naperville, IL 60566, (708) 979-6179 :-) The advice you get here is worth all that you paid for it. :-)