Live data from Hacker News

Alternative code styles

swalladge.id.au

51–60 of 107 posts

Re: Alternative code styles

#51
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.

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

Re: Alternative code styles

#52
post #48
post #9

Surprised nobody talks about the kdb codding style: https://github.com/KxSystems/kdb/blob/master/c/c/k.h

That's Whitney's style. My preferred example is 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.

> after spending a long time studying (and partly rewriting) this code, I actually find the terse version better.

I'm sure Mr. Goldberg understood his machines just fine, too.

Re: Alternative code styles

#55

Earlier quoted context omitted.

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.

I have my IDE do all the formatting every time I close something and rarely personally intervene.

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

Re: Alternative code styles

#57
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.

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?

Re: Alternative code styles

#59
post #5

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.

make your syntax highlighter show braces and semicolons in a faint color – similar effect, better editability!
Post reply on HN