Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.
Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind.
I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.
I worked at a place recently where someone (who left before me) argued seriously that automated syntax fixing shouldn't be brought into the millions of lines multi-project codebase with approximately a dozen developers with a 40% retention rate over any two year period because it would encourage bad habits by not properly punishing people for being bad.
Humans format with rules that take into account semantic information, symmetry, and aesthetics. They know that a function call that gives the entries of a matrix is formatted as a grid for a reason even when the auto-formatter could fit it on one line. They know that that arm of the match that would be formatted weird if it were on its own is actually formatted well because it exhibits that case's consistency with the other cases in the match. Probably the most important formatting decision they make is to, rather than format a long line, break it into intermediate results and store them in local variables given human-meaningful names.
Fixed width fonts let you quickly parse syntax. Syntax and semantics are equally important when reading code, whereas semantics are generally the only thing you need for understanding the written language.
That said, I haven't seriously tried programming using variable width fonts; maybe it's a well-kept secret to digesting code. Or maybe it's like Hemp Milk, there's a reason it hasn't caught on.
There is actually no evidence for that. Programmers in general seem to be faster with whatever they are used to. I personally have trouble parsing code in fixed width fonts versus proportional ones* because I’m used to the latter and the kerning of fixed width formatting annoys me. Keywords pop out easily with syntax highlighting in any case, making syntax pretty obvious.
* to be fair, I’d have trouble with a bad proportional font like Times New Roman, but I’m sure many would have trouble with Courier New on the other side, the specific font matters.
I don't know if variable width fonts are a help or a disaster but I've been using multiple fonts in a single editor window for quite a while and the productivity boost is huge. My choices are Operator Mono (to typeset keywords and math stuff) and Firecode (to typeset ligatures). You can find my custom Atom stylesheet here if you want to try.
PS: The idea is not mine but I can't remember where I read the instructions about this editor setup, so Google is your friend.
Fixed with fonts work well when you are using the alt key to work with multiple lines of code at once. This is especially helpful in the middle ground where the lines of code are similar enough that one can easily use a pattern but the extent needed to be written with that pattern doesn't justify creating some tool to automate writing the code.
I strongly prefer coding in normal fonts instead of typewriter fonts. This is the primary reason that tabs are better than spaces. Working with a proportional width font in a space-indented file is always trying.
Fixed width fonts are used for programming because of cargo culting. I tried programming in serif fonts only after a HN comment suggested it (would never have thought of it myself) and it's fantastic. Very readable. They were right.
And you can still manually format code, serif or monospace.
Proportional or monospace font choice is orthogonal to formatting.
Mono space allows you to do manual alignment, eg if you want ascii art in your code or non standard formatting. Doing this with a proportional font means other people can’t read your code without using the same font.
Horstmann style looks like my ideal, but there's very little tool support for it, from what I've seen. For instance, if I want to swap the first two lines of an "if" statement, I can't use "line-based" copy/paste. Do you do things manually, or does your editor support it fairly well?
Consistency is key. Follow the style that the code already uses. For new apps, I make sure the team has the same style template and use the editor to format the page.
At the end of the day, it is important that the code looks like it was written by one consistent person and not 20 random different people.
I really don't like the mandatory use of eslint (used as style enforcement), prettier, etc. When used as a bat to hit developers over the head, all this tells me is that the organization has too many anti-social developers that can't check their ego at the door.
Often someone will recommend a tool or technology in place of simple social common sense. If a developer can't follow the existing code style, they should be shunned. It's their problem. It's not a problem to solve with a fancy tool. You solve this particular problem by telling that person that they are an asshole. Using technology to solve social problems just exacerbates the problem.
All of that leads to a situation where we can't have nice things. You go into a codebase and see hundreds of exceptions to turn off eslint or whatever. Instead of just working around one-off style exceptions with common sense (who really gives a damn if a line needs broken/indented a certain way for a specific function) you have to plead with the style cops to let you off each and every time.
Developers really hate each other. Small organizations or teams tend to be a bit better in my experience. There is more camaraderie. But I often feel like I'm in a group of mercenaries, each ready to stab you in the back.
Linters save so much formatting time, I don't really see what it has to do with ego.
I certainly could go through and make sure all the spacing is exactly right, the functions/properties are in the right place, and rest of the rules of the styleguide are followed. But it's much easier to do when you get a warning, squiggly, or can use an autoformatter to match the rules.
I would never intentionally violate a rule, but I might forget a rule or miss a violation. With linters this is not an issue, the machine will let you know.
Everyone can focus on the correctness and quality of code and let the machine worry about making sure everything is formatted correctly.
Clearly the project you describe, where linting is disabled every other line is bad. But I wouldn't blame the linter for that. I don't know what can be done if a team has such a commitment to their own style that they put in the extra work to disable the linter.
A linter is not a tool for punishing people who violate a style guide, it's an assistant for people who are trying to follow a style guide.
Do you actually do this? From what I hear (and this makes sense from what I know about formatting/parsing algorithms) it's a huge pain, and not implemented for many languages.
That's easyish: it's a one-way street. The OP imagined something where everyone checks out code in whatever state it's in, applies their own system, then transforms it back, with no artifacts. That's hard.
Same here, with a twist: the test suite does: global reformat (uncrustify or astyle, depending on the team), build, run the actual tests.
As people almost always run the test suite before checking code in, all the project stays properly formatted.
My experience is: each time a team started doing this, all coding-style related discussions vanished, and it became a non-issue.
It turns out it's a lot easier to accept a coding style you're not the one doing the actual formatting (this is why, BTW, I think stylechecking hooks alone are a bad idea).
It looks obfuscated, but in fact it is just a lot of information. Many people would claim dividing it in 10 files with longer function names and less tricks would make it easier to understand, but after spending a long time studying (and partly rewriting) this code, I actually find the terse version better.
I've tried Whitney's style and got some good takeaways from it. I don't need that level of density, but it made me realize that when the code is already doing something very abstracted from business logic, there is no sense in trying to name the variables with more than one or two letters. (x0 and x1, appearing in geometric functions, are favorites of mine.)
I also started using "result" after seeing it in Pascal code and have quite liked it for many years, but I just had the epiphany that "ans" (answer, as seen on several graphing calculator lines) would be a little more dense.
Basically, it was well worth it to try these radical styles out. They did a lot to smooth my everyday coding.
I've been told that the guy who wrote this believe that the brain only has a limited buffer to compute source code. So he is trying to use the shortest code possible everywhere.
As someone who writes q all day, it's typical to see functions written in one line and no white spaces. The mantra is, if it takes you more than 1 line you're probably doing it wrong.
The only style there that is actually used by a person is the Bourne style. There are other styles that people develop for themselves, for example there was some Haskell program posted to a mailing list with a warning about personal style. This defines:
(.) :: a -> (a -> b) -> b
x.f = f x
And then the author can write e.g.
x.length
Instead of
length x
I think this is really quite a natural operator (and other languages support it, eg in F# it is pronounced |> and closure has something like it with ->)
The best coding styles are the ones that allow to be translated back and forth to another style.
It doesn't matter which style you prefer. As long as a computer can pick it up and translate it into the project standard style and back to yours again. You can simply setup git filters and live in you own style world.
Using git filters is a great idea! I've heard of this for translating between unix and dos line endings in git, but hadn't thought about using it for entire styles. There are heaps of automatic code formatting tools becoming more popular these days too.
Code is meant to be read first and foremost by humans.
As such, code should be written for clarity and presentation. To communicate intent. Automated tools destroy this human/code connection. They reduce your coworkers to simple cogs in a machine, rather than authors and communicators.
How code is styled doesn't distract from the main purpose to communicate intent. Most often humans are the ones mindlessly layering on the meaningless formatting/style on top of syntax and its then becomes the pivotal point of code reviews, burying the essence of the code.
I applaud companies like Google and Hashicorp for forcing formatting as compilation errors. As it lets you get on with the real tasks ahead.
I think something simpler like (n)(n+1)/2 is better.
This means that the difference between the n-th and (n+1)-th indentation level is n spaces (barring of by one errors I made).
We still get a curving indentation, and we are still warned against nesting, but the indentation doesn't explode exponentially.
Why should I avoid needless nesting ? Is there any other reason besides the holy 80 character limit !? Nesting can for example be used to limit variable scope and make use of closures, or to avoid creating more code paths, or just make the code more readable. You can however often break some code down to named functions and it will be easier to read, with the added benefit of less nesting. But I don't see how avoiding nesting is a good rule by it's own.
You've given some good examples of nesting which don't introduce branches, but most nesting does and therefore, nesting is an approximation for the cyclomatic complexity of a piece of code. Reducing this complexity helps with testability and (moreso) with the ability of humans to understand the code https://en.wikipedia.org/wiki/Cyclomatic_complexity
Agree with you that reducing nesting is not in and of itself beneficial.
Cyclomatic complexity seems like a great example of Goodhart's Law [1]. I absolutely agree that on the whole, code with fewer paths tends to be easier to read. However, taking deeply nested code and arbitrarily pulling chunks of it out into functions which only have a single caller and don't really abstract anything that's ever going to be terribly meaningful on its own seldom makes it better in my experience -- and can force a lot of skipping around if you're actually trying to understand what the system as a whole is trying to do.
If you punish nesting a smart developer might use imaginable horror (with the same or worse complexity) to keep the code flattened. Nesting makes the complexity apparent.
One place where nesting makes things difficult is in error handling.
If at each potential error point you best one level, you quickly find yourself deeply nested.
I find the pattern of exiting early and having the “happy path” running to the end of the scope to make it much easier to comprehend a function (I’m sure there’s a term for this coding style but I can’t find the name of it at the moment).
Or just use Python or other languages that require fewer braces/semicolons in the first place? We have so many options now, we don't have to deal with the tyranny of overly precisely punctuated languages if we don't want.
'eye-pleasing' is a subjective thing here and doesn't have much to do with functionality/readability (on the contrary, which is why you posted your comment). I think I understand what the OP means: that code sample, when looked at as an art form and not as code, indeed can be considered eye-pleasing by some because of the symmetry etc. For that aspect whether the code is readable has nothing to do with it.
Yes, the whole article is semi tongue-in-cheek. I tried to bring it back to reality by mentioning my appreciation for the creativity of people who designed the styles. :)
Probably I've taken this so serious since the article mentioned Bourne Shell code, which is a real project, and the Fibonacci indent style is actually nice.
I love the Fibonacci indentation. Deeply nested code then looks like the gravity well in a black hole, drawing a direct and clear analogy to where readability and understanding are headed.
Yes, satire and some examples of programmer creativity. I hope none of these styles are used in production code, but they are all definitely styles that someone has used for something. Even if just for fun.
Imagine every non-whitespace character in your code were replaced with garbage. Indent so that the reader could still understand the structure of your code.
Sadly I have been asked to use it. Horror story time.
First job out of school, I joined a place with a lot of EE's writing VHDL tools.
So EE's--no offense--at that time viewed software as a solved problem if you did everything by a book (any book) and a spec and a waterfall.
So despite working in C, which was already plenty idiomatic with a fine K&R standard, they insisted that while(p-- = p--) was verboten and instead made a bunch of FOOL/LOOP, WHILE/ELIHW, IF/FI and other abhorrences to hide the idioms they didn't like (such as braces) and make it more like algol/pascal. This was all less important than actual CS principals.
Then to make matters worse, there was a SPEC, a binder full of PAPER pseudocode mostly in algolish, some hand written. But every piece of code needed to refer back to its spec. Of course those things got out of spec quickly so any new feature was always about triple work.
