Some would rebel. Some were absolutely convinced that they were goodprogrammers and I was just some over-the-hill old guy that didn’t knowwhat he was doing. I know I would have said the same thing not long ago:“The program works. What is your problem?” When I say, “You don’t getcredit because the program works. We’re going to the next level. Workingprograms are a given,” they say, “Oh.” Then they talk to other people anddiscover that that’s basically the BBN standard. You can’t explore a newidea in doing something if you are not craftsman enough to make thecomputer do what you had in your mind.

I had a preference of how I liked my global variables and how I liked mysubroutines organized and I got into a multiday battle with one guy wherehe said, “Look, it works just fine” and he was such a good programmer thatI didn’t want to pull rank. I felt it important that he understand that I wasnot just being a tyrannical turkey; that there was a reason why I wanted himto do it this other way. He didn’t realize how hard it is to understand aprogram with a single C subroutine that’s 42 pages of code long.

Seibel: Yikes!

Cosell: I argued with him because I’m a big fan of call-once subroutineswhere the only function of the subroutine is to abstract some little part of aparent subroutine. When you read the parent subroutine—in my approachto programming—and you get to this place in the code and you getdistracted with the details of this big nexus of stuff, I like to pull that wholeclump out. Now you have a single thing that says, “Sort the table and findthe best route,” even though this is the only place it’s called. Someoneoptimizing the code would say, “That shouldn’t be a subroutine. Put that inline.” But it’s a little subroutine where I can isolate it. It’s obvious what theinputs are. You can see the algorithm, and only be concerned with that. Hehated when I used to say, “Your routines are too complicated. Yourroutines are spanning big chunks of the design”. He’d say, “That’s OKbecause I can do it all in one routine.”

He rebelled but eventually he did it my way. Then the next task he had wasto take a big piece of code from one of the programmers working on anearlier effort and make it fit into our system. He worked on that for almosta week. He so hated the other guy’s program that he complained to myboss that there aren’t strict enough programming standards in the division.And the other guy was programming the way he had wanted to programbut with a different spin. So he saw what happens when one very intense,very good programmer doesn’t segment it down. You get one very longprogram—it’s not that the program was spaghetti code but there were justso many levels of complexity in this one linear suite. He almost pissed meoff because, as I say, he went over my head to demand that the departmenthad to have standards to not allow that thing to happen.

Seibel: Not realizing that his own previous code would’ve probably fallenafoul of the same standards?

Cosell: No. He got that. He was a convert. It’s sort of like the guys whogive up smoking and are the most pains in the butt about other people stillsmoking. He became one of the strongest guys on my project. He used tonag me when I wasn’t careful enough—when I compromised. My projectwas the first project of its type he had ever worked on. Communications,real time, all this stuff—all new to him. But he was a smart guy and he wentthrough this little epiphany and came out of it the programmer I alwaysthought he was going to be. Last I heard, he was doing wonderfully. Withhim it worked out. Other people didn’t like working with me because theyfound me too overbearing; I can’t imagine why.

Seibel: Did you have particular rules for how much or how little tocomment?

Cosell: I don’t put a lot of comments in my code because I think youshould be writing your code so that it is readable and your algorithms andthoughts are clear in the code. I put comments that say this routine issupposed to do this, and usually some description of how you call it—whatdo you do when you get exceptions, what the order of the arguments is,and things like that. But the code itself should clearly express what you aredoing.

The only place I tend to put comments in my code is when my instinct says,“This particular piece of code, even though it works, doesn’t clearly statewhat I’m trying to accomplish.” And so I put a comment in the code to say,“This code sorts the table,” if it may not look like your standard tablesortingcode because, as it turns out, I can take advantage of something.

I have never been a fan of structured programming listings where everysubroutine has to have 18 lines of comment at the beginning and thearguments are in the right order. I don’t do a consistent segmentation of myprograms. Some of my subroutines are complicated and some are simple. Ido worry about things like layout; I’m part of the contingent that arguesabout curly braces.

One of the reasons is because I read code to understand what it does asopposed to reading code to see what each little piece of it is. So when I seean if statement, for example, I see the condition. I’m now thinking yea ornay on that condition, and if I want to skip the if statement I like having aprogram organization that lets my eye flip down to the end of the ifstatement without me having to process a lot of syntax. So I’m one of thoseold-fashioned guys that likes lined-up, open and close braces.

If you made column five go away, my code would look like, “operator, openbrace, close brace; operator, open brace, close brace,” which lets me seethe sequence of operators. Another part of that is related to something Imentioned before: if the open brace is too far from the close brace thenoften it’s doing too much, in which case I can pull it out. Sometimes even ifit’s not doing too much I’ll still pull it out because I can’t apprehend whatthat little branch is doing if there’s too much crap in there.

I try very hard to hide the crap, to move the crap someplace so that I canfollow the flow of the code, so I can build the picture in my head of whatthe code is doing. I have a lot of trouble reading some programming stylesbecause I have too much trouble trying to absorb the block structure. It’sinteresting that the guy that did Python was clearly of a similar mind. Heeliminated the syntax wars because he doesn’t have open and close braces.When you see an if the open curly brace is always there implicitly and theclosed curly brace is also implicitly there and if you need to find the nextthing, it’s lined up under the if. I use an editor in C and in Perl, and Iassume that editors in Python do the same thing, where you can click on abutton and it shrinks the whole thing so you only see the outer structure.

I don’t like to fight these style wars on the basis that one style is ugly. I liketo believe I fight the style wars is because it interferes with meunderstanding the code. I was always pretty good at that. Unless you couldconvince me you’re better at understanding code than I am, you have atough fight convincing me your way is better.

Seibel: Certainly coming in cold to new code and debugging it is aparticular skill that not every good programmer has, which it sounds likeyou did.

Cosell: Indeed. And there are two aspects of that. There was another guy.His name was Steve Butterfield. And he was also a good fixer, but theantithesis of me. Steve was about the best I have seen at not having any cluehow a program worked and fixing it. He could dive into a program andchange some little ugly piece down in the bowels of the code to make it dosomething different. Big, complicated programs, Steve could leap in and fixlittle things leaving them, to my view, functionally better but worse off.