forums.silverfrost.com

[technophobe]

Hello Folks,

I'm currently putting the finishing touches to a farily large program (about 2000 lines of code) and was thinking of ways to improve the structure of it to make it easier for my colleagues to understand. I am fairly new to programming in fortran and was advised, when starting this project, to write the code without using subroutines. I don't know why I was advised to do this but my superviser belived it was the best way to proceed.

I am thinking now that the structure of the code would be much easier to understand if I wrote each section as a subroutine and the main program would simply call them in the correct order. The code is rather complicated and takes a long time to execute. I was wondering if putting everything into subroutines would slow down program execution?

I'd really appreciate any advice you guys could offer,
Bren

[JohnCampbell]

Dear Technophobe !

My advice is:
Learn about modules to store common variables etc.
Try to divide your program approach into basic actions.
create subroutines for these basic actions.
you may even want to group some of these actions as a combined actions subroutine
cut and paste your program into these subroutines / actions
get a new superviser !!

best of luck.

[DrTip]

Here Here to all comments especially

Get a new supervisor

if he says anything about dropping punch cards run very fast.

lack of structured code is mostly what gives Fortran a bad name.

btw 2000 lines of code isn't that much just sort of normal.

A great piece of advice I saw somewhere (admittedly not about Fortran but still true )

when you come in in the morning try and delete code before you write anymore new code

ie work out which bits are doing the same things,and write subroutines for those.

the overhead of calling subroutines is tiny. The overhead of debugging unstructured code is enormous especially if someone else wrote it,( like may be yourself 12 months earlier )



Carl

[technophobe]

Thanks very much for the advice guys.

I'm happy enough with my superviser , but think I will spend some time re-writing my code using subroutines. I was only concerned that it might slow things down further.

The code is pretty complicated and inolves lots of loops within other loops. This is necessary to solve my problem but it does makes it pretty slow to execute (

Thanks again,
B

[weaverwb]

Wow! That has to be the worst programming advice I've ever heard!

One rule of thumb is that any code segment (e.g., a subroutine) should be about one page long. As any complicated code extends over several pages, it becomes harder and harder to follow -- especially if you do have lots of loops.

The concept of subroutines is more about only writing code once if you are to do it (or something very similar that can be parameterized) many times. But you may write them because you're starting off with a case statement or some other branching of choice.

Obviously you can't always keep it down to a single page or two, but you should think hard about why you can't. In any case, you should separate "paragraphs" of code, the same way you separate logical text modules.

Now that the good old days of optimizing to minimize the use computer resources are behind us for most code, the second priority (after the part about having code that does what it is supposed to) is readability. What is obvious to you today will be totally obscure next month. KISS!

Good luck.

[IanLambley]

Loops within loops eh?

I must tell an amusing tale of such a thing from the 1970's. We had a student in our office at a time when computing was done by timesharing over a 300baud phone line and you paid by the cpu-second. Due to the noise of the terminal, it was situated in a separate room. The student wandered slowly into the main office and interrupted the boss, saying that the program he had written and was running seemed to have gone dead. The boss jumped to his feet, performed a beautiful Rugby hand-off on the student to get him out of the way. Sprinting to the "Terminal room" he hit Control-C to stop things, and the Company got the biggest monthly bill it had ever seen, something like £900, then £900 was worth £9000.

The moral is check your code as small functional blocks in subroutines and consider the effect of loops within loops. All the advice given here is good, with the exception of your supervisor's.

[technophobe]

Hello again guys,

The type of problem I'm solving is transonic flow around a flexible airfoil. There are several areas where I have nested one loop within another although for this type of problem I don't know of any other way to write the code.

A very brief schematic of my code would be

[JohnCampbell]

Bren,

You probably would not gain a lot of run time efficiency, but the program flow may be more understandable with the following program example. This would definately lead to significant programming and debugging efficiency!

You would probably be advised to similarly structure "DO_SOME_USEFUL_MATHS" as I would expect there are a number of numerical phases to this computation also.

Regards John

Module experiment_data
( declare most useful variables)
end Module experiment_data

Program test_options
use experiment_data
!
logical use_this_option
external use_this_option

call initialise_all data

DO experiment=1,10
DO velocity=v1, v2, dv

if ( .not. use_this_option (experiment, velocity) ) cycle

call run_this_model (experiment, velocity)
call report_this_run

ENDDO !velocity loop
ENDDO !experiment loop

call summarise_all_runs

end Program test_options

subroutine run_this_model (experiment, velocity)
!
! note : experiment and velocity are not in the module.
! putting key do loop variables in modules can be a risky programing approach
!
use experiment_data

DO I=1,200 !this loop switches between rows of my domain
DO J=1,200 !switches between columns of the domain

DO_SOME_USEFUL_MATHS

ENDDO !J-loop
ENDDO !I=loop
end subroutine run_this_model

logical function use_this_option (experiment, velocity)
use experiment_data
!
! you can use this area to test for un-necessary run options and probably
! save a lot of run time
!
...
end logical function use_this_option

--------------
I gave an example above of declaring an external function. You could possibly declare them in the MODULE, and then possibly use CONTAINS and include the function code as well. Unfortunately, I am yet to use these constructs in my programming approach, as I am yet to identify the benefits this approach provides. I continue to develop libraries of routines, typical of a pre-f90 approach.

I hope the above programming example helps. If anyone disagrees I would look forward to learning from their different approach.

[technophobe]

Thanks John that was a very helpful post.

I have yet to use some of the programming blocks within my existing code. My superviser has been using fortran since punched cards were the norm and I suspect that he's not used to structured programming.

I guess it's something I'm going to have to get used to myself - it seems much more efficient!

Many thanks,
Bren

[JohnHorspool]

[weaverwb]

Hi,

We're wandering a bit but this last post has touched on a sore point which I can't resist commenting on.

For us real geezers -- I started with Fortran II -- there were always IF statements and there was always well-structure code. There is little that annoys me more than a language that tries to enforce good programming practice. Programming is a craft and programmers should be expected to behave as craftsmen or pay the price.

The unrelenting attack on the GO TO statement is an example of this misguided approach. There are essential locations for GO TO statements, including certain error conditions and, especially, complex logically situations where not using them creates nearly impenetrable code.

I had once written some complex code in an expert system language and used GO TOs to exit complex logic predicates at critical points. Some expensive consultants came to migrate my code to the latest version of this language that had totally dropped GO TOs to keep up with current vogue. While theoretically they should have been able to do it, the cases were so complex that no one could figure out how to do it. The problem was solved by surrounding each logical block with IF tests to mimic single GO TO statements far above in the code.

This failed the readability test (see my earlier post) and the quality/comprehensibility of the code was diminished. The best programmer is the one who makes the code the easiest to understand.

Modern constructs certainly reduce the need for GO TOs and this is a good thing but if you were writing spaghetti code it was because you were yet a novice and learning your craft. I'll bet now you would write much more intelligible code in Fortran IV.

apologies again for the digression.