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.

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.

But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.

Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language.

If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have.

Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.

It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it.

We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier.

Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.

Code uses text, sometimes even natural-language prose, but isn't like "books and writing". It has to communicate knowledge, not feels. It also ultimately have to be precise enough to give unambiguous instructions to a machine.

In this sense, code is like mathematical proofs and like architectural blueprints, which is a different category to drawings, paintings and literature. One is about shared, objective, precise understanding of a problem. The other is about sharing subjective, emotional experiences; having the audience understand the work, much less everyone understand it the same way, is not required, usually not possible, and often undesirable.

The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following DO-178 would almost certainly be able to do something comparable.

It is going to be very industry dependent, where "industry" means aviation, or maritime, or railroad, or Healthcare, etc... Just "software" is too general to be meaningful these days.

Whoever drew your blueprints knew they would be needed beyond getting the house up. What would the equivalent perspective and effort for software engineering be?

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

With clang-format & co. on Save plus possibly a git hook this all went away. It might not always be perfect (which is subjective anyway) but its so worth it.

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...

If the code needs to be reformatted, this should be done in a separate commit. Fortunately, there are now structural/semantic diff tools available for some languages that can help if someone hasn't properly split their formatting and logic changes.

What we should have instead is syntax-aware diffs that can ignore meaningless changes like curly braces moving into another line or lines getting wrapped for reasons.

These diffs already exist (at least for some languages) but aren't yet integrated into the standard tools. For example, if you want a command line tool, you can use https://github.com/Wilfred/difftastic or if you are interested in a VS Code extension / GitHub App instead, you can give https://semanticdiff.com a try.

https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...

The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.

I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.

This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the <future> consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

> Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

Those are solutions to real problems. The real issue is the cargo cult, aka "Google is doing it, let's do it too". If you don't have the problem, don't adopt the solution (which always bring its own issues). It's always a balancing act as there is no silver bullet.

> "When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."

The same is true in software when a developer inherits a codebase.

Those signs of quality turn into longevity, even when they face away from the user.

This is incredibly important.

This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.

This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if it meets the requirements in functionality. You don't have time for that stuff, you are too busy trying to make this one person happy by turning an if else into a ternary and the end of sprint is a day away.

If/else vs ternaries is something where consistency is a lot less important, but if you know that a team member has a strong preference for one over the other and you think it's unimportant then you should just write it how they prefer to begin with. Fight over things you think are important, not things that you think don't matter.

I worked with a guy where you would try to predict what he would bitch about next. In this example, you would write it as a ternary so you don't have to hear about it ... and he'd suggest it be an if-else statement.

Nobody fucking cares which one it is; is it readable? That's the real question. Your preference of which version of "readable" it is only applies when you are the author. If you're that picky about it, write it yourself. That's what we eventually did to that guy after the team got sick of it. Anytime he'd complain about something like that, we would invite him to write a PR to our PR, otherwise, get over it. Then, we would merge our PR before he could finish.

He eventually got fired for no longer able to keep up with his work due to constantly opening refactor PR's to the dev branch.

Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me.

The example about if/else vs ? : is pretty damning though.

That is not to say I'm one of those people who need a specific code style to have their weird brain satisfied. But not using a linter/autoformatter at all [when available] in 2025 sounds like the opposite of "work smart, not hard"

Code style though, I do agree isn’t worth stressing about. I do think you may as well decide on a linter/style, just so it’s decided and you can give it minimal energy moving forward.

Maybe not at the same level, but code organization is also a design.

I don’t care that much about the exact linter rules applies (but I do prefer blue, hmm, nooo). But getting rid of merge conflicts that come from lake of common linter rules, this is a great pipeline process improvement, and this is some kind of code contribution pipeline design.

Did anyone claim otherwise? Besides, I imagine bridges aren't rebuilt every week -- poor blueprints can only cause a finite amount of pain.

I'd argue that code is more akin to a paper map than blueprint.

