Thanks Bruce, this is great. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message----- From: Bruce Barkstrom <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, November 4, 2014 at 6:12 AM To: "[email protected]" <[email protected]> Subject: A Note on Software Design to Make Maintenance Easier >I was working through some intricate programming yesterday and >observed that I should put in some input consistency checking >before turning a workflow over to the production >system. My guess is that in complex workflows, that kind of >automated checking would cut down on errors enough to be very >worthwhile. > >Don't know how much of the OODT software does that kind of >checking, but it might be interesting to see if it would help. >Even better would be documentation of cases where it did. > >This kind of work is like the help my Ada compiler provides >in detecting errors such as type inconsistencies and violations >of interface consistency. That kind of error checking really improves >my coding productivity. I've even gotten in the habit of building >exception handling right into my standard code construction and >testing work. Each module (i.e. subroutine) returns a Boolean >variable labelled 'OK' and a string called 'Err_Msg'. That makes it >easy to figure out where things have gone wrong, including diagnostic >notes on values of key parameters (sort of like "Err detected when x = 0 >in routine `check input'. It seems like a bother sometimes during code >writing, but it saves a lot of time after development moves on and some >new error crops up in the previous code after you've forgotten the >details. > >Bruce B.
