Live data from Hacker News

Alternative code styles

swalladge.id.au

61–70 of 107 posts

Re: Alternative code styles

#61
post #13

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

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

Make it 1.3063778838630806904686144926...^(3^n), where 1.306... is Mill's constant. Then all your indents will be to prime columns.

Re: Alternative code styles

#63
post #21

Earlier quoted context omitted.

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 avoidin…

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 benefi…

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.

Re: Alternative code styles

#64

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 languag…

This operator is (&) in Haskell these days.

Re: Alternative code styles

#66

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

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.

Re: Alternative code styles

#67
post #21

Earlier quoted context omitted.

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 avoidin…

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 benefi…

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

Re: Alternative code styles

#68
post #24
post #20

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.

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

Re: Alternative code styles

#69
post #57

Earlier quoted context omitted.

Sign of an experienced architect. Read: "I'm old and too tired to argue, just don't break it ok."

I'm 32 and I feel like I'm already at that stage sometimes. What will I be like when I'm 50?

I'm 70, push out production code every day (Horstmann style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_st...), and I'm having the time of my life.
Post reply on HN