Imagine if Blueprint A used imperial units while others used metric units.

That's what inconsistent code style does to you.

Things I beleive:

- If you're picking up on code-style in PRs then your toolchain is backward.

- If you're changing linting rules every month then you're focussed on the wrong things

- It's better to have a consistent style than a perfect style

Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.

I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.

If you have five similar statements somewhere with only one exceeding the linter's line length, breaking up that one can lead to code that is harder to parse than just leaving it jutting out by way of an exception to the general rule; especially if it contains some predictable bit of code.

The general benefit of automated formatting outweighs these edge cases.

I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.

I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.

golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.

My point is that many things we end up doing manually can be automated, so I don't need to care about unsorted or unused imports at all and can rely on them to be fixed without my input, and I don't have to worry about a colleague forgetting to it either.

Also, gofmt not removing the breaking lines and handling groups inside themselves tell me that gofmt is aware of these choices already and accommodates this without being fussy or needing configuration about it, and it's an elegant approach.

Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?

Go is a programming language developed for teams. From its syntax to core library to language server to tooling, Go is made for teams, and to minimize thinking. It's opposite of Rust. It's devilishly simple, so you can't make mistakes most of the time.

Even the logo's expression is an homage to this.

So yes, Go's formatter should be this prescriptive. The other thing is, you can continue this conversation till the end of time, but you can't argue with the formatter. It'll always do its thing.

In other words, "computer says no".

Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It would be red, end of story. It doesn't matter if we like red or not, it just has to be. end of story.

Yes, the code looks awful. end of story.

One interesting thing that happened was the ability to guess who wrote what code purely based on coding style.

A healthy toolchain lets a developer separate the Craft from the minutiae.

The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.

[1] https://go-proverbs.github.io/

[1] https://en.wikipedia.org/wiki/Law_of_triviality

Authors totally obsess over details that seem irrelevant to people outside that craft.

There is nothing to support this in either writing or programming, at all. For every software craftsman out there obsessing over formatting, editor layout, linters, line length, there is an ancient, horrifyingly laid out C codebase that expertly runs and captures the essence of its domain, serves real traffic and makes real money.

Make your editor work how you like, but if my team lead started to get annoyed after my 4th formatting-only PR I should probably start to think about what I want them to bring up to my manager in my performance review.

I heard neal stephenson say that he writes using a pen rather than a wordprocessor specifically because it does affect the quality of the writing. Because he handwrites slower than he types, he does more thinking and editing in his head rather than after it's on paper.

I have no problem whatsoever with people having preferences, I just think people mistake preferences for proof.

I read https://prog21.dadgum.com/ somewhat regularly when I think I am getting to tool obsessed.

There is no way this is true. There;s 100% chance that no human is productive is uglified JS code.

That doesn't mean it's normal for them only use a certain typewriter because of its typeface, insist a publisher use Garamond to typeset their book for publication, or refuse to write without a certain margin.

To bring it closer to programming, in collaborative writing especially (think manual writing at large corporations), nobody is insisting that everyone indents paragraphs their way because it's better. As long as there's consistency those matters are best left to the printer. When I was younger I knew a lot of technical writers who in fact really disliked the move to Word from traditional word processors, because they didn't want to be distracted by those things.

