Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UPPERCASE vs lowercase vs CamelCase vs snake_case

173 views
Skip to first unread message

Doc Trins O'Grace

unread,
Jul 8, 2015, 3:13:59 PM7/8/15
to
Generally I am a lurker in comp.lang.cobol. Nonetheless, I appreciate the wit
and wisdom I often glean from you all. Consequently, I have decided to ask a
question:

I have been a programmer for well over four decades. In that time I have written
in languages from Ada to ZPL. My intention is to continue programming for some
time to come.

Currently I am predominantly using Cobol. One of the things I've been thinking
about is changing my coding standard away from UPPERCASE to CamelCase. It
occurred to me that you all might be kind enough to offer me some suggestions.

The shop in which I am working is very small. There are currently no real
conventions other than the unwritten ones that surface in the code.

Would you each be willing to render up some of your favorite conventions? Also,
might I prevail on you to explain your thinking on the pros and cons of each?

I will be grateful for your time and attention.

Pete Dashwood

unread,
Jul 8, 2015, 10:52:31 PM7/8/15
to
Quoting from the Book of Gensys in the Chronicles of Cyberdom...

"In the beginning was the mainframe and it did not recognize lower case for
programming."

I know it's hard to believe, but there wasn't ALWAYS agreement on a "byte"
being 8 bits. Some architectures used 6 bits either as a character or as
part of a "word". That meant that, in order to represent lower case
characters "control" or "shift" characters had to be inserted into the data
stream. That could get messy so it was just easier to use only upper case.

As a result, by the time everybody standardized on the 8 bit byte (which
could easily support lower case) it was too late, and programming in upper
case had become the accepted norm.

After the ice age when computing was re-invented in the early 1980s by the
advent of desktop machines and personal computers, the demand for proper
text and word processing, using both cases exploded.

I can remember a Director in a major UK Corporation saying to me:

"My kid can poroduce documents in upper and lower case and put a signature
on them, with his Amiga, but we have a multi-million pound mainframe that
sends letters to customers on green lineflo in upper case, with no
signature. Can you do something about that?" (I did, but it was a huge
battle with entrenched programming attitudes and people (used to
bullshitting their know-nothing managers) telling me it couldn't be done,
until I introduced them to AFP and wrote a sample program that did it.)

As time passed it seemed that mainframe programming would stay in upper
case, while the rest of the world on networked systems became offended by
it... ("there's no need to SHOUT!")

Mainframe languages such as COBOL became available on workstations and you
could easily code in mixed case if you wanted to.

This led to some sites implementing standards that utilized this capability
(like reserved words being in upper case and user names in lower). As time
passed other languages started to replace COBOL and the "conventions" for
these languages (like CamelCase) spilled over.

With all the choice that is available today, what you use will depend on
your personal style preferences and the site standards where you work.

For myself, I don't use only upper case in COBOL any more because I find
mixed case easier to read. I like CamelCase for user variables as it means
there is no need to use hyphens, and hyphens can cause grief under some
circumstances (an immediate one that comes to mind is when you write COM
components in COBOL and the compiler generates ODL for the Typelib;
hyphenated names will crash and burn...CamelCase is safe)

If you have the latitude to decide what you will use, then these are the
considerations I would recommend.

1. Use what is easily readable.

2. Be consistent. (Don't change the way you write datanames, for example,
within a program. with some in upper, some hyphenated some in CamelCase and
so on.)

3. Don't assign significance to the format of an element. (Of course it's a
File Name; can't you see the first 2 letters of the name are in
capitals?...")

I have no idea what snake_case is and I don't think I want to know... :-)

Pete.

--
"I used to write COBOL...now I can do anything."


Rick Smith

unread,
Jul 9, 2015, 1:43:08 PM7/9/15
to
On Wednesday, July 8, 2015 at 10:52:31 PM UTC-4, Pete Dashwood wrote:

<snip>

> I have no idea what snake_case is and I don't think I want to know... :-)

See < https://en.wikipedia.org/wiki/Snake_case > for a brief description.

Apparently, I prefer 'spinal-case', as the article calls it.

