Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alternative code styles

swalladge.id.au

Post reply on HN
Print view View original

41–50 of 107 posts

Re: Alternative code styles

#41

Post by emodendroket »

brixon wrote: post #38
crehn wrote: 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.

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.

Unless the code you're working on combines different styles not only in the same project bet even in the same file.

Re: Alternative code styles

#42

Post by emodendroket »

hyperpape wrote: post #39
gdfasfklshg4 wrote: post #33

Earlier quoted context omitted.

Lint to personally preferred style on checkout. Lint to project style on checkin. Not a problem.

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.

Re: Alternative code styles

#44

Post by emodendroket »

z3t4 wrote: post #21
Sharlin wrote: post #13

Earlier quoted context omitted.

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

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…

Highly nested code is hard to understand.

Re: Alternative code styles

#45

Post by gohwell »

vhb wrote: post #9

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

that's just for writing c interfaces to kdb.

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.

Re: Alternative code styles

#46

Post by chris_mc »

_v7gu wrote: post #34
dan-robertson wrote: post #17

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…

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

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

Re: Alternative code styles

#47

Post by hyperpape »

emodendroket wrote: post #42
hyperpape wrote: post #39

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.

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.

Re: Alternative code styles

#48

Post by yiyus »

vhb wrote: 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.

Re: Alternative code styles

#49

Post by [deleted] »

yiyus wrote: post #48
vhb wrote: 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.

[deleted]

Re: Alternative code styles

#50

Post by taneq »

yiyus wrote: post #48
vhb wrote: 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.

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.
Post reply on HN