ArticleS
.
TimOttinger
.
ClassNotBasicProgram
Edit Page:
!title Not a BASIC Program I have noticed that a lot of tests are written in a way that looks startlingly familiar to me. When I was starting in the late 70s and early 80s, I worked in *that* language. BASIC. Don't blame me, it was the language that all the computers I'd ever seen supported. It was in ROM in the TRS80 models, the [[!-NorthStar-!][http://en.wikipedia.org/wiki/North_Star_Computers]] computers, and the early PCs. I had an interpreter and editor in CP/M and later DOS. In !-NorthStar-! and PC it was even an interesting variation that had some modula-like features. But it was basic. In BASIC in the old days, it was common to have a lot of variables declared at the top of a program. These would be followed by a bunch of subroutines (or, if you were lucky, functions). The vogue technique at the time was to use 'GOSUB'. Some of the cool kids even had gosub ''labels'' instead of line numbers. That was pretty advanced, and a little spooky at the time. Bear with me, I am kinda old. Anyway, when you would 'gosub' to a routine, it would do some things. Among those things were side-effects, like the modification of the global variables. You could not tell by looking at the gosub call that there were going to be major 'sea changes' in the application, necessarily. Names were short and limited, so you had to go look through the code. You might find that one routine would overwrite dozens of variables, rewrite lists, and perform other scary activities. The trick in the day was to know all the variables, and which ones were going to be modified in which way by which subroutine. The subroutines were really formed because there was some segment of code you wanted to repeat, and ideas like "maintainability" and "single purpose" and "command/query separation" were not known in my circle of friends. Not back then. It was brutal, and is the REAL reason that so many people my age have grey hair. Or no hair. Or both, like me. The scary part is that I've seen a number of test files that remind me an awful lot of the old BASIC programs. One routine would modify/initialize a whole lot of member variables. The next routine might modify several more. The routines do not take parameters and they return void. The only effects they have are side-effects. We were refactoring, and noticed that naming a method according to what it really did required a name composed of nouns, verbs, and conjunctions. Really: "and" in the method name. Sometimes a few of them. No, that's not alright with us. It took a while to dawn on me, and now I have a few more things to blog: 1 A CLASS IS NOT A BASIC PROGRAM. 1 SIDE_EFFECTS ARE BAD 1 A SINGLE FUNCTION SHOULD SERVE A SINGLE FUNCTION 1 TEMPORAL BINDING DOES NOT A FUNCTION MAKE 1 A BUNCH OF SIDE-EFFECTS DO NOT ADD UP TO A SINGLE PRIMARY EFFECT Having written those recommendation I feel much better, and I suddenly realize that I probably don't need to blog about them. Most of the people reading [[!-ButUncleBob-!][http://butunclebob.com/]] should understand them perfectly well. !commentForm !* Thu, 29 Jun 2006 23:24:04, ${ottinger}, North Star Museum I found a cool photo of the old [[North Star computers][http://www.bowkera.com/north_star_museum.htm]]. It's like looking at some old friends. I had 'Horizon' and 'Advantage' models. *! !* Sat, 1 Jul 2006 13:46:28, , I'm not that old, but close. I used BASIC in Sinclair computers, Atari computers, which had GOTO line and GOSUB line which was a kind of GOTO, but it rememebered where it was called so that when RETURN was called, would return where it was called. Today GOTO doesn't exist and GOSUB/RETURN is the only mechanism avaliable. And it was BASIC around 1986. Variables could not be declared. So the advice: Do not use global variables. Do not create methods that have more than one purpose. Methods should be named after what they really do (IntentionRevealingName). Do not declare variables at the start of a method, but when they are really needed to avoid name pollution. *! !* Tue, 26 Sep 2006 20:08:26, ${ottinger}, Accumulate and FIRE! I found another example of this described at the wikipedia. I was browsing patterns and found [[Accumulate and Fire][http://en.wikipedia.org/wiki/Accumulate_and_fire]] which I think is the basic programming mode of most Windows programmers and BASIC programmers in the old days. It is indeed an antipattern (or smell). This is how I see a lot of tests being written, where "global" means "class scope". *!
Hints:
Use alt+s (Windows) or control+s (Mac OS X) to save your changes. Or, tab from the text area to the "Save" button!
Grab the lower-right corner of the text area to increase its size (works with some browsers).