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

101–107 of 107 posts

Re: Alternative code styles

#101

Post by edflsafoiewq »

jeremy_wiebe wrote: post #74
emodendroket wrote: post #40

Earlier quoted context omitted.

There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.

I feel like Prettier does a really good job with JavaScript. What situations have you found where automated formatting doesn’t suffice or has these limits?

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.

Re: Alternative code styles

#102

Post by jeremy_wiebe »

chrisweekly wrote: post #83
jeremy_wiebe wrote: post #80

Earlier quoted context omitted.

Interesting, yeah, that’s definitely missing. ESLint has rules for ordering, feels like it’d be a relatively simple addition to prettier.

eslint and prettier are not mutually exclusive

I didn’t mean to imply that. In fact we use eslint + prettier where I work.

Re: Alternative code styles

#103

Post by swalladge »

inherentFloyd wrote: post #56

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

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.

Re: Alternative code styles

#104

Post by marvy »

GnarfGnarf wrote: post #69
gagege wrote: post #57

Earlier quoted context omitted.

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.

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?

EDIT: looks like the tool support is so bad, Horstmann himself pretty much gave up: http://horstmann.com/unblog/2010-06-28/braces.html

Re: Alternative code styles

#105

Post by nomel »

vhb wrote: post #14
swalladge wrote: post #11

Earlier quoted context omitted.

:O that is ... interesting. Sure that's not an entry for the ioccc? ;)

Nope :) This is being used everyday in production by most financial institutions. https://code.kx.com/wiki/Cookbook/InterfacingWithC 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.

It looks more like the guy that wrote this wanted good job security and pay, and ended up making and industry with good job security and pay.

Re: Alternative code styles

#106

Post by jungler »

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.

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.

Re: Alternative code styles

#107

Post by bryanrasmussen »

frou_dh wrote: post #24
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.

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