
Alternative code styles - swalladge
https://swalladge.id.au/archives/2018/10/15/alternative-code-styles/
======
crehn
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.

~~~
frou_dh
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.

~~~
seanmcdirmid
Many programmers are still committed to manual formatting, or fixed width
fonts would have been obsolete already.

~~~
dxhdr
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.

~~~
seanmcdirmid
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.

------
vhb
Surprised nobody talks about the kdb codding style:
[https://github.com/KxSystems/kdb/blob/master/c/c/k.h](https://github.com/KxSystems/kdb/blob/master/c/c/k.h)

~~~
yiyus
That's Whitney's style. My preferred example is
[http://www.kparc.com/b/b.c](http://www.kparc.com/b/b.c)

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.

~~~
taneq
The problem with satire is that no matter how far over the line you think
you've gone, someone will always wonder whether you _really_ meant that.

------
dan-robertson
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 ->)

~~~
ulucs
neat, I think D has language level support for this too

~~~
chris_mc
That's basically uniform function call syntax. D and Nim use it and a few
others.

------
aequitas
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.

~~~
deckard1
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.

I'm not a fan of this cold, brave new world.

~~~
aequitas
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.

------
janlaureys
That Fibonacci based indentation might not be a bad idea after all. Especially
when doing callback-style javascript.

~~~
Sharlin
I'd prefer something like 3^n. Would really make you try to avoid needless
nesting.

~~~
z3t4
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.

~~~
seanhunter
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](https://en.wikipedia.org/wiki/Cyclomatic_complexity)

Agree with you that reducing nesting is not in and of itself beneficial.

~~~
dasmoth
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.

[1]
[https://en.wikipedia.org/wiki/Goodhart%27s_law](https://en.wikipedia.org/wiki/Goodhart%27s_law)

------
mmjaa
Putting every single item in this on my list of "reasons to kill a
motherfucker".

Seriously though, I find myself oddly attracted to the Python-braces style ..
if only I could use it without running afoul of my own list.

~~~
uryga
make your syntax highlighter show braces and semicolons in a faint color –
similar effect, better editability!

~~~
WorldMaker
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.

------
aasasd
I followed the link to the OOPS source code from the comments:
[http://people.idsia.ch/~juergen/oopscode.c](http://people.idsia.ch/~juergen/oopscode.c)
(originally from
[http://people.idsia.ch/~juergen/oops.html](http://people.idsia.ch/~juergen/oops.html))

Aaaand… “we're achieving levels of nerdery that shouldn't be possible.”

------
letientai299
> Poetry... quite eye-pleasing

I disagree with this comment. That style makes the code extremely hard to
follow, as there's no proper indention to identify scope.

~~~
saagarjha
Most of these examples are meant to be a joke, I’d assume.

~~~
swalladge
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. :)

------
inherentFloyd
This has to be satire. Most of these are terrible and I'm pretty sure the
fibonacci indentation originated on /g/.

~~~
sidlls
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.

------
jpfed
Kevlin Henney gave a talk (
[https://vimeo.com/97329157](https://vimeo.com/97329157) ) that included an
interesting idea for style:

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.

------
XorNot
Braceless Rust does look very nice. I wonder if a python style syntax is
possible?

~~~
steveklabnik
[https://github.com/mystor/slag](https://github.com/mystor/slag)

~~~
vlunkr
I appreciate the honesty of the readme

------
HiroshiSan
Wow! I've never heard of bournegol. That is really cool.

~~~
imglorp
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.

Yes, and it was uphill both ways.

------
runemadsen
oh god no stop.