Frank Swarbrick

unread,
Jul 9, 2015, 2:19:03 PM7/9/15
to
ITHINKALLVARIABLESSHOULDBENAMEDTHISWAY

or not

Pete Dashwood

unread,
Jul 9, 2015, 8:14:09 PM7/9/15
to
Thanks Rick.

A really interesting read...

docd...@panix.com

unread,
Jul 12, 2015, 9:04:36 AM7/12/15
to
In article <fea154ea-76b3-4377...@googlegroups.com>,
Consistency is paramount. In an almost Confucian 'rectification of names'
code processes should be where they should be and code alignment should be
as it should be. For example:

I know of nobody who would be confused or disoriented by:

PROCEDURE DIVISION.

PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
PERFORM 5000-MAIN-LINE THRU 5000-EXIT
UNTIL NO-MORE-INPUT.
PERFORM 9000-EOJ THRU 9000-EXIT.
STOP RUN.

Granted that those durned youngsters will roll their eyes, sigh and say
'Oh, this boring old stuff again!'... but they'll know where everything is
going and what it does (nore-or-less) while it is there.

(Geezers, duffers and gaffers will, of course, smile and say
'Pre-classical high counterpoint... later than Zarlino but not quite yet
Fux')

Obviously I am most comfortable with ALL CAPS. The only difficulty I can
see with mixed case is that successive generations of maintenance coders
will consider different things worthy of emphasis... and programmers from
languages where mixed case makes a real difference will be lead down blind
alleys by looking for significances between realdifference,
Realdifference, RealDifference and REALdifference.

DD

Rick Smith

unread,
Jul 12, 2015, 11:41:48 AM7/12/15
to
On Sunday, July 12, 2015 at 9:04:36 AM UTC-4, docd...@panix.com wrote:

<snip>

> Consistency is paramount. In an almost Confucian 'rectification of names'
> code processes should be where they should be and code alignment should be
> as it should be. For example:
>
> I know of nobody who would be confused or disoriented by:
>
> PROCEDURE DIVISION.
>
> PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
> PERFORM 5000-MAIN-LINE THRU 5000-EXIT
> UNTIL NO-MORE-INPUT.
> PERFORM 9000-EOJ THRU 9000-EXIT.
> STOP RUN.

I 'cachinnate' at that 'flumadiddle'! <g> (dictionary.com words of the day)

Actually, I never cared for the use of 'housekeeping'. I found it confusing
thirty-plus years ago and don't recall ever having used the term in
programs I wrote.

So, I found this definition:
< http://dictionary.reference.com/browse/housekeeping >,
'Computers. system tasks, as initialization and managing peripheral
devices, that must be done to permit a computer program to execute
properly but that do not directly contribute to program output.'

What 'system tasks' are done in COBOL? None that I see, because the
language hides all that. It seems to me that 'housekeeping' should be
reserved to describe a process in assembler, not COBOL!

(I have done 'housekeeping', as defined above, in assembler, when I was
doing embedded programming, but I never called it that.)

I think it is better to call it 'open-files', if that is all it does,
or 'initialization', if it does more!

Pete Dashwood

unread,
Jul 12, 2015, 9:27:11 PM7/12/15
to
I'm confused by this. :-)

I thought that user-defined names in COBOL cannot start with a number... :-)

Maybe it only applies to datanames...

>
> Granted that those durned youngsters will roll their eyes, sigh and
> say 'Oh, this boring old stuff again!'... but they'll know where
> everything is going and what it does (nore-or-less) while it is there.

