more than one line. You can split a single line of C over two lines, obviously, and if I do that, I always brace it because it does allow your eye to see the code-flow. SB My eye is not very good at that, either. The number of bugs I’ve had to remove from code because the braces weren’t in the right place is more than I care to mention. Of course, the answer to that is to have tools. If you look at something like Python, it won’t even compile a program if it’s not laid out properly. BC That’s interesting. Python does go to an extreme. SB I wrote some Python code without the tools to support your intent, and it’s actually quite difficult. A lot of other people find it quite easy, so I’m probably in the minority. EA I have to admit I find it jarring. All my life I’ve been using this one style. SB I don’t mean to be too critical—there are many things about Python that I like. It has some language features that somebody, presumably, actually thought about. So I quite like a lot of it, but the idea that they went back to Fortran layout was surprising. BC Although it’s perhaps heresy to say it these days, I’m not enamored with Python for a couple of reasons. One is I think there’s a difference between having a style that you enforce and having white space be relevant to the language. EA One of the big mistakes I made with sendmail was using tabs as active characters in the config file. The reason I did it was because make files were exactly the same way, so I just kind of emulated that idea. Then I talked to [make creator] Stu Feldman and he said, “The biggest mistake I made in make was using tabs as active characters.” SB The point I was making—and I don’t disagree with you—is that there are some guidelines that improve the code, but my question is, how much does this actually help you structure the code so you can see the relationships between the functions that you’re writing and deduce what happens if you make a change? Those seem to be the important questions about code, not so much “Can I read it? Can I write it?” BC “Can I read it? Can I write it?” are important questions, especially if you’re in an environment where you may need to modify someone else’s code and vice versa.

SB I agree, but there are higher-level structural issues in code that I don’t see that helping with, and they are the ones that are actually, in my opinion, more important than what I’m calling these lower-level issues.

BC An interesting metric would be how many lines of code you read for every line that you write. In my case, I read a lot of code. Even when I’m writing new code, I’m reading a lot of code to figure out how to write that code and how to structure it. So for me, the style gives you the parameters in which you develop new code, and I think it does actually help.

EA I believe Fred Brooks said something about no silver
bullet [“No Silver Bullet—Essence and Accidents of Soft-
ware Engineering,” 1986],
and coding standards are

not silver bullets, but I think they are a reason- _{We believe that on the} able part of a program to produce clean code. It eighth day, God created doesn’t matter, as Bryan _{80 columns, and ye shall} points out, if it’s only one person who’s ever going to never exceed 80 columns. be reading the code. Who _{Bryan Cantrill} cares? But when was the last time there was only one person involved in any kind of code that made it out of the room?

BC It still matters with one
person because it’s really
not just one person. It’s multiple people—namely, it is
you at different times of your life. I’ve written lots of code
where I’m the only one who will ever edit it, and if I die,
that source will no longer be edited at all. The problem is,
I’m editing it at different times of my life, and the state
that I may have once had on the problem falls out of my
head; and when I go back in, it has been written by a dif-
ferent person—it has been written by the “past-me.” So, I
think even for one person, style is important.

SB I’ll amplify that. When I’m writing code, I’m making deals with myself, but I’m two different people in different parts of the code. That’s what you do when you write code. When you abstract something out, you’re making a deal with yourself: here’s what it’s going to do and here’s the interface. Then you put your other hat on, and you’re now the client of that code that you just wrote for yourself. I think that’s an important distinction to make when you’re writing code.