|
|
|
|
|
Immediately after I awoke last Saturday, it quickly became clear that the
warm autumn wind and crystal-blue sky would "force" me to
endulge in a little fishing excursion. So, I ambled down to
the basement to retrieve my gear, anticipating a quiet
afternoon in the outdoors. Imagine my dismay, then, when
I found that I hadn't stored my poles quite as neatly as
I should have, and I wasted a good half-hour of sunshine
untangling the unseemly mass of fishing line binding them
all together.
Much of the scientific code written in decades past was developed with one goal in mind: to get the right answer. As a result, it's not uncommon to find code riddled with "goto" statements and variable names which bear no resemblance to the utility of the values they hold. As well, there is generally little-to-no documentation (comments) provided within the body of the code, so it's often nearly impossible to casually read a piece of code and have an idea of what is going on. Luckily, the greatly enhanced performance of modern computers has led to the slow death of this type of programming. As computers have become faster and more capable of handling truly large amounts of data, computer programs have concomitantly become much more complex. Because of this development, programmers of scientific applications have come to realize that it's just not possible to keep track of their codes if the logic is continually jumping to remote reaches of the program. Indeed, for maintaining tight control over the workings of a very large, complex code, it is necessary to make the logic flow as smoothly as possible and clearly delineate where the specific functionalities of the program reside. Probably the most basic way of gaining some organizational control over a piece of code is the use of subroutines. By dividing one big program into several smaller ones, each with a specific task to perform, the programmer can write one clean main program that calls these subroutines as needed. This is also quite efficient in that subroutines represent a form of reusable code -- different values can be computed at different times using the same piece of code. Additionally, Go To Page: 1 2
The copyright of the article How to Avoid Spaghetti Code in Scientific Computing is owned by Adam Hughes. Permission to republish How to Avoid Spaghetti Code in print or online must be granted by the author in writing.
|
|
|
|