The definitive guide to whitespace, part 1

OptionC fails to semantically group the arguments with the call, so it's out.

Some will argue extra whitespace in OptionB makes for better readability. They are wrong. Again, when I read it quickly, it fails to semantically group arguments. The call to func just looks ridiculous.

So OptionA is the only one that makes any sense.

I am using my background in typography when I say "semantically". Unexpected whitespace is cognitively jarring. No one would write English like OptionB, and in OptionC, the space between the name of the function and the items in parentheses indicates a separation of ideas, which is what you don't want.

Isn't everyone taught OptionA anyway?

Perhaps I didn't specify "subjective" clearly enough. By "subjective" I mean any argument that relies on any sort of individual preference, such as your argument to exclude option B. I will even exclude arguments that rely on probabilistic preferences ("3 out of 5 people prefer x").

Your argument for OptionC is borderline, but I think still subjective. You say unexpected whitespace is cognitively jarring but there's an implicit "for me" at the end of that. You might be able to reformulate that one to be more objective.

And it doesn't matter what people are taught. Most of what we are taught is wrong anyway.

If those are going to be your rules, I'm not sure we're going to get anywhere.

The only objective source I have for the laying out of text is the rules of typography, and they say putting spaces between things means they are two separate things. If there's two things with a space in the middle that I have to think of as one thing*, that's cognitively jarring because one can't use the same heuristics applied to all other reading. OptionC seemingly slain by the rules of putting words on paper/a screen.

(* - You might be thinking of "fire truck" or similar as a counterexample, but that's still two things, one a noun, the other an adjective modifying the noun. Think instead of an unexp ected space in a word or a paragraph

break in the middle of a sentence.)

Whitespace is going to be a subjective thing no matter what. Decades later, people can't decide on one way lay out their braces to denote code blocks. Or which kind of paradigm is superior in a text editor. This strikes me as the same problem: people like different things, and they're going to choose the one they like the best, and no matter what they choose, someone will come along with arguments that boil down to "UR DOIN IT WRONG"

I can see people who might like optionB. It strikes me as time-wasting frippery, but if you want to lay out your code that way, go nuts.

We might not get where you think I'm going, but we should get *somewhere*. Note that I'm not trying to convert the masses to switch. Better people have tried and failed at that; I have a different solution to that particular problem.

However, I would, for my own benefit, like to determine the best programming practices. Ones that result in the highest possible quality of code. There are simple idioms you can use in how you write code that makes it more robust against error. I'm looking for analogous practices when it comes to visual layout of code.

I'm also dismissing all arguments that are based on "readability" because I believe that if you use a particular coding style, it becomes more and more readable to you as you get used to it. Given enough time, even OptionC (which I admit looks really weird to me right now) would look natural. Since all coding styles are therefore equally "readable" in the long run, I'm only considering things that have a functional benefit. Apologies if that offends your sense of typography, but that's what I care about.

I think I see what you're trying to drive at, but I don't believe there's one way to visually lay out code that necessarily makes one a better programmer, if for no other reason than if there was, we'd be doing it by now.

Parsing? Lexing? Bah! The Code Monkey cares not for the concerns of the Compiler Guru. They want different things out of a language (people love perl, but no one wants to rewrite a perl compiler). I don't care which is easiest to write a compiler for; that only has to happen once.

And since you don't care about readability (which strikes me as the only tangible thing visual layout of code impacts), I don't see anywhere to go.

I don't buy that argument. By induction you could say that we've already discovered everything there is to discover. And anyway, I would rather waste time in an attempt to find a better code layout and fail than assume there isn't one and sit around on my ass twiddling my thumbs.

What about the arguments I gave in the post? Are those not tangible benefits that are independent of readability?

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, Structure and Interpretation of Computer Programs

When I write code, I try to make it as readable as possible (or that's what I tell myself). How the machine deals with what I've written is an afterthought.

In general, I prefer human-friendly coding choices over computer-friendly choices. The increasing popularity of high-level programming languages (machine language -> C -> C++ -> Java -> Python) would also imply that humans are code's target audience, not machines.

I agree wholeheartedly that code must be readable before all else. I'm not disputing that in the least. What I am disputing is your assumption that one style of coding is inherently more readable than another, and that it will remain so for all of eternity. That is simply not the case. To me right now, options A and B are equally readable. Given a month or so, option C would be just as readable. I have no control over what other people find readable, so conforming to most readable style overall is pointless. The only logical action is to find the most useful style, and then *make* it the most readable as well for myself.

Incidentally, you seem to also assume that readability and functionality are mutually exclusive. They are not. For instance, being able to search for a particular piece of code and finding it before you get distracted or lose your mindspace is critical to readability. If the formatting of your code is such that it takes too long to find code, then that hampers readability.

By induction you could say that we've already discovered everything there is to discover.
That's a straw man. I'll buy you a goat if you're the first person to ever examine the layout of code by...what metric exactly?

I still don't see what kind of ruler one should be applying. You threw readability out. We've agreed that ease of compilation/lexing/parsing shouldn't enter in to it. Your post then mentions grepping and typing time. I don't believe that any one is easier to grep than any other, and people type at such different rates that typing time can't be an objective measure.

I'm out of this discussion. I'm now certain your investigations will be fruitless.

To be determined once y'all weigh in with additional options and arguments.

This is syntactically incorrect. "y'all" is the singular second pronoun, equivalent to the word "you". To refer to multiple people in the second person^*, you have to use "all y'all".

And I abstain from voting since you're tossing readability concerns.

*: Interestingly, in older English, there was a difference between the singular and plural second person - "you" and "yous", respectively. Standard Irish English retained this difference (and Cockney resurrected it), whilst standard RP English dropped it.

The definition I heard for "y'all" is different. I think it's plural second person, as in "what do y'all want for dinner".
As it was explained to me "all y'all" means each person in the group you're addressing. as in "did all y'all enjoy the movie".


what about:
optionD ( foo, bar, func ( baz ) );

"Y'all" is a contraction. It contracts "you" and "all": y'all = you all.

"What do y'all want for dinner?" = "What do you all want for dinner?" = "What do all of you want for dinner?"

"Did all y'all enjoy the movie?" = "Did all you all enjoy the movie?" = doesn't make sense. It's colloquial and I believe is used the same was if the first all wasn't there, but strictly speaking, the phrase is grammatically incorrect.

strictly speaking "ain't" is incorrect as well, but it still has a well understood meaning.

An arbitrary google search confirms my definition: http://memphis.about.com/od/midsouthliving/qt/yall.htm

Interestingly, in older English, there was a difference between the singular and plural second person - "you" and "yous", respectively

No, in early modern English the distinction was "thou" for singular and "you" for plural.

The dangers of learning about English from the Irish, illustrated ;)

I was reminded of this entry by this posting from The Verge. And yes, I still believe option C is the most human-readable, and thus must be the correct answer ("it's prettier"! etc).