> The model estimated that using spaces instead of tabs leads to a 8.6% higher salary (confidence interval (6%, 10.4%), p-value < 10^-10). (By predicting the logarithm of the salary, we were able to estimate the % change each factor contributed to a salary rather than the dollar amount). Put another way, using spaces instead of tabs was worth as much as an extra 2.4 years of experience.
Maybe I'm not up on my statistics lingo, but saying "using spaces instead of tabs leads to a higher salary" sounds much more causal than "using spaces instead of tabs is correlated with a higher salary."
If they're going to say something leads to something else, I don't see how that one's justified over the reverse: "having a higher salary leads to using spaces." Isn't that's just as valid a conclusion from the data?
I needed a good laugh this morning. But of course this is pretty bogus relationship. People who drive Teslas make more money than those who drive Gremlins.
But there's an actual causation here (you need more money to buy a Tesla). Use of tabs and salary don't seem to have any relation one way or an other.
My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
On paper tabs sounds better, they're "configurable", you should indent with tabs and align with spaces, yada yada and everything is good in the world.
In practice however it becomes a big mess real quick unless you only work on projects with very good and perfectionist developers who understand when they should indent and when they should align and how they should configure their editors to do the right thing. See for instance the linux kernel codebase, it looks like arse if you don't use 8-space tabs and the coding style even tells you to use that value (it shouldn't really matter if tabs were used "right", except maybe for 80-column limits). So why even bother with tabs in this situation? Do we really care that much about wasting a few bytes?
Therefore I gave up on tabs a long time ago and tell everybody to just use spaces in all the projects I maintain.
There could be a third factor of conscientiousness that causes both high salary and use of spaces (to align your code just right). At least I will be using that excuse now when I spend time aligning function parameters in table columns.
> My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
They explicitly rejected this explanation after controlling for years of experience.
That being said I'd be curious to see "years of experience working in a team", because that's really when using tabs starts becoming tricky. If you're well disciplined and are the only person messing with your codebase the issues I mentioned in my previous post don't really apply.
Yea, I'm honestly surprised this is a thing still. I've not thought about the tab vs spaces "war" in years; because of Vim. I just hit Tab and whatever the pre-defined standard is, be it tabs or spaces and space count, is used.
Visually I can have it display in my editor of choice (Kakoune at the moment) however I want.
I guess I'm just saying, I would have thought the most common answer to this question would be: Whatever my employer / language standards dictate.
Anything less than 16 is literally blasphemy, in the modern world everyone is using 4k 32:9 monitors and for the best level of readability heavy indentation may as well be mandatory.
I believe the correct answer to that interview question would be "Follow the code style as established by the company, or keep it consistent within existing projects."
Of course they do because they are pig headed ignoramuses who are insist on getting their way in spite of all evidence that they're wrong. So of course they are good at getting raises. ;)
Well, of course. Only companies with fuck-you money can afford the extra bytes spaces take up versus tabs, so it follows logically that they'd pay their developers more.
It's pretty much an unwritten rule that a sarcastic joke on the internet with sufficient exposure will get a response by someone who didn't get it. Using /s really kills the fun (and whole point) of using sarcasm so it's a trade off to accept these comments will happen.
I'm impartial to downvoting as to reply literally doesn't usually add to the conversation, which is generally the point of downvoting. Losing karma shouldn't hurt your feelings.
If we called everything that was first described on Usenet as "Usenet's Law" then everything would be Usenet's law, probably even a couple of things in physics.
Do you mean partial to? As in, you favor downvoting over commenting to point out their mistake? Don't mean to be nitpicky, just genuinely confused if that was a mistake or I'm misunderstanding.
Yeah but we are human. Most people's feeling probably are hurt when their [non-malicious] comments are downvoted. But besides that I mostly agree with what you wrote.
I'm confused. Do you mean that we're allowed to create posts on Hacker News that are not sarcastic? I thought there was a rule, with a powerful AI enforcing it, stating that all posts had to be sarcastic. (Warning, this post is sarcastic and not meant to be taken literally.)
I've grown so tired of sarcasm. Online and in real life people are often saying the exact opposite of what they mean. We have to pick up the sarcasam to truly understand.
The real issue with sarcasm is that it actually places the burden of subtleness on the speaker, whereas people will usually blame the listener for not understanding. If the tone and wording isn't just about perfect, then it's obviously easy to miss sarcasm, let alone the humorous intent. And that is sometimes very hard in writing, hence the "/s" which ruins the fun for everybody. Likewise if the listener isn't educated about the object of sarcasm, little can s/he get the irony of the statement... I think missed sarcasm has more to do with failed cultural fit than fault of anyone involved. Which is probably why it's much more common and accepted within social circles than in general discussion. HN clearly fits the former, though; sarcasm is just about yet another norm here!
> HN clearly fits the former, though; sarcasm is just about yet another norm here!
Agreed, this is why I didn't want to take a hard position on downvoting someone for missing the sarcasm. We're in a public forum which crosses cultural boundaries. I see the argument for both sides.
Although I lean more towards downvoting as the majority of people on HN will get the joke and it's an opportunity to learn for those unfamiliar with the mainstream culture.
The article is serious. But I'm guessing there is either something subtle wrong in the analysis (they even find Go programmers who use spaces earn more, which makes no sense given that 99% of Go programmers use tabs), or it's some kind of weird selection bias, given that it the sample is self-selected.
I think that a rational sounding inerpretation can be found: all spaces means python programmer (mixing spaces and tabs messes up the indentation), python rulez, therefore high salary
Spaces over tabs is the default for IntelliJ. Given there are over ten million Java developers who are in very high demand, Python is practically a rounding error.
While your comment is obviously meant as a joke, it somehow rings true from my anecdotal experience.
I'd also like to see an analysis of space-vs-tabs as it relates to operating systems. Again, from anecdotal experience, it seems spaces are more common for folks with *nix background who tend to work in product-oriented companies (i.e. where code is an asset) and tabs are more common with windows folks, who tend to work on IT (i.e. where code is liability)
I'd like to add my own anecdote: Windows development primarily happens on one vendor's IDE - Microsoft Visual Studio, and where MS leads, Windows-based developer follow.
Case in point - I use the default Visual Studio settings which are spaces, BUT they weren't always. I remember as recently as 2008 tabs were the default.
I've mostly only ever worked in Windows environments with the odd linux machine here and there, but mostly Windows, I've worked in both I.T. and product-oriented shops. I've mostly favored spaces. I've never been questioned it or asked to do differently. Generally speaking, those that care about the money, don't give a fuck about whether I use tabs or spaces. I've worked in tight-ass shops that have nickeled and dimed for every cent savings and I've worked for shops flush with cash to pay developers to do it right.
In my actual experience, I've never seen any relation to tabs vs. spaces with regards to being paid more. Nobody that has ever paid me for what I do has cared about which I use, nor have they questioned it.
One thing I have noticed in programmers are an asset vs. programmers are a liability is that companies who understand that automation is going to extend their profitability by more of a margin than it costs them will pay you what you're worth. Those that view programming as a sunk cost, that just makes their lives easier or cuts costs will pay you what they can get away with.
Don't work for a company that views you as a cost centre. Work for a company that views you as a profit centre. The work will be more meaningful. You will be more fulfilled. You will most likely be less stressed and you will most certainly be appreciated and respected more.
If you're a software developer and you're part of the "IT" department, then you're a liability. Your code is a necessary evil.
If you're not part of the "IT" department, then you're working in a product-oriented environment where the company is selling your code (either as a good or as a service) or otherwise making money from the code. In that case, your code is an asset.
I've always understood it as functionality is an asset and code is a liability. The company wants and uses the functionality to make money. Code has to be maintained, has bugs, etc. Your goal should be to provide the required functionality while reducing the costs incurred by your code.
Most of the time I've seen people refer to code as a liability, they aren't referring to the 'cost-center' mentality, but rather recognizing code is the liability you incur in order to get the business value [1], and thus you should minimize the code you write per solved business problem.
You probably mean companies that are loaded or well-funded or stupidly rich. This isn't the same as fuck-you money, which refers to the amount of savings a person would need in order to retire early and thereby bid their employer goodbye. See for example: http://time.com/money/4187538/f-u-money-defined-how-much-cal...
"The model estimated that using spaces instead of tabs leads to a 8.6% higher salary".
So the model actually predicts causality, instead of correlation? That's amazing. I'll start using spaces instead of tabs today and I will ask for a 8.6% raise.
As a spaces user, I have to acknowledge that I get irritated when I open a document with tabs and the formatting is messed up thanks to tab setting mismatches.
Is it possible that tab-aversive people making hiring decisions act on their aversions (consciously or unconsciously), while tab-friendly hiring managers do not?
Can you explain that? I can't see how different tab settings would mess up formatting. Unless you use tabs to match the position of things over two different lines (which is abusing tabs), or mix spaces and tabs, tabs should work fine.
Interesting how multiple people presumed that older devs prefer spaces, which seems like the opposite to me. Tabs are a thing of the past, people used to use them a lot, and now they are relatively rarely used.
Older people use spaces. Older people make more money because they are further along in their career. Thus it only appears spaces make more than tabs, when it's really about age.
This is the third time I've noticed that people didn’t read the article closely enough to note that this explanation was explicitly rejected after the author controlled for years of experience and the effect was still present.
First thought: perhaps languages that officially recommend spaces (e.g. Python) predict higher salaries compared to those that recommend tabs (e.g. Go)?
I thought that too, but further down the article it seemed that wasn't the case.
I'd like to see the split of age vs tabs and spaces. I'm with a few other people that may say experienced programmers prefer spaces as it causes them less formatting issues over time when working in larger teams or on differing IDEs - and experience pays more.
This does not mean that changing from tabs to spaces will increase ones income.
I would expect there simply is a confounding factor that the author did not look at. Maybe the info is not in the data.
I can imagine that the space/tab choice is related to the "upbringing" of the developer. Maybe which language or editor they used first in their life.
Or maybe it's related to culture. For example when using IRC, tabs are usually not used to communicate. Maybe that impacts the general choice of tabs/spaces.
Or maybe more sophisticated users tend to exchange the tab key for something else:
This is already accounted for in the article, the data seems to indicate this even in the same language, and consistently does so across all languages.
The effect in the data (unless it isn't random fluctuation. At the moment I'd go with the assumtion that it is a genuine correlation, as the effect is present over all subgroups), might (1) not be monocausal, i.e. a combination of contributing factors like development experience, age of IDEs/tooling, etc. might play a role as well as other aspects. (2) a cause might not be "explained away" because the control variable was considered. Let me elaborate
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).
If you hit Tab in Notepad and hit save you get a file with tabs.
If you hit Tab in IntelliJ or a related IDE you get a file with spaces.
If you hit Tab in an older version of VS (the kind you'd expect in certain types of settings where high pay is not usually expected) you get tabs, but in newer versions you get spaces (with defaults)
But that just contributes to the gap, the kind of place that devotes time to things like shared editor configs is the kind of place with enough money (and interest) to contribute to development quality, and places like that probably pay more.
The average "sweatshop/devshop" developer probably doesn't even know/care about tabs vs spaces.
I set tab to call auto-indent or the language formatter on the code. I literally hit tab once to insert whatever is the defined standard for the file. So my single tab key press inserts or removes exactly the right amount of white space.
It's a holdover from my emacs days; the one thing I could not give up from emacs...
It may also hint at the years & depth of experience & skillset.
Those who grew up in a shell often ended up building a much more diverse set of skills, the commonality of which is a lot of text based files with a favourite editor.
This extended to using tools like IntelliJ, Eclipse, etc.
Hope a follow up of this study can include the IDE's and if that has some say in this.
Yes, but since it's a human situation, you can reverse the causality link. Imagine people use spaces for an underlying reason that gives them naturally a higher salary, like Harvard Legacy applicants are taught to use spaces, they don't become wealthy because they use spaces, but because their parents were wealthy. And wealthy people hire the kids of other wealthy people with big salaries. Clearly there is no space => big salary.
If you are not born in the nobility that uses spaces, but if at first contact the people in power see you using spaces they might assume you are born a noble, and lower their anti-commoner guard for you and you have a greater chance of entering the nobility without a proper title (don't forget to slam the door after you, nobility only works on exclusivity).
So there is a path for taking the implication completely backwards and still reaching the expected outcome.
It could work if the confounding factor is the one you described. But it would probably backfire if the confounding factor is which language you learned first.
Then forcing yourself to use spaces might reduce your productivity, your self-esteem and your mood.
The first place I would look is size of dataset and correlation effects from multiple self-reporters working for the same company.
Big companies tend to pay more in the software industry. Big companies also tend to have standardized on tabs or spaces internally to simplify the problem of merging code across developer teams. So if you find out that, hypothetically, Amazon, Microsoft, Google, and Facebook have all standardized internally on spaces, that alone could account for the data.
Tab is usually three spaces, right? So if I hit the tab key, I'm getting three button presses for the price of one. So extrapolating from that, if I hit tab I can get my work done three times faster and get out of the office quicker. If I'm using space, it takes me three times longer, which makes the boss think I'm working three times harder and I get a pay raise. I'm always at the office before she is (to fill in all the spaces) and I'm at the office after she leaves (still jamming that space bar). Sure the guy who uses tab ships code faster, but it must be worse code because he obviously rushed through it.
It looks good that I'm such a hard worker. So I get paid more.
A quality analysis, but you're neglecting the wear on your space key. Managers tend to look askance at wasting capex, so I'd recommend taking that in to account.
If I had to guess, developers who pay more attention to corner cases and/or carefully consider the secondary and tertiary effects of a design choice will tend to choose spaces.
- "TABS WORK GREAT FOR ME" -> First-order effect
- "If someone else views this file with a different tab width preference, the indenting will match their preference" -> Secondary effect
- "If users' preferences can change the indenting of a file, then vertically aligned elements will align or misalign depending on who's viewing it and who wrote it." -> Tertiary effect.
- "Randomly broken formatting and/or forcing users to constantly change their personal tab preferences is a bad way to work with code" -> Quaternery effect, etc.
In other words, a whole-system view that accounts for interactions with other decisions might lead you toward using spaces, while an immediate "local" view might lead you to choose the thing that seems most convenient right now.
This may or may not be true, but just FYI the salaries were an optional part of the survey so those people may have chosen not to give their salary for some reason or another.
I think the implementation is that those who are high earner don't have time/desire to participate in SO surveys, not that they are unlikely to state their income in SO surveys.
I've been using prettier.js in my JS projects for a few months and honestly I can't imagine going back to formatting my own code. It would be like making all of my own clothes or something. Who has time for that?
The Go community was on to something with gofmt (even if they did decide on tabs).
No, whitespace-sensitive languages are still generally the exception (except newlines). In fact I can't think of a new language that is vaguely popular and whitespace sensitive since Python. I guess there is YAML but that isn't a programming language and is also a bit mental.
Ok, here's a question I've been wanting to ask someone steeped in syntactic-whitespace languages. Do you find that two developers typing the same code will format it the same way? How much would an auto-formatter change in your team's code?
There has been a bit of friction on that very point...Now we just agree on "four spaces all over the place".
I know for a fact that an auto-formatter like `gofmt` or something would have avoided at least one argument, so it would probably would make the code better in some respects.
That said, I like the whitespace. I like that it forces you to think about how the code is formatted and it tends to make the code a lot less verbose.
689 comments
[ 2.2 ms ] story [ 304 ms ] thread(J.k.: spaces FTW)
Maybe I'm not up on my statistics lingo, but saying "using spaces instead of tabs leads to a higher salary" sounds much more causal than "using spaces instead of tabs is correlated with a higher salary."
If they're going to say something leads to something else, I don't see how that one's justified over the reverse: "having a higher salary leads to using spaces." Isn't that's just as valid a conclusion from the data?
Correlation still:
(a) implies causation (it's a necessary attribute of causation, just not a sufficient one).
(b) makes it statistically more probable for someone to be making more money than another, if they use spaces and the other doesn't
My personal guess would be that using spaces is a practical decision and might be more popular towards older, more experienced devs (who are therefore better paid).
On paper tabs sounds better, they're "configurable", you should indent with tabs and align with spaces, yada yada and everything is good in the world.
In practice however it becomes a big mess real quick unless you only work on projects with very good and perfectionist developers who understand when they should indent and when they should align and how they should configure their editors to do the right thing. See for instance the linux kernel codebase, it looks like arse if you don't use 8-space tabs and the coding style even tells you to use that value (it shouldn't really matter if tabs were used "right", except maybe for 80-column limits). So why even bother with tabs in this situation? Do we really care that much about wasting a few bytes?
Therefore I gave up on tabs a long time ago and tell everybody to just use spaces in all the projects I maintain.
Also some languages are "tab friendly" and there are correlations between language and salary; see previous HN posts on the topic.
They explicitly rejected this explanation after controlling for years of experience.
That being said I'd be curious to see "years of experience working in a team", because that's really when using tabs starts becoming tricky. If you're well disciplined and are the only person messing with your codebase the issues I mentioned in my previous post don't really apply.
If you know another variable that explains the difference please let us know.
Who do I contact for my check?
Sure, but how many spaces? grabs popcorn
Visually I can have it display in my editor of choice (Kakoune at the moment) however I want.
I guess I'm just saying, I would have thought the most common answer to this question would be: Whatever my employer / language standards dictate.
Imagine that half of those interviewed worked at Google.
Awyis I'll be rich in no time!
https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
[0]http://editorconfig.org/
Just oldsters cargo culting old kludges into the 21st century.
Or do some people actually use the space bar to indent code? (which is obviously insane)
I'm impartial to downvoting as to reply literally doesn't usually add to the conversation, which is generally the point of downvoting. Losing karma shouldn't hurt your feelings.
[1] https://en.wikipedia.org/wiki/Poe%27s_law
[1] https://news.ycombinator.com/item?id=14561801
https://en.wikipedia.org/wiki/Stigler%27s_law_of_eponymy
Agreed, this is why I didn't want to take a hard position on downvoting someone for missing the sarcasm. We're in a public forum which crosses cultural boundaries. I see the argument for both sides.
Although I lean more towards downvoting as the majority of people on HN will get the joke and it's an opportunity to learn for those unfamiliar with the mainstream culture.
they are publishing a very limited, informal, unscientific, survey and having fun drawing outlandish conclusions.
if you think this was serious in any way you may want to bring back pirates to counter global warming.
It's official: science proves that highly paid tab users just don't need it.
I'd also like to see an analysis of space-vs-tabs as it relates to operating systems. Again, from anecdotal experience, it seems spaces are more common for folks with *nix background who tend to work in product-oriented companies (i.e. where code is an asset) and tabs are more common with windows folks, who tend to work on IT (i.e. where code is liability)
Case in point - I use the default Visual Studio settings which are spaces, BUT they weren't always. I remember as recently as 2008 tabs were the default.
I've mostly only ever worked in Windows environments with the odd linux machine here and there, but mostly Windows, I've worked in both I.T. and product-oriented shops. I've mostly favored spaces. I've never been questioned it or asked to do differently. Generally speaking, those that care about the money, don't give a fuck about whether I use tabs or spaces. I've worked in tight-ass shops that have nickeled and dimed for every cent savings and I've worked for shops flush with cash to pay developers to do it right.
In my actual experience, I've never seen any relation to tabs vs. spaces with regards to being paid more. Nobody that has ever paid me for what I do has cared about which I use, nor have they questioned it.
One thing I have noticed in programmers are an asset vs. programmers are a liability is that companies who understand that automation is going to extend their profitability by more of a margin than it costs them will pay you what you're worth. Those that view programming as a sunk cost, that just makes their lives easier or cuts costs will pay you what they can get away with.
Don't work for a company that views you as a cost centre. Work for a company that views you as a profit centre. The work will be more meaningful. You will be more fulfilled. You will most likely be less stressed and you will most certainly be appreciated and respected more.
You got it backwards. In companies that sell code, code is an asset. In companies that sell services code is a necessary evil.
If you're a software developer and you're part of the "IT" department, then you're a liability. Your code is a necessary evil.
If you're not part of the "IT" department, then you're working in a product-oriented environment where the company is selling your code (either as a good or as a service) or otherwise making money from the code. In that case, your code is an asset.
[1]: https://twitter.com/tastapod/status/726747175317852160
So the model actually predicts causality, instead of correlation? That's amazing. I'll start using spaces instead of tabs today and I will ask for a 8.6% raise.
According to this model, I should get it!
Is it possible that tab-aversive people making hiring decisions act on their aversions (consciously or unconsciously), while tab-friendly hiring managers do not?
If a tree falls in the forest, etc
Just a guess.
I'd like to see the split of age vs tabs and spaces. I'm with a few other people that may say experienced programmers prefer spaces as it causes them less formatting issues over time when working in larger teams or on differing IDEs - and experience pays more.
I would expect there simply is a confounding factor that the author did not look at. Maybe the info is not in the data.
I can imagine that the space/tab choice is related to the "upbringing" of the developer. Maybe which language or editor they used first in their life.
Or maybe it's related to culture. For example when using IRC, tabs are usually not used to communicate. Maybe that impacts the general choice of tabs/spaces.
Or maybe more sophisticated users tend to exchange the tab key for something else:
https://xkcd.com/1806
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).
If you hit Tab in IntelliJ or a related IDE you get a file with spaces.
If you hit Tab in an older version of VS (the kind you'd expect in certain types of settings where high pay is not usually expected) you get tabs, but in newer versions you get spaces (with defaults)
In this case it is supposed to override your IDE settings.
The average "sweatshop/devshop" developer probably doesn't even know/care about tabs vs spaces.
It's a holdover from my emacs days; the one thing I could not give up from emacs...
Those who grew up in a shell often ended up building a much more diverse set of skills, the commonality of which is a lot of text based files with a favourite editor.
This extended to using tools like IntelliJ, Eclipse, etc.
Hope a follow up of this study can include the IDE's and if that has some say in this.
If you are not born in the nobility that uses spaces, but if at first contact the people in power see you using spaces they might assume you are born a noble, and lower their anti-commoner guard for you and you have a greater chance of entering the nobility without a proper title (don't forget to slam the door after you, nobility only works on exclusivity).
So there is a path for taking the implication completely backwards and still reaching the expected outcome.
Then forcing yourself to use spaces might reduce your productivity, your self-esteem and your mood.
Big companies tend to pay more in the software industry. Big companies also tend to have standardized on tabs or spaces internally to simplify the problem of merging code across developer teams. So if you find out that, hypothetically, Amazon, Microsoft, Google, and Facebook have all standardized internally on spaces, that alone could account for the data.
It looks good that I'm such a hard worker. So I get paid more.
- "TABS WORK GREAT FOR ME" -> First-order effect
- "If someone else views this file with a different tab width preference, the indenting will match their preference" -> Secondary effect
- "If users' preferences can change the indenting of a file, then vertically aligned elements will align or misalign depending on who's viewing it and who wrote it." -> Tertiary effect.
- "Randomly broken formatting and/or forcing users to constantly change their personal tab preferences is a bad way to work with code" -> Quaternery effect, etc.
In other words, a whole-system view that accounts for interactions with other decisions might lead you toward using spaces, while an immediate "local" view might lead you to choose the thing that seems most convenient right now.
The Go community was on to something with gofmt (even if they did decide on tabs).
I suppose that maybe none of the really popular languages follow this though...my bad.
I know for a fact that an auto-formatter like `gofmt` or something would have avoided at least one argument, so it would probably would make the code better in some respects.
That said, I like the whitespace. I like that it forces you to think about how the code is formatted and it tends to make the code a lot less verbose.