> A silly example I sometimes use here is the next software requirements: > If the input 2 is given, then the result must be 4. If the input 4 is given, > then the result must be 16. > General solution, just writing the requirements: > if input == 2 > then result = 4 > else if input == 4 > then result = 16 > else ERROR > > A solution with a little more thinking: > result = input * input > > Both solutions do exactly as asked but the last one has a much wider usage. > Lesson learned: remove unnecesary checks by using the proper routine. > (Nothing whatsoever to do with RFB or VNC, but I can't resist ...)
I think this is really wrong-headed thinking. The initial coding easily accommodates version 2 of the program, the spec for which reads "If the input is 3, the result is 10.", whereas the second coding would have to be rewritten rather than enhanced. (You see the simple-minded result=input*input perhaps should have been result =6*input-8.) The initial coding also accommodates version 3 of the program, the spec for which reads "If the input is anything other than 2, 3, or 4, the output is 42." Worse still, if, rather than returning an error when unexpected input is received, the program returns something predictable, you guarantee that somebody somewhere will grow to depend on it. It will probably be your biggest meanest nastiest customer who, if you change it, will throw out your product. Probably the absolute worst part of the second coding is that it distances the code from the spec. The spec doesn't say "The output is the square of the input." so there should be some compelling reason to make the code read that way. Imagine the Bombay programmer (who was the maintenance programmer for the product) trying to implement version 3 if version 2 had been coded result =6*input-8 and Corni had written the comments in Dutch. _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
