I feel like my original post has just fallen out of context here. I literally opened with “the practical value is clear”.
garrison
sodapopcan
While I’m on team-formatter, the thing is they only enforce very, very minimal style (especially mix’s formatter). There are still a million different ways to much up style in a team setting that causes frustration beyond just “I don’t like this style.”
1
dimitarvp
I am with you but this is mostly Elixir-specific. It simply does not go far enough. Rust’s formatter is much more aggressive and I love it for that. (Though of course many don’t.)
My stance on formatters is: if you want to assist programmers then why don’t you go all the way? Why pull punches?
That’s why I like the Quokka formatter more. It’ll directly rewrite val |> do_stuff() to do_stuff(val). Frak your feelings, we have a team coding style and we deemed spending further time on this to be unproductive.
You can also configure it to sort keys in maps and struct definitions.
But yeah, my problem with Elixir’s default formatter is that it’s too meek. It should have more opinions and a handful of configurable knobs i.e. leave with that has whitespace alignment alone – it’s objectively easier to read that way.
1
tfwright
Definitely true, and the reason why team success often has a lot more to do with political/psychological dynamics than any technical issues, aesthetic or otherwise. It can seem sisyphean but it seems obvious to me that tools like credo help. Honestly have a hard time seeing another side to that in relation to a team setting.
Practically, one thing I’ve found really helpful is to try to get some consensus off the bat there is utility in drawing a line between style “preferences“ and “errors” even when it’s not pure from a theoretical pov. Then issues idenitfied as mere style go into a basket for potential credo rules, if we can’t get the computer to enforce it we just accept variation and ignore in PR reviews. Other things, like using some random acronym for a var, are legitimate targets for callouts even though they are also arguably only about readability.
1
dimitarvp
Let me know if I misunderstood you but this right here looks a bit pretentious. Or maybe you don’t work in teams and can afford this view?
While I have certainly found and used my own style towards a good amount of problems, it also has to be said that programming is mostly an objective science – one nobody can quite describe fully and formally just yet.
But let me not jump to assumptions. Can you give examples of artistic merit in programming? I am struggling with that.
To reiterate my stance, to me formatters are a fact of life, one I grew very fond of with time. I actually view this transition of mindset as a character development; letting go of something that looked like ego to me, so I can collaborate with people. I find it fascinating that it seems you’re going in the opposite direction. But I am certain I have misunderstood you and will appreciate elaboration.
1
jam
I agree with your thoughts on the rigid SQL and HTTP apps. Curious, what would you say would be a better or ideal way to build quality software? What has been forgotten?
0
garrison
For the record I think having a “coding style” is a great idea. And I would include many things in such a style guide that are impossible to lint because they require intelligence to make a judgement call as to whether something is in the spirit of the guide or not.
As an example, take a look at TigerBeetle’s style guide. There are some things on here that could be linted, but look at how many cannot be. There are literally entries labeled “this requires taste”!
0
tfwright
This wasn’t directed to me specifically, but I think physical architectural is a classic example no? When a building just has the right proportions, but also is made with high quality components, it blends into its environment amplifying natural beauty instead of destroying it. The opposite of a mcmansion.
I feel the same way when I’m reading good code, vs reading the software equivalent of a mcmansion. The names express the intent instead of making me squint, modules have a pleasant size where I can grasp the context but am not overwhelmed by details…etc
0
dimitarvp
I get the idea but I would be more interested in examples with code. I’ll start: I do my best to produce code that reads like English; like a story. Never have functions that are too long. Don’t mix concerns if you can help it. Isolate side effects to the maximum extent possible without resorting to various madnesses. Things like that.
But I would argue those are mostly quantifiable and don’t fall under “art”.
0