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

81–90 of 107 posts

Re: Alternative code styles

#81

Post by diegoperini »

dxhdr wrote: post #72
seanmcdirmid wrote: post #68

Earlier quoted context omitted.

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

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.

I don't know if variable width fonts are a help or a disaster but I've been using multiple fonts in a single editor window for quite a while and the productivity boost is huge. My choices are Operator Mono (to typeset keywords and math stuff) and Firecode (to typeset ligatures). You can find my custom Atom stylesheet here if you want to try.

PS: The idea is not mine but I can't remember where I read the instructions about this editor setup, so Google is your friend.

https://gist.githubusercontent.com/diegoperini/853d54c8873e7...

Re: Alternative code styles

#82

Post by eropple »

jeremy_wiebe wrote: post #80
paulddraper wrote: post #78

Earlier quoted context omitted.

Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949

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

In JavaScript, imports sometimes (too often, really) have side effects. I don't know if it makes sense for prettier to do that, at least by default.

Re: Alternative code styles

#83

Post by chrisweekly »

jeremy_wiebe wrote: post #80
paulddraper wrote: post #78

Earlier quoted context omitted.

Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949

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

Re: Alternative code styles

#84

Post by paulddraper »

eropple wrote: post #82
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.

In JavaScript, imports sometimes (too often, really) have side effects. I don't know if it makes sense for prettier to do that, at least by default.

In my experience, side-effecting imports are fairly uncommon.

But in any cases, all formatters allow you to selectively disable it for certain liners.

Re: Alternative code styles

#85

Post by paulddraper »

jeremy_wiebe wrote: post #80
paulddraper wrote: post #78

Earlier quoted context omitted.

Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949

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

> it’d be a relatively simple addition to prettier.

It would be, but as you can see in the linked issue, it was closed for being a non-goal. So, it's not likely to change.

(Prettier generally keeps the AST identical; i.e. whitespace and parentheses changes only.)

Re: Alternative code styles

#86

Post by seanmcdirmid »

dxhdr wrote: post #72
seanmcdirmid wrote: post #68

Earlier quoted context omitted.

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

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.

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.

Re: Alternative code styles

#87

Post by deckard1 »

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.

pet peeve #1 right here.

I really don't like the mandatory use of eslint (used as style enforcement), prettier, etc. When used as a bat to hit developers over the head, all this tells me is that the organization has too many anti-social developers that can't check their ego at the door.

Often someone will recommend a tool or technology in place of simple social common sense. If a developer can't follow the existing code style, they should be shunned. It's their problem. It's not a problem to solve with a fancy tool. You solve this particular problem by telling that person that they are an asshole. Using technology to solve social problems just exacerbates the problem.

All of that leads to a situation where we can't have nice things. You go into a codebase and see hundreds of exceptions to turn off eslint or whatever. Instead of just working around one-off style exceptions with common sense (who really gives a damn if a line needs broken/indented a certain way for a specific function) you have to plead with the style cops to let you off each and every time.

Developers really hate each other. Small organizations or teams tend to be a bit better in my experience. There is more camaraderie. But I often feel like I'm in a group of mercenaries, each ready to stab you in the back.

Re: Alternative code styles

#88

Post by seanmcdirmid »

nothrabannosir wrote: post #75
seanmcdirmid wrote: post #68

Earlier quoted context omitted.

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

Fixed width fonts are used for programming because of cargo culting. I tried programming in serif fonts only after a HN comment suggested it (would never have thought of it myself) and it's fantastic. Very readable. They were right. And you can still manually format code, serif or monospace. Proportional or monospace font choice is orthogonal to formatting. (Edited to be more specific)

I prefer a San serif myself.

Mono space allows you to do manual alignment, eg if you want ascii art in your code or non standard formatting. Doing this with a proportional font means other people can’t read your code without using the same font.

Re: Alternative code styles

#89

Post by deckard1 »

aequitas wrote: post #6

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.

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.

Re: Alternative code styles

#90

Post by seanmcdirmid »

arama471 wrote: post #73
seanmcdirmid wrote: post #68

Earlier quoted context omitted.

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

wait are you saying fixed width fonts are only useful for manual formatting? because I find they make it much easier to read code.

There is no evidence that fixed width fonts have any advantage. It seems to be a matter of just what you are used to.
Post reply on HN