× 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.


  • Subject: Re: Section naming conventions
  • From: Howard Weatherly <hweatherly@xxxxxxxxxxxx>
  • Date: Wed, 25 Aug 1999 16:56:12 -0400

As far as names go, I prefer to name sections descriptively. While I
have no axe to grind with either numbering 0001-descriptiv-name Section
or A00-discriptive-name Section, I have never found the numbers all that
useful, just something else to look at. (trust me, with my eyes thats an
issue :))

As far as conventions go however, I have adopted a quasi 'C' habit of
using upper and lower case. I choose to code variables in UC and verbs
in mixed case eg.. Move ITEM-THINGY to THE-OTHER-THINGY. Also keeping
the Section names and Paragraph names in UC eg.. Perform
ADD-TO-TOTALS....

To speak directly to your example, READ-FILE Section leaves me wanting
more also, I would prefer READ-ITEM-FILE Section as a name. Over time
however I discover that all rules are begging to be broken for some very
good reason, for instance I doubt that I would have a section for a
simple file read, I would prefer an FILE-ACCESS Section with multiple
paragraphs identifying whatever file and whatever function be it READ
WRITE REWRITE DELETE etc... and this would be only after I determine
that my own rule of "only one read per file" needs to be violated.

So having said that, and adhering to structured programming conventions
as much as possible, I find myself faced with a dilema, do I violate my
rule and do an initial read inline followed by a read inline at the end
of a performed until paragraph or do I code a seperate performed read?

Now we get to the techie part, do I want to expend the cycles on a
perform for the sake of following a rule or do I want to be as efficient
as possible and bend the rules?

Well the answer is "It depends" and that is true of your examples, it
depends on where you are, who your doing it for, what the situation and
shop standards are and a whole raft of other "things" that bring you to
a conclusion.

Which way is right???  THE WAY THAT WORKS CONSISTANTLY

Hope this helsp in some small way.

Chris.Chambers@v2music.com wrote:
> 
> I am intrigued to learn the various naming conventions experienced by those of
> you who not averse to using SECTIONS.
> 
> I have only ever worked with A00-INITIALISATION, B00-PROCESS, Z00-CLOSE and
> subordinate sections would be AA00, BA00, BB00, ZA00 etc.
> 
> In any manuals or guidebooks the sections merely have names that seem to have 
>no
> formula eg READ-FILE SECTION or
> UPDATE-RECORD SECTION which shows no dependencies. (Do people actually write
> like that?).
> 
> I am thinking of adopting new conventions when developng new systems and would
> like to hear views on the pro's and con's of peoples naming conventions.
> 
> Thanks,
> 
> Chris.
> 
> +---
> | This is the COBOL/400 Mailing List!
> | To submit a new message, send your mail to COBOL400-L@midrange.com.
> | To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---END
+---
| This is the COBOL/400 Mailing List!
| To submit a new message, send your mail to COBOL400-L@midrange.com.
| To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
| To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END



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.