Distinctive style is actually bad. You want your code to be uniform, readers should not be unable to tell who wrote what.
Otherwise you run into the danger of having parts that are peculiar and or obscure to everyone except the one who wrote them. That's if you are lucky, if you are unlucky the person who wrote them won't be able to decode them either.
Obviously there’s a line to draw somewhere so that your code doesn’t end up looking like a YouTube comment section or have half of its API with Spanish names. And if by style you mean that overly “clever” or dense code without detailed comments and formatting for readability ought to made digestible by those who lack context about the why/what of it, or that “dangerous” or unsafe practices like rust’s unsafe/python’s exec/C++ UB ought to be only permitted in exceptional situations, sure.
Everything else is so inconsequential that it truly pains me to see people spending hundreds or even thousands of dollars of their time having to indent, comment, or space things in a certain way just to get CI to pass or merge a PR.
I don’t give a fuck that Jeff wants to use 4-space tabs and I cannot tell you how much I resent spending tens of thousands of dollars of Google’s time pleasing the fucking Go linter or trying to figure out errors like “ERROR: const/var” that I can’t turn off because some master artisan truly finds it meaningful and important to make me declare const blocks before var blocks, and their OCPD and fulltime bikeshedding is more important than whatever actual work I’m trying to do to get them paid.
> Everything else is so inconsequential that it truly pains me to see people spending hundreds or even thousands of dollars of their time having to indent, comment, or space things in a certain way just to get CI to pass or merge a PR.
I generally agree with that sentiment, but the solution is to use automated formatting and lint fixing.
I as a mostly python developer have my gripe with mypy. The powers that be decided all code must pass mypy which means I have to spend hours of their money typing out trivially inferable types because myph can't infer the type of the empty dictionary I just defined when just two lines below I proceed to initialize it. Or it can't infer the return type of my function that returns true in half the return statements and false in the others.
If I wanted to write down types I would use another language. And if I didn't want duck typing I would write somekind of ML. In short I would never write out the types because that's compiler work. But nooooo All the cool kids use mypy and typescript so we have to as well.
You say that, but sufficiently advanced automated formatting and fixing can be its own kind of footgun. The unsung heroes behind making absolutely sure my code passed Go linting also enabled an automatic formatter that would constantly remove imports immediately after adding them, because they were now imported and not used.
However a normal person might actually handle auto formatting in their CICD still requires spending a decent amount of upfront time and ongoing maintenance on running scripts/containers that convert true tabs into 4-spaces tabs. Most of the time, anything that’s fully automatically formattable into something that passes linting is so trivially superficial like reordering or replacing or spacing out things, so if it’s necessary for anything more important than that I’d be questioning things.
I can actually see value in encouraging explicit types for most of the kind of stuff I work on, but I’d never choose Python for them to begin with because of that. LLMs make some of this stuff a lot easier to handle in one shot, but the ceremony and constant implication that you can’t be trusted to good work without being forced to wear a monkey backpack with a leash just wear you down when you run into them consistently over long periods of time.
Simplicity is the most underrated attribute of a well-designed system.
There is a tendency for smart people to want to build complex solutions when often, the best solution is one that simple.
We had a dev recently write a whole source generation library to verify configuration at application startup. I pointed out that it would only save -- at most -- 14ms over a reflection based approach and that our application at startup is rolling over nodes in K8s and not a serverless function where cold starts matter.
I'm kind of confused by your post, as if you didn't read your parent poster at all and wanted to use the chance to write a lecture about CS101 concepts. Can you explain how your uniform code argument fits in at all with their example of introducing multiple other system components in a PR because they lacked the knowledge to add it in the correct area? Every piece of code they brought to that PR could have followed a uniform standard and still be considered a failure at understanding proper system architecture for their app, which is the discussion everyone else is actually having.
Within a module, yes. But it's ok for one module to be different from another because, you know, they are different modules that do different things (the difficult part is deciding what level your modules are split at, of course).
Otherwise you run into the danger of having parts that are peculiar and or obscure to everyone except the one who wrote them. That's if you are lucky, if you are unlucky the person who wrote them won't be able to decode them either.