Except for the ones who would never code PERFORM...THRU and consider it
anathema... :-) (I'm not one of those; I prefer performed sections but I
have no problem with COBOL coded to any kind of standard (or even NOT coded
to any kind of standard). The key, as you mentioned, is CONSISTENCY.

When you think about it, it DOES seem a bit redundant, looking at the above.

You know it will always be ... THRU xxxx-EXIT, so why code it? (on the
arguable assertion that the less code there is in a program, the better...)

If HOUSEKEEPING, MAINLINE, AND EOJ are coded as SECTIONS then you get:

PERFORM 0000-HOUSEKEEPING
PERFORM 5000-MAIN-LINE
UNTIL NO-MORE-INPUT.
PERFORM 9000-EOJ
STOP RUN.

(Personally, I'd remove the period after NO-MORE-INPUT because it is
inconsistent; put one on every line or don't...I'm a fan of scope
delimiters, with a convention (applied consistently) that if a PERFORM is
coded WITHOUT a scope delimiter (END-PERFORM), then it is a "simple"
PERFORM. I've spent many hours poring over bugs caused by misplaced periods
or things that looked like a period on a printout but actually weren't. so I
am of the opinion that the fewer periods there are in COBOL , the better. I
agree it is arguable, and I wouldn't refuse to maintin COBOL code that has
full stops in it. [Note the inconsistent use of "period" and "full stop" in
this paragraph; it is aimed at an international audience.] :-))

>
> (Geezers, duffers and gaffers will, of course, smile and say
> 'Pre-classical high counterpoint... later than Zarlino but not quite
> yet Fux')
>
> Obviously I am most comfortable with ALL CAPS. The only difficulty I
> can see with mixed case is that successive generations of maintenance
> coders will consider different things worthy of emphasis... and
> programmers from languages where mixed case makes a real difference
> will be lead down blind alleys by looking for significances between
> realdifference, Realdifference, RealDifference and REALdifference.

Yes, that's very true. Again, consistency of use can help a lot.

Pete Dashwood

unread,
Jul 12, 2015, 9:40:18 PM7/12/15
to
An interesting take on it, Rick.

What if it does a whole lot more than "open files" OR "initialize"?

For example, code produced by a code generator may be required to trap
exceptions, or do certain system tasks like instantiate an object so the
process can run.

It's "housekeeping"... :-)

Your post made me think about what I consider to be "housekeeping". I think
it is anything that is peripheral to the task the application needs to do.
Application code processes an application; anything else it has to do is
"housekeeping" that is required by the computer system it is running on. (On
reviewing the dictionary definition you provided above, I find myself in
agreement with it; we diverge on whether or not COBOL does system tasks. In
the OO environment it certainly does and there are constructs in the
language to let it do so.)

Personally, I have used both terms and have no problem with either of them.

Rick Smith

unread,
Jul 12, 2015, 11:09:02 PM7/12/15
to
On Sunday, July 12, 2015 at 9:40:18 PM UTC-4, Pete Dashwood wrote:
> Rick Smith wrote:

< snip>

> > Actually, I never cared for the use of 'housekeeping'. I found it
> > confusing thirty-plus years ago and don't recall ever having used the
> > term in programs I wrote.
> >
> > So, I found this definition:
> > < http://dictionary.reference.com/browse/housekeeping >,
> > 'Computers. system tasks, as initialization and managing peripheral
> > devices, that must be done to permit a computer program to execute
> > properly but that do not directly contribute to program output.'
> >
> > What 'system tasks' are done in COBOL? None that I see, because the
> > language hides all that. It seems to me that 'housekeeping' should be
> > reserved to describe a process in assembler, not COBOL!
> >
> > (I have done 'housekeeping', as defined above, in assembler, when I
> > was doing embedded programming, but I never called it that.)
> >
> > I think it is better to call it 'open-files', if that is all it does,
> > or 'initialization', if it does more!
>
> An interesting take on it, Rick.
>
> What if it does a whole lot more than "open files" OR "initialize"?
>
> For example, code produced by a code generator may be required to trap
> exceptions, or do certain system tasks like instantiate an object so the
> process can run.
>
> It's "housekeeping"... :-)

Or,

perform initialization

...

initialization section.
perform get-command-line-parms
perform get-app-saved-parms
perform start-app-objects
perform open-files
perform etc
.

Besides, any who 'keep' a 'house' know that 'housekeeping' is an
on-going process. It may begin when one moves in, but continues
until one moves out. Thus the analogy to 'housekeeping' breaks
down when other things 'that do not directly contribute to program
output' are done during 'main-line' and thus are outside the
'housekeeping' procedure. An example from my own work is the use
of report writer to create a 'report of program output' that is
not used elsewhere in the application.

The bottom line, it seems to me, is that someone, eons ago, coined
'housekeeping' in the belief that the word was analogous to the
activities that person wanted to describe. It became accepted by
many, perhaps most; but to me it is confusing because the analogy
just doesn't work. <g>

Rick Smith

unread,
Jul 12, 2015, 11:21:45 PM7/12/15
to
On Sunday, July 12, 2015 at 9:27:11 PM UTC-4, Pete Dashwood wrote:
> docdw...@panix.com wrote:

<snip>

> > I know of nobody who would be confused or disoriented by:
> >
> > PROCEDURE DIVISION.
> >
> > PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
> > PERFORM 5000-MAIN-LINE THRU 5000-EXIT
> > UNTIL NO-MORE-INPUT.
> > PERFORM 9000-EOJ THRU 9000-EXIT.
> > STOP RUN.
>
> I'm confused by this. :-)
>
> I thought that user-defined names in COBOL cannot start with a number... :-)
>
> Maybe it only applies to datanames...

Data-names may begin with numbers but must contain at least one
non-digit.

Procedure-names may be entirely numeric.

8.3.1.1.1 User-defined words,
"With the exception of section-names, paragraph-names, and
level-numbers, each user-defined word shall contain at least
one basic letter or extended letter."

Pete Dashwood

unread,
Jul 13, 2015, 8:29:09 PM7/13/15
to
I thought about this some more and I think I may have been thinking of
hyphen. I learned it in 1967 so I guess my memory , while generally
excellent, may have slipped a cog here.

docd...@panix.com

unread,
Jul 14, 2015, 8:06:54 AM7/14/15
to
In article <d0gifd...@mid.individual.net>,
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
>> In article <fea154ea-76b3-4377...@googlegroups.com>,
>> Doc Trins O'Grace <doctrin...@gmail.com> wrote:

[snip]

>>> Would you each be willing to render up some of your favorite
>>> conventions? Also, might I prevail on you to explain your thinking
>>> on the pros and cons of each?
>>
>> Consistency is paramount. In an almost Confucian 'rectification of
>> names' code processes should be where they should be and code
>> alignment should be as it should be. For example:
>>
>> I know of nobody who would be confused or disoriented by:
>>
>> PROCEDURE DIVISION.
>>
>> PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
>> PERFORM 5000-MAIN-LINE THRU 5000-EXIT
>> UNTIL NO-MORE-INPUT.
>> PERFORM 9000-EOJ THRU 9000-EXIT.
>> STOP RUN.
>
>I'm confused by this. :-)

Thence comes the logicks:

DocDwarf knows nobody who is confused by (sample).
Mr Dashwood is confused by (sample).
DocDwarf knows Mr Dashwood.
Mr Dashwood is nobody.

Congratulations on achieving One-ness, Mr Dashwood!

[snip]

>> Granted that those durned youngsters will roll their eyes, sigh and
>> say 'Oh, this boring old stuff again!'... but they'll know where
>> everything is going and what it does (nore-or-less) while it is there.
>
>Except for the ones who would never code PERFORM...THRU and consider it
>anathema... :-)

It makes no difference what they would never code nor what they'd consider
anathema, Mr Dashwood; if they know enough COBOL so that they understand
'the PERFORM will direct execution of code to the first imperative
statement following the paragraph label specified and after the
period/full stop of the specified THRU paragraph execution will resume at
the statement following the PERFORM' they will not be confused by this.

If they do not know how a PERFORM THRU works then whoever let them into
the code deserves what happens.

[snip]

>You know it will always be ... THRU xxxx-EXIT, so why code it?

In order to maintain the program's code in an orderly manner unto the
seventh generation of maintenance and beyond.

>(on the
>arguable assertion that the less code there is in a program, the better...)

The balance between elegance and legibility is kept, in part, by art.

>
>If HOUSEKEEPING, MAINLINE, AND EOJ are coded as SECTIONS then you get:
>
> PERFORM 0000-HOUSEKEEPING
> PERFORM 5000-MAIN-LINE
> UNTIL NO-MORE-INPUT.
> PERFORM 9000-EOJ
> STOP RUN.

(must... resist... cheap... shot... ... can't)

Of course... nobody would think to discuss coding SECTIONs versus
paragraphs

DD

docd...@panix.com

unread,
Jul 14, 2015, 8:14:14 AM7/14/15
to
In article <e511e5f7-9b1e-4443...@googlegroups.com>,
Rick Smith <rs84...@gmail.com> wrote:
>On Sunday, July 12, 2015 at 9:04:36 AM UTC-4, docd...@panix.com wrote:
>
><snip>
>
>> Consistency is paramount. In an almost Confucian 'rectification of names'
>> code processes should be where they should be and code alignment should be
>> as it should be. For example:
>>
>> I know of nobody who would be confused or disoriented by:
>>
>> PROCEDURE DIVISION.
>>
>> PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
>> PERFORM 5000-MAIN-LINE THRU 5000-EXIT
>> UNTIL NO-MORE-INPUT.
>> PERFORM 9000-EOJ THRU 9000-EXIT.
>> STOP RUN.
>
>I 'cachinnate' at that 'flumadiddle'! <g> (dictionary.com words of the day)
>
>Actually, I never cared for the use of 'housekeeping'. I found it confusing
>thirty-plus years ago and don't recall ever having used the term in
>programs I wrote.

A rose by any other name &c, Mr Smith. At the start of a program one
checks the validity of passed parameters, opens files (as needed),
initialises storage areas, loads lookup tables... in general, one makes
things tidy and ready for the hard slog of processing that is to come.

Some men find it confusing that a woman will give them a playful slap in
order to indicate a kind of adult interest... overcoming that confusion
may lead to activities of great delight for all.

I'm not sure that metaphor was entirely appropriate.

DD

docd...@panix.com

unread,
Jul 14, 2015, 8:18:29 AM7/14/15
to
In article <91817abd-8069-47f7...@googlegroups.com>,
Rick Smith <rs84...@gmail.com> wrote:

[snip]

>The bottom line, it seems to me, is that someone, eons ago, coined
>'housekeeping' in the belief that the word was analogous to the
>activities that person wanted to describe. It became accepted by
>many, perhaps most; but to me it is confusing because the analogy
>just doesn't work. <g>

Next week: Stop-Light Confusion, or, 'keeping the traffic moving when you
JUST KNOW that red indicates good luck, yellow is for happy sunshine and
green is for lush fertility'.

DD

Rick Smith

unread,
Jul 14, 2015, 11:09:53 AM7/14/15
to
On Tuesday, July 14, 2015 at 8:14:14 AM UTC-4, docd...@panix.com wrote:
> In article <e511e5f7-9b1e-4443...@googlegroups.com>,
> Rick Smith <rs84...@gmail.com> wrote:
> >On Sunday, July 12, 2015 at 9:04:36 AM UTC-4, docd...@panix.com wrote:
> >
> ><snip>
> >
> >> Consistency is paramount. In an almost Confucian 'rectification of names'
> >> code processes should be where they should be and code alignment should be
> >> as it should be. For example:
> >>
> >> I know of nobody who would be confused or disoriented by:
> >>
> >> PROCEDURE DIVISION.
> >>
> >> PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT.
> >> PERFORM 5000-MAIN-LINE THRU 5000-EXIT
> >> UNTIL NO-MORE-INPUT.
> >> PERFORM 9000-EOJ THRU 9000-EXIT.
> >> STOP RUN.
> >
> >I 'cachinnate' at that 'flumadiddle'! <g> (dictionary.com words of the day)
> >
> >Actually, I never cared for the use of 'housekeeping'. I found it confusing
> >thirty-plus years ago and don't recall ever having used the term in
> >programs I wrote.
>
> A rose by any other name &c, Mr Smith. At the start of a program one
> checks the validity of passed parameters, opens files (as needed),
> initialises storage areas, loads lookup tables... in general, one makes
> things tidy and ready for the hard slog of processing that is to come.

Mr Dwarf, a rose by any other name and initialization by the name
housekeeping both, it seems to me, violate 'rectification of names';
but, in fairness, you did say 'almost'. <g>

< https://en.wikipedia.org/wiki/Rectification_of_names >
"Confucius believed that social disorder often stemmed from
failure to perceive, understand, and deal with reality.
Fundamentally, then, social disorder can stem from the
failure to call things by their proper names, and his
solution to this was the rectification of names."


> Some men find it confusing that a woman will give them a playful slap in
> order to indicate a kind of adult interest... overcoming that confusion
> may lead to activities of great delight for all.
>
> I'm not sure that metaphor was entirely appropriate.

Not entirely age appropriate.

"Eww, girl cooties!"
"Yippee!"
"It'll be a while for the pill to work."
"Ain't happenin' babe!"

But you did say 'may'. <g>

Bruce M. Axtens

unread,
Jul 15, 2015, 4:41:10 AM7/15/15
to
On Tue, 14 Jul 2015 20:06:53 +0800, <docd...@panix.com> wrote:

>>
>> If HOUSEKEEPING, MAINLINE, AND EOJ are coded as SECTIONS then you get:
>>
>> PERFORM 0000-HOUSEKEEPING
>> PERFORM 5000-MAIN-LINE
>> UNTIL NO-MORE-INPUT.
>> PERFORM 9000-EOJ
>> STOP RUN.
>
> (must... resist... cheap... shot... ... can't)
>
> Of course... nobody would think to discuss coding SECTIONs versus
> paragraphs
>
> DD
>

When I was taught COBOL (way back in 1983), it was all SECTIONs. We had
VT52s and VT100s hanging off a VAX-11/750. Okay, it was a CAE (College of
Advanced Education -- halfway between a Uni and a Technical College) in
Lismore, NSW, Australia. All sorts of other anomalous things happened
there.

Bruce.
--
Using Opera's mail client: http://www.opera.com/mail/

Bruce M. Axtens

unread,
Jul 15, 2015, 4:50:40 AM7/15/15
to
On Tue, 14 Jul 2015 20:18:28 +0800, <docd...@panix.com> wrote:

> Next week: Stop-Light Confusion, or, 'keeping the traffic moving when you
> JUST KNOW that red indicates good luck, yellow is for happy sunshine and
> green is for lush fertility'.
>
> DD
>

A Solomon Islander, and teacher, visited friends of mine some years ago.
They drove him around Sydney a fair bit during his visit. They accompanied
him back to home at the end of his visit. The teacher described traffic
signals to his class as follows:
Red means "Stop". Green means "Go". Yellow means "Go Faster".

Richard Maher

unread,
Jul 15, 2015, 8:10:17 AM7/15/15
to
On 7/9/2015 3:13 AM, Doc Trins O'Grace wrote:
>
> I will be grateful for your time and attention.
>

All lower-case with underscores instead of hyphens.

docd...@panix.com

unread,
Jul 15, 2015, 8:37:41 AM7/15/15
to
In article <eab15562-10b2-406d...@googlegroups.com>,
Rick Smith <rs84...@gmail.com> wrote:
>On Tuesday, July 14, 2015 at 8:14:14 AM UTC-4, docd...@panix.com wrote:

[snip]

>> Some men find it confusing that a woman will give them a playful slap in
>> order to indicate a kind of adult interest... overcoming that confusion
>> may lead to activities of great delight for all.
>>
>> I'm not sure that metaphor was entirely appropriate.
>
>Not entirely age appropriate.

After the age of mewling, puking babe and whining schoolboy perhaps
moreso.

>
>"Eww, girl cooties!"

And folks wonder why I ask 'Are the kids still up?'

>"Yippee!"
>"It'll be a while for the pill to work."
>"Ain't happenin' babe!"
>
>But you did say 'may'. <g>

Were I to be less generous in my sprinklings of subjunctives there might
be fewer alternatives to consider, maybe.

DD

0 new messages