They try to shoehorn it into being an engineering discipline and comparing it to authoring a book (something you can't give timelines on or T-Shirt size) probably horrifies them.

I’m so much more productive now.

And this ignores the collaborative writing many authors do to pay the bills: technical writing at large corporations, like bank manuals and such, or academic writing at universities. While consistency and standards are enforced, nobody's arguing that everyone else should really indent paragraphs their way, because that's the best way.

A better one would probably be accounting and spread sheets. Having common formatting conventions between spreadsheets (and code files) allows your brain to filter out the noise better. Obviously you can get too down in the weeds on "what are the best conventions" but the most important part is to have them and stick to them.

Not sure the typesetting analogy is the best, but typesetting absolutely matters for readability. Authors don’t need to care about it because typesetting is easy to change (before printing) and because publishers spend time caring about it —- all before it ends up in the hands of readers.

It is incredibly irritating if I need to reformat code to be able to read it clearly before modifying it, then have to either back out all of the formatting changes to create a clean PR that shows the actual change, or create a PR full of formatting changes with the actual logic change buried somewhere within.

I'm on team "agree at the beginning and then make it part of CI" and I basically never have to have this conversation more than once or twice per project now but I also think that the people most obsessed with it and dwell on it for their personal daily work are problematic, as are the people who hate any rules whatsoever and want to write complete shit code to just call the job done because "that's the important part".

For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.

If you don't already, you should run `cargo fmt --check` in CI and block PR merges until it passes. You can also run it in a pre-commit hook, but you can't be sure everyone will set that up.

Automating such types of decision is great but moot if others have to opt into it.

Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.

Sure, but there's two differences between artisans and programmers.

Firstly, most artisans produce sellable products. Once the customer has bought an item, they would never see it again. I'm pretty sure that if there was a minor error on a self-produced table or a vase and it was standing in the artisan's own living room, they'd not be able to unsee it, and still work to correct it.

Secondly and more importantly: code is not just the product that programmers work on, it's also the workshop that programmers work in. And you bet your ass that artisans are very anal about the layout and organization of their workshop. Put away screws in the wrong box, or throw all the dowels of multiple sizes in the same container? The carpenter will fire his apprentice if it happens more than once; place your knives in the wrong place in a kitchen and the chef will eat you alive; not properly wearing or storing safety equipment can be a fireable offense in many places.

To me, a code review is how you close your workshop for the week: tools are cleaned and stored, floors are tidy enough to walk around, and the work area is available so I can come back on monday and be productive again. I shouldn't have to spend monday cleaning glass shards because someone left a hammer standing straight up on a glass table - or chasing down last week's lunch because someone left the fridge open and now the cheese has grown legs.

So no -- making fuss about code style and quality can certainly be artisanal (maybe not about indents specifically, but can certainly be about textual organization). Because the code is the workshop, and you know the next time you will enter this room it will be because of a high-priority demand and you can't afford to spend half your day cleaning up what you couldn't be bothered to do last time.

Pick a style stick with it. Review it every 6 months to year to see if anything needs to be tweaked.

If you hear 'we are professionals' you are about to see code that has 20 different styles and design patterns.

I worked with one guy who could not make up his mind and changed the whole style guide about every 2-3 weeks. It royal made him mad the original style guide fit on a couple of postit notes. Me and two other engineers bashed it out in a 1-2 hour meeting at the start of the project (odd number of people to vote on anything). It came down to the fact he came in after the fact and had no say in it. Then proceeded to change everything. One week it was tabs everywhere then spaces then tabs again. One day camel case, week later all lower, another partial hungarian, upper on random things, etc. Waste of time.

Second best is to start a large cross company standards organization and only allow one representative per organization. Make sure there is a lot of process standing in the way of changes so that changes are only made when really justified (because most are not justified)

I care deeply about the end result that is presented to the user who has no idea what code even looks like. How we put together the UI. How we load data to minimize delays. That's "the craft" to me.

I care much less about code style, linting etc. that no-one other than a small group of developers will ever see. To a certain extent the latter enables the former. But I've often witnessed the latter being valued over the former and that's where things start to go wrong.

In our profession, our conventional approach to resolve these kinds of differences is to reduce them to a specific set of conditionally applied rules that everyone _has_ to agree on. Differences in opinions are treated as based on top of a more fundamental set of values that _have_ to be universal, modular, and distinct. Why do we do this? Because that's how we culturally approach problem-solving.

Most industries at large train and groom people to absorb structured value systems whose primary function is to promote productivity (as in, delivery of results). That value system, however, ultimately benefits capital most, not necessarily knowledge or completeness.

Roles and positions ultimately encompass and package a set of values and expectations. So, we are left with a small group of people who practiced valuing few other aspects but feel isolated and burdened with having to voluntarily take on additional work (because they really care about it), and others unnecessarily pressured to mass-adopt values and also burdened taking on what feels like additional work that only a small group of people like to care about.

In the cultural discourse, we are trying to fix minimum thresholds of some values and value systems and, correspondingly, their expectations. That is never going to be possible. In and of itself, that can be a valid ask. However, time and resources are limited, and values are a continuum. Fixing one requires compromising on another. This is where we are as a professional culture and community in the larger society today.

The Tech industry refuses to break down the role of a "software engineer/developer" further than what it is today and, consequently, refuses to further break down more complex/ambiguous values and value systems into simpler ones, thus reducing the compromises encompassed in and perceived by different sub-groups and increasing overall satisfaction of developers in the industry. Instead, we've expanded on what software developers should be responsible for, which has caused more and more people to burn out trying to meet a broader set of expectations and a diminished set of value systems with more compromises to accommodate that.

Ideally, we need an industry and a professional culture that allows for and respects niche values and acknowledges the necessity of more niche roles to focus on different parts of the larger craft of software development.

PS. As a side note, the phrasing of it in the article is unfair, which OC is pointing out too — there is a false equivalency drawn between "caring for the craft" and "stressing over minutia." This causes, in this context of having a discourse around the article, those who value and want to talk about the value of caring for the craft to be viewed and perceived as the insane weirdos who stress over the minutia that the author was referring to.

But surely naming convention contributes to keeping code documented, extensible and efficient?

A deviation from the norm leads to people thinking x does not exist in a large code base, leading to them implementing duplicate methods/functionality, leading to one instance evolving differently enough to cause subtle bugs but not enough to be distinct, or leading to one instance getting fixes the other does not etc?

Sample size of 1, but I've seen it happen unfortunately.

I have seen so many people going on and on about best practices and coding styles and whatnot and using big words just in hopes to keep discussions going so no one figures out out that they don't know how to code.

That is, I'd argue the "stressing" is not about what these tools check, but about the tools and their configuration itself. Just go with all the defaults and focus on bigger issues.

"This game sucks, would not recommend." - playtime 1.2h

Every language has automatic formatters. Use them, configure them if you don't like the default (in accordance with your team), and configure your editor so that is applied automatically when you save. And use CI to detect PRs with bad formatting so devs who don't have configured their editor yet can't break it.

Same with linters, you still have to agree with your co-workers about which rules make sense to be enforced, but with good editor integration you can see it right away and fix it as you code.

No. The two aspects (let's call them the craft and the minutiae) are orthogonal, they're not different level of caring about the same thing. I've seen people obsessed over minutiae and writing buggy, careless and unmaintainable code.

As with other formal aspects (e.g., testing) the quality of the code and the level of adherence to convention or forms are independent of each other; but they do both consume the same limited resource, which is the time and attention of developers.

The linter people are hypercorrectionalists of the type that would change “to boldly go where no man has gone before!” because it’s a split infinitive.

It’s kind of like what Bruce Lee said about punches. Before you know how to code, styling is just styling. When you become proficient in coding, styling is more than just styling. But when you’ve mastered coding, styling is just styling again. Be like water my friend.

Yup. Doesn't matter.

Code style should be consistent and look nice, probably use the default without too much nitpicking. You have bigger fish to fry

There are better things in life to worry about

"Craft", most code goes to irrelevancy in 5 yrs. And if it doesn't it's fixable (amen for AIs)

Try to sweat up every detail right off the bat and you go nowhere

Theses are bullet points expressing general rules of thumb, not legal treatises. You're reading far too much into these.

And I couldn't care less about where you put the {}. I love autoformatters.

Linting is a little more. It's both style and genuine issues, like don't == instead of === in JavaScript.

At least with Python I just push everyone to follow PEP-8 makes it easier.

Abhored obstructionists and covert saboteurs are also the ones that care for the details.

You need to care about right kind of details. Any specific linting is not that kind. Linting at all is.

Artisan without a proper sense could spend weeks exquisitely decorating a spoon with gaping hole in the middle. State of nearly all software is more or less horrible. Choosing the right linting rules is most often than not putting lipstick on a pig.

This may point to the dividing line. Software is required to be functional, not simply "artistic". You can certainly make the argument that there are non-functional considerations in its construction: readability, maintainability, extensibility, etc. And, these absolutely intersect with style, so it's tempting to apply words like "artistry".

But, is there a point where details veer into personal preference and insistence on style for the sake of style? I think so, and many of us have seen this. For those who haven't yet, stick around!

I cannot put it into words right, but you can see there’s usually a vibe. It will be different coming from an experienced developer knowing what they are talking about from lived experience, and from a clueless one who has seen shit but is hell bent on process and rules.

It’s like obsessing over the font on the packaging of the marker you use to write to the whiteboard in a math seminar.

Now, weird is beautiful but it’s not usefull and mostly irritating in a professinal context.

Cherish your weirdness and celebrate when you can find people of same persuasion. But don’t bother your colleagues with it.

I’m saying this as a person with very deep weird personal interests as several here do - and I’ve learned this slowly and painfully.

On your own projects, choose a style, go with it. On someone else's project, go with the style chosen. On a shared project, come up with a style, go with it.

Code _organization_ matters way more than code _style_. Where style refers only to the aesthetic choices that don't impact the structure or flow.

Until you open a file that has 10 different coding styles from 5 different developers. Just the variations of variable naming schemes alone in individual code files that I see/edit, would drive anyone crazy.

Yes, you need to care about this. But for the most part you should just follow the conventions of the language/framework, and not reinvent the wheel. Instead, you should put cycles into crafting architectures and algorithms.

At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.

Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.

I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter.

At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.

That's kind of my point: the end cannot see, or feel, minutiae. If they can, it's not minutiae.

> Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.

The code still isn't the product in that instance. It's the educational process. In many cases, clarity != beauty. This is why the best written tests often duplicate code, rather than being curated exercises in DRY.

> we aren’t paid to eat healthily and taking care of our bodies either

Yet programmers insist to be paid. Obviously taking time to grow on your own, on your own dime, is self-enriching for all the reasons you describe.

this is my biggest beef with linters. i break lines following typography rules and poetry, using the line break to help communicate. hate it when the linter takes away my thoughtfully chosen line break, because i broke it there to improve readability. i seem to be the only person in the world who cares about the line break of code. other style things idgaf but you can use typography and poetry rules to improve the readability of your code.

You have to read between the lines to pick that up though, so your criticism seems valid.

Sure, have a style and a linter. Be DRY. Don't lose your head over it though.

I can also understand the fuss better in indentation-is-structure languages like python.

> What you call “stressing over minutiae” others might call “caring for the craft”.

So what? The presence of disagreement is not an argument in favor of relativism and subjectivism. People can be wrong, and they can be wrong about what is valuable. Value is not subjective. The fact-value dichotomy is false.

That's the general principle. As far as this particular example is concerned, the author didn't say things like code style and linting rules have absolutely no value. They have some value. The question is how much, especially in the grand scheme of things, and whether one's concerns, attention, and efforts are proportioned to the objective value of such things. That's how this question should be framed. The author's position, charitably read, is that it is objectively irrational to obsess over such things.

If you wish to rebut, then go ahead and provide an argument, but don't retreat into the bollocks of subjectivism.

Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on.

If you don't see a difference between those groups, I don't think you understood author's points.

80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.

80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable.

200 is great.

And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me.

I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll.

People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourne 1 computer.

Now get off my lawn you punks!

I am.

And that's why I said I use the zoom in VSCode in my previous message. My font is big as fuck compared to everyone else.

If you can live with a single file on screen that's great, but the utility of two is far greater than having a chunk of the screen empty most of the time because of a few long lines.

...unless you really want to prove grandparent's point.

The choice for me is simple:

If I'm going to view the code I'm writing in a 80x24 terminal later on, I'll break that lines, and will try really hard to not get closer to 80 chars per line.

If that code is only going to be seen in Eclipse and only by me, I won't break that lines.

I omitted your other examples for brevity.

Having bigger screens doesn't make longer lines legit or valid. I may have anything between 4-9 terminals open on my 28" 2K screen anytime, and no, I don't want to see lines going from one side to another like spikes, even if I have written them.

When dealing with tabular data, particularly test data, I find most formatting lacking. I want to be able to specify blocks that align on the decimal point. Especially when dealing with lists of dicts. This makes reading test fixtures much more intuitive than default indentation styles.

Has anyone seen a formatter where you can specify a block be formatted in that manner?

  [{'a':  3.89, 'b':  10},
   {'a': 12.3,  'b': 233}]

  [{'a': 3.89,
    'b': 10},
   {'a': 12.3,
    'b': 233}]

Well yea, but which detail you care about still matters and reveals a lot about your "craft". Code style is of such little consequence compared to semantics it's always a little eyebrow-raising to see people who are extremely opinionated about it.

I've also noticed that this sort of thing can sort of fade into the background after a couple decades of coding. I know people who go on and on about how "beautiful" code is—to me it's just syntax serving a purpose. Sometimes you can make really elegant code that works well with the language, sometimes you can't. But how the code is presented impacts my reading comprehension very little unless you're doing something very strange (looking at you, early 90s c code with one-letter variable names and heavy macro usage).

Actually, I recant one element of this—Javascript and Typescript are just straight ugly and hard to read.

Function(vars) { ... } )

I would say, when to use one or the other of each of those options is very much a craft.

Someone's style can be "different" without being "bad", and you have two basic options to deal with it. One is to authoritatively remove the soul via process (auto-formatters, code review, and to a lesser degree linters, etc. are all designed to create uniformity at the cost of individuality.) The other is to suck it up and deal with it, as this is just an inevitability of creating a team size larger than one: people have different tastes and those have to be reconciled. I somewhat prefer allowing for individuality, and individuals should endeavor to match the style of whatever module they're working in, out of courtesy to its owners/stakeholders if nothing else. However I have only worked independently or on small teams. Most large teams (/ open source projects) have gone the former route of automating all the fun/craftsmanship out of their systems, and even I think that makes sense at a certain scale.

Someone's style can just be objectively "bad", however, and I usually find it's evidence they just don't care about the source artifact that much, and they're focused on the results. (It can also be a sign of an under-performer that spends so much mental capacity just getting the code to work that they have no spare cycles to spend thinking about matters of taste.) If it compiles / works / passes the test-suite that's "good enough" and "their job is done" and they move on to the next task. These people tend to be hyper-literal thinkers that are very micro-task oriented: they see implementing a new feature as a checklist to be conquered, rather than being systems-level thinkers on a journey of discovery & understanding.

If the author is talking about the latter, I have to agree with you that the latter are quite difficult for me to work with; particularly since I know that the source has to be maintained & supported over a much larger time-scale. The source-code is like your house, you live in it, being comfortable to work with/in/on it is the key to success. The deployed artifact may live for only a few weeks, days, or even hours before it gets replaced. The source has evolved over decades. You (the organization) are practically married to it. To further the analogy: I don't mind if somebody wants to hang posters in their room for a band I don't like. (Hell I can even handle if a group of those posters are tastefully hung out-of-level to make some kind of statement.) I do mind if their furniture is blocking a vent, the outlet covers are hanging off, there's a hole in one of the walls, a light has been burnt out for months, and the window-blinds over there are clearly broken but they insist it's fine because daylight still gets through.