←back to thread

873 points belter | 6 comments | | HN request time: 1.94s | source | bottom
Show context
latexr ◴[] No.42947128[source]
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are

> (…)

> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.

What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth.

What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.

replies(64): >>42947180 #>>42947185 #>>42947187 #>>42947236 #>>42947241 #>>42947385 #>>42947445 #>>42947527 #>>42947549 #>>42947550 #>>42947776 #>>42947831 #>>42947871 #>>42948239 #>>42948415 #>>42948549 #>>42948597 #>>42948603 #>>42948816 #>>42948889 #>>42949006 #>>42949205 #>>42949721 #>>42949848 #>>42950103 #>>42950597 #>>42951017 #>>42951417 #>>42951446 #>>42951888 #>>42951983 #>>42952213 #>>42952396 #>>42952951 #>>42952983 #>>42953095 #>>42953185 #>>42953920 #>>42956368 #>>42956749 #>>42956933 #>>42957674 #>>42957827 #>>42958578 #>>42959426 #>>42959516 #>>42959604 #>>42959832 #>>42959898 #>>42960492 #>>42961062 #>>42961380 #>>42962073 #>>42962322 #>>42962379 #>>42962529 #>>42962821 #>>42963089 #>>42963205 #>>42963258 #>>42964858 #>>42964922 #>>42966606 #>>42974258 #
hliyan ◴[] No.42947527[source]
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.

I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.

replies(20): >>42947540 #>>42947576 #>>42947599 #>>42947739 #>>42947770 #>>42947773 #>>42948888 #>>42949256 #>>42949591 #>>42949745 #>>42951412 #>>42951450 #>>42952786 #>>42955720 #>>42956620 #>>42957839 #>>42958226 #>>42959595 #>>42961043 #>>42964637 #
Retric ◴[] No.42947599[source]
> the formatting and conventions of the blueprint

Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.

I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.

replies(8): >>42947699 #>>42948411 #>>42948818 #>>42949115 #>>42950567 #>>42951552 #>>42952254 #>>42961444 #
desdenova ◴[] No.42948411[source]
Fortunately nowadays formatting issues can be delegated to autoformatting in any popular language.

Some people still argue over autoformatter parameters, but then people will always find a bike shed to argue about.

replies(2): >>42949255 #>>42950758 #
1. noahjk ◴[] No.42949255[source]
Maybe a new paradigm for code formatting could be local-only. Your editor automatically formats files the way you like to see them, and then de-formats back to match the codebase when pushing, making your changes match the codebase style.
replies(4): >>42949766 #>>42949774 #>>42950418 #>>42954006 #
2. tele_ski ◴[] No.42949766[source]
It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.
replies(1): >>42962163 #
3. asdajksah2123 ◴[] No.42949774[source]
This is pretty common now. At least my Vim/git combo does this, where I always open source code with my preferred formatting but by the time it's pushed to the server it's changed to match the repo preferences.
4. ruined ◴[] No.42950418[source]
this works for pure formatting, but falls apart when you start linting to exclude certain syntax or patterns
5. withinboredom ◴[] No.42954006[source]
This is disastrously easy to implement with just a few filters on git (clean & smudge).

I highly recommend it though, especially if you worked for a long time at one company and are used to a specific way of writing code. Or if you like tabs instead of spaces...

6. maccard ◴[] No.42962163[source]
I’d like to think that GitHub would be able to display with my editor format settings.