× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dan,

Like Scott I agree with you. Every time I have to write a new programme I ask 
myself this question: "When should I put a piece of code in a subroutine?" 
Having answered that question I have my programme already half written, as I 
only have to type it.

I always think it horrible to see a main line (the first C-specs before the 
first subroutine or procedures) that only exist of one line: EXSR MAIN (sic!). 
And that subroutine calls other subroutines, nothing more (Think of having a 
DOW doing an EXSR). Those programmes do not have a spine.

But some fortunates do have to design their programmes that way, as it is their 
shop's standard. 

I can think of some situations to use a short EXIT subroutine (with SETON LR 
and RETURN) as default statements. But then this subroutine will be called from 
different parts in the programme.

Sorry I was not there to help you out in the other thread; perhaps it was a 
long one and at some point I loose interest in the debates in some threads.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 9-4-03 at 13:06 Dan wrote:

>I was the one getting beat up by Jon & Barbara & others in this very list for 
>refusing to create one-line
>subroutines, (...)
>
>@#$*&!!!  These drive me crazy!  I realize, from the list response, that I am 
>likely in the
>minority.  I like to think there's more of a balance between one-line 
>subroutines and monolithic
>programs.  Oh, and thanks for not lecturing. <g>




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.