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

91–100 of 107 posts

Re: Alternative code styles

#91

Post by PurpleBoxDragon »

seanmcdirmid wrote: post #68
frou_dh wrote: post #24

Earlier quoted context omitted.

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.

Fixed with fonts work well when you are using the alt key to work with multiple lines of code at once. This is especially helpful in the middle ground where the lines of code are similar enough that one can easily use a pattern but the extent needed to be written with that pattern doesn't justify creating some tool to automate writing the code.

Re: Alternative code styles

#92

Post by britch »

deckard1 wrote: post #87
brixon wrote: post #38

Earlier quoted context omitted.

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

Linters save so much formatting time, I don't really see what it has to do with ego.

I certainly could go through and make sure all the spacing is exactly right, the functions/properties are in the right place, and rest of the rules of the styleguide are followed. But it's much easier to do when you get a warning, squiggly, or can use an autoformatter to match the rules.

I would never intentionally violate a rule, but I might forget a rule or miss a violation. With linters this is not an issue, the machine will let you know.

Everyone can focus on the correctness and quality of code and let the machine worry about making sure everything is formatted correctly.

Clearly the project you describe, where linting is disabled every other line is bad. But I wouldn't blame the linter for that. I don't know what can be done if a team has such a commitment to their own style that they put in the extra work to disable the linter.

A linter is not a tool for punishing people who violate a style guide, it's an assistant for people who are trying to follow a style guide.

Re: Alternative code styles

#93

Post by michaelmior »

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.

I don't have a problem with anything that discourages imports with side effects. You can always ignore[0] any cases where this happens.

[0] https://prettier.io/docs/en/ignore.html

Re: Alternative code styles

#94

Post by eberkund »

paulddraper wrote: post #78
jeremy_wiebe wrote: post #74

Earlier quoted context omitted.

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?

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

I don't know if it supports JavaScript but Resharper does this for .Net

Re: Alternative code styles

#95

Post by aequitas »

deckard1 wrote: post #89
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.

How code is styled doesn't distract from the main purpose to communicate intent. Most often humans are the ones mindlessly layering on the meaningless formatting/style on top of syntax and its then becomes the pivotal point of code reviews, burying the essence of the code.

I applaud companies like Google and Hashicorp for forcing formatting as compilation errors. As it lets you get on with the real tasks ahead.

Re: Alternative code styles

#96

Post by [deleted] »

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.

[deleted]

Re: Alternative code styles

#97

Post by oneeyedpigeon »

jeremy_wiebe wrote: post #79
keedon wrote: post #26

Earlier quoted context omitted.

I think it would help with clarity - too much nesting in a function can mean it's doing too much and might need splitting into several functions

One place where nesting makes things difficult is in error handling. If at each potential error point you best one level, you quickly find yourself deeply nested. I find the pattern of exiting early and having the “happy path” running to the end of the scope to make it much easier to comprehend a function (I’m sure there’s a term for this coding style but I can’t find the name of it at the moment).

I also find myself doing a similar thing in loops - 'continue'ing early instead of wrapping everything in conditionals.

Re: Alternative code styles

#98

Post by dvlsg »

paulddraper wrote: post #84
eropple wrote: post #82

Earlier quoted context omitted.

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.

Hopefully uncommon, anyways. Imports with side effects sounds like a nightmare to debug.

Re: Alternative code styles

#99

Post by reitanqild »

eberkund wrote: post #94
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

I don't know if it supports JavaScript but Resharper does this for .Net

I think all three major Java IDEs do this as well.

Re: Alternative code styles

#100

Post by andjd »

seanmcdirmid wrote: post #68
frou_dh wrote: post #24

Earlier quoted context omitted.

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.

I strongly prefer coding in normal fonts instead of typewriter fonts. This is the primary reason that tabs are better than spaces. Working with a proportional width font in a space-indented file is always trying.
Post reply on HN