> 1. I think one of the best "recent" (ha! Recent to a mainframer!) > improvements in assembler was the support for long names. It took me a while > to get used to violating the column 1-10-16 thing.
Well, SOAP limited names to 5 upper case letters and GATE limited them to one, but I happily used longer names once I could. That said, I do use single letter loop control variables when the loop is tiny. > In assembler every variable has scope over the entire module You haven't seen enough assemblers, or even enough IBM assemblers. Certainly the assemblers for the S/360 line don't have scopes, but that isn't true for all assemblers. > 2. Yes, comments should say what a block of code does. Comments like "Clear > R2" on an SR R2,R2 instruction are noise. When drafted into taking over a programming class, I told my students that I would take points off for such comments. What I didn't do, and should have, was to throw students' homework at other students; if the user students couldn't understand the code I should have taken it as a red flag. > 4. I always liked the way ISPF edit FIND works. You can say WORD, PREV, ALL > and so forth in any order. When using ISPF EDIT, I miss XEDIT. When using XEDIT, I miss ISPF EDIT. I really wish that IBM would offer an editor that cleanly combines the features of both. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Charles Mills [[email protected]] Sent: Tuesday, June 15, 2021 6:24 PM To: [email protected] Subject: Re: Coding for the future 1. I think one of the best "recent" (ha! Recent to a mainframer!) improvements in assembler was the support for long names. It took me a while to get used to violating the column 1-10-16 thing but long names are clearly goodness. I don't think I would *ever* use an assembler variable name of less than about four characters. OKAY EQU 0, WARN EQU 4 come to mind, although Ret_OKAY and Ret_WARN are probably better. I write now mostly in C++, and there names can have a very small scope, so tiny names are not so bad: for (int i = 0; i < limit; i++) foo[i] = 0; It's pretty clear what i is doing and it does not survive beyond the semicolon, so there is little opportunity for confusion. In assembler every variable has scope over the entire module, so I don't see how I could defend the use of i as a variable name. 2. Yes, comments should say what a block of code does. Comments like "Clear R2" on an SR R2,R2 instruction are noise. 3. Robustness is good. 4. I always liked the way ISPF edit FIND works. You can say WORD, PREV, ALL and so forth in any order. 5. I once fired a developer because of his indenting. Well, that is an exaggeration but not much. He was a poor developer, and one of the obvious manifestations of that was an indenting style that could charitably be called random. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bob Bridges Sent: Tuesday, June 15, 2021 3:07 PM To: [email protected] Subject: Coding for the future In a recent email one of our number, whose name I won't mention except to say that his initials are Jeremy Nicoll, made a comment that got me thinking about ~my~ past and present coding habits. Like most programmers (maybe), I had some habits that I no longer tolerate. For example: 1) I used to hate long-winded variable names. Ok, that's a bad example to start with, because I still do. But I no longer use one-character variable names, ever; I use two- to four-character names if they're to be used only in one brief section, but if they're supposed to last longer I make them more descriptive; and even the shorter ones follow a naming standard that I'm familiar with. It wouldn't be any help to someone else who had to modify my code, though. 2) I know everyone says to comment your work, but I never used to. "I'm the only one who'll use this code", I thought, "and I know what I did". Oh, fool! I can forget what I was doing a mere two months later, much less two years or two decades. So now I'm more likely to use one-line comments on every other line and a paragraph at the head of each section. Well, perhaps I exaggerate, but not much. 3) Not for me, any longer, to assume that my TSO commands will work correctly. For pretty much every interaction with the outside world I include checks for file-not-found, empty datasets, missing non-optional arguments, anything I can think of. I want my programs to go on working long after I've forgotten how to invoke them properly. 4) This isn't exactly a bad-coding issue, but as much as possible I want the input arguments on a command to come in any order I happen to think of them at the time. My routine to search through a concatenation of PDSs for a particular module has to receive the DD and module name in a particular order, but mostly it's possible to say "tso command arg1 arg2 arg3" or "tso command arg2 arg1 arg3" without any confusion. 5) One thing hasn't changed: Like most of us here, I was ~always~ rabid about proper indentation. (Where by "proper" I mean "consistent"; I know styles can vary, but as long as there's no variation...) I'm just curious about other issues that y'all are careful about that maybe you weren't when we were young and foolish. --- Bob Bridges, [email protected], cell 336 382-7313 /* While the best judge of Christianity is a Christian, the next best judge would be something more like a Confucian. The worst judge of all is the man now most ready with his judgements: the ill-educated Christian turning gradually into the ill-tempered agnostic, entangled in the end of a feud of which he never understood the beginning, blighted with a sort of hereditary boredom with he knows not what, and already weary of hearing what he has never heard. -from the Introduction to _Everlasting Man_ by G K Chesterton */ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
