If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
On Sun, 10 Aug 2003 10:53:16 -0400, Andrew Gideon
wrote: Roger Halstead wrote: I've seen code that students turned in where it took more work to decipher than it did to write it. Course I saw a few students who could write Pascal that way too and it's almost a plain language when it comes to source code. Please help. Shouldda had my old instructor in college. You turned in nothing with out a flow chart (Nazzi Schinerdman?). Then pseudo code, then the program with plenty of internal documentation. You might have trouble understanding the code in a few months but with the internal docs you at least knew what it was supposed to be doing. :-)) You've the perfect opportunity to teach that code is almost universally read more than it is written. More, the reader is typically unfamiliar with the code being read - even if it's the author, but a few days or weeks or months or years downstream. When I was working as a Sysadmin, Developmental analyst, and finally as a project manager I spent a good deal of time rewriting many of the programs used by our Laboratory Information Management System (LIMS). One of our people at a different site was a great programmer, except he would just write as much stuff as he could get on each line and no documentation. It not only made it difficult to read, but oft times the code would behave differently. We used a Pascal "like" language called VGL. It was easy to work with and easy to use. Dynamic memory allocation and pointers were transparent to the programmer so you never had to remember "new" and clear". Then again you didn't create any linked lists. This should motivate the writing of code designed not to be written quickly, but read easily. Avoiding nested returns, keeping logic expressions simple, commenting, writing short functions... Pretty Printing. Nested returns and logic need not be obscure. Flow charting *usually* cures problems with nested returns and logic. The big kicker is that like writing to make things easier for the user, writing for readability with internal documentation takes extra time. Time that can be saved many times over when modifying that code later on. Unlike writing for ease of use, writing for readability does not make the program more complicated. OTOH you will never get some programmers to use structured programming with pretty printing and internal documentation. Then again, that extra time may grate on management. When they see a programmer write code in a day that takes another two or three, they see efficiency. They don't see the extra weeks work it takes to decipher the quickly written stuff and modify it later on. With that kind of code it's often easier to start from scratch. I taught in a "new hire" program for a number of years at a couple of investment banks in NYC a while back. Too may (most?) of the people hired regarded the concept of writing code to be written as foreign. I hold one stance on that, if they aren't trained programmers they shouldn't be writing code. Programming is "grunt work" and takes a specific mind set and dedication. Then you get into larger programs that require team work and coordination. (I've been a project manager where both hardware and software were concerned as well as modifying the way a corporation had to do their networking with FDA validation) They have to write to a given specification so each programmers part will work with all the others which is far different than the environment where one person writes some small programs or routines. It's much like filing a flight plan. It has to be properly organized to work in the system. Roger Halstead (K8RI EN73 & ARRL Life Member) www.rogerhalstead.com N833R World's oldest Debonair? (S# CD-2) - Andrew |
#22
|
|||
|
|||
On Sun, 10 Aug 2003 21:37:58 GMT, Roger Halstead
wrote: Shouldda had my old instructor in college. You turned in nothing with out a flow chart (Nazzi Schinerdman?). Then pseudo code, then the program with plenty of internal documentation. NS diagrams ("structured flowcharts") never added anything to structured code. For that matter, neither did conventional flow charts. They may have had a use once before we settled on the control structures in use today. IMHO, there's still a pedagogical use for conventional flow charts to teach the student how the structures work (i.e. that the condition in a while loop is only evaluated at the beginning of each iteration). IMHO, there's no substitute for good naming conventions and comments that say *why* you're doing something. I can see what you're doing. Best ever example is the Edison Design Group source code (compiler front ends). They've turned it into an art form. In general, reading good code really does help you a better programmer, almost, but not completely, exactly unlike how talking about flying makes you a better pilot. Can we talk about aviation now? Morris |
#23
|
|||
|
|||
"G.R. Patterson III" wrote in message ... Roger Halstead wrote: OTOH you will never get some programmers to use structured programming with pretty printing and internal documentation. We used 100% code reviews by "peers" at my former employer. Those who didn't use structured programming didn't stay long. Then again, that extra time may grate on management. When they see a programmer write code in a day that takes another two or three, they see efficiency. I've seen plenty of C programmers crank out 30KLOC of garbage that had to be throw away. Since my former employer was not in the habit of handing the same assignment to several programmers, this never happened. Number of lines of code was not a factor in evaluation; what mattered was whether you had completed assignments on time, the perceived complexity of those assignments, and the number of bugs turned up in testing. Unfortunately for the IT field, KLOCs typically WERE the main point for evaluation, particualrly by non-technical magagement. Both the number of lines of code *and* the number of comment lines *were* recorded, however. Sad to say, non-objective measures have become the bean-counters standard for measurement. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AOPA Stall/Spin Study -- Stowell's Review (8,000 words) | Rich Stowell | Aerobatics | 28 | January 2nd 09 02:26 PM |
Want simple flight planning software | marc | Home Built | 13 | December 20th 04 04:36 AM |
Logging approaches | Ron Garrison | Instrument Flight Rules | 109 | March 2nd 04 05:54 PM |
us air force us air force academy us air force bases air force museum us us air force rank us air force reserve adfunk | Jehad Internet | Military Aviation | 0 | February 7th 04 04:24 AM |
"I Want To FLY!"-(Youth) My store to raise funds for flying lessons | Curtl33 | General Aviation | 7 | January 9th 04 11:35 PM |