| PLEX86 | ||
|
transputers again was: The dissolution of Commodore 2926
Ok, people should not write long chunks of code. But a language should provide the tools for doing so -- because the programmer may be too occupied with some other problem to be able to afford to think about function length in any relevant way1. As an example, the C code I'm maintaining right now. In the past, it was added to repeatedly, on very short notice, by one overworked guy. The opportunities for testing and debugging were very limited, so no attempts were made to redesign it. Result: extremely long functions with lots of code duplication. The interesting thing was that the original author apparently belonged to the "one exit point" school. So the functions looked like this (but with much worse nesting level): int foo(void) { int ret = OK; ... if(bar) { if(baz) { ... pages and pages of complex code ... } else { baz-relayed error handling } } else { bar-relayed error handling } return ret; } transputers again was: The dissolution of Commodore 2928 I always believed life was too short to learn TeX. I think it came from having to read too many Springer-Verlag "Lecture Notes In Computer Science" (read: halfbutted formal methods conference papers that... When I had added early error exit points for !bar and !baz It occurred to me ( transputers again was: The dissolution of Commodore 2927 Now consider comparing subroutines with CISC instructions. And look at compilers analyzing statements from an HLL down to the level of...
That's one reason I like C++. 1 Splitting a function well requires thinking. Just splitting it in four equal-sized parts creates an even bigger mess. --
|
||||||||