Searching for "Best Practices" is commendable and should benefit you.
However, don't expect agreement, even after 50+ years, of what is and isn't "Best Practice".
That aside, you should have a set of "local standards" for your site. These you should adhere it, as should others there. If they contain dumb things, try to get them discussed, but go with the consensus after that. If everyone has the best chance of understanding the code that everyone else writes, things will be better. Traditionally COBOL systems are team efforts, so understanding other people's code, and making yours understandable, is very important.
Sometimes the local standards are not what many would describe as best practice. They may have been at least good practice at some time in the past, but local standards change slowly.
You ask in a comment about blank lines. Perhaps 40 years ago (less depending on hardware at a particular site) not having blank lines would make sense. Each blank line would be a punched-card. Each card takes some time to read. Each card may become faulty and jam the reader, or be rejected.
Even slightly after that sort of time, CPUs weren't anywhere near as fast as they are today. So reading a blank line just for the compiler to ignore would have some effect on compiler throughput for large programs, and with perhaps one address-space only dedicated to compiles and running 24-hours-a-day, little things add up.
Today, don't worry about it at all. Make your program readable for a human. The compiler will always manage, it is us who needs help in reading programs, so give it to us.
A. MOVE B TO C. PERFORM D. D. MOVE E TO F. PERFORM I. I. MOVE Z TO Q.
That's "valid" COBOL. Theoretically faster to compile than coding eight separate lines (even without blank lines), but work out how much longer it takes a human to understand what is happening.
NEW-CLIENT-RECORD.
[all the stuff you need to do for establishing a new client record]
PERFORM NEW-CLIENT-SUB-RECORD
.
NEW-CLIENT-SUB-RECORD.
[all the stuff you need to do ...]
PERFORM CLIENT-COMPLIANCE-VERIFICATION
.
CLIENT-COMPLIANCE-VERIFICATION.
[all the stuff you need to do ...]
.
Do not try to "save storage" by using REDEFINES. Define separate fields, and avoid the "side effect" headaches, either when you write the code, or when someone (perhaps you) throws in a careless change in two months time.
Use good names for everything. Ditch any idea of VAR1 or I, J, K.
IF VAR1(J)>7
MOVE "Y" TO VAR4
END-IF
Would you prefer debugging that, or writing this:
IF CT-OF-APPLES-IN-STOCK ( WAREHOUSE-STOCKED-IN )
GREATER THAN MAX-CT-FOR-PERISHABLES-TYPE-P014 [which has a value of 7]
SET OVERSTOCKED-ORANGES TO TRUE
END-IF
In fact, look, you can't even write that about the oranges, can you? Whilst writing, you can even ask yourself (and look at the spec, ask the analyst/designer/business-user) should that be the "count" of the apples, or something like "box" or "pallet" or whatever, because apples in a warehouse aren't usually stored singly.
Try to get anything useful out of the VAR1/I rubbish and you'll spend a lot of time tracking down what a field holds, and what it means.
Make your programs readable. Do nothing to make things obscure. Follow local standards.
Read the manuals. Read other people's code. Experiment. Think about what people suggest, and what benefit it gives you.
For instance, you will find WS01-data-name, WS02-data-name etc. The W is useful, the rest is nonsense which will cause frustration when defining data. Without renaming everything, it will not be possible to include new data in a group of existing data it is related to. You will find local standards dictating such things. Try to get those changed, but go with the flow if you fail (write some macros/scripts to do the work for you, of course).
