I didn’t realise it had been that long. Is there any interest in supporting this style in Ormolu?
That’s a great point! I hadn’t considered that. In our case we use persistent which generates names in the form of the latter. I’m not sure, but I think it could probably be configured to not prefix the field names with the name of the record. I think this wouldn’t work if you defined all your models in one module as is pretty common in smaller projects, but in a larger project where all persistent models are split into individual modules for better compilation performance anyway this might be viable.
Everywhere except local development. We used to include it in our local development setup also, but we found it too onerous.
After 15 years of coding or so, I’m confident in saying that style consistency is a waste of time.
I’ve worked on codebases without style consistency. It doesn’t make much of a difference, unless the programmer doesn’t know what they’re doing. Style is the least of your worries then.
And yet, the only thing worse than style consistency… is constant arguments about style. They don’t just waste a teams time, but their energy too.
Formatters are annoying, because they take away expressivity and usually just have bad taste (see ormolu), but it’s better than enforcing a complex style guide manually and having to keep all that stuff in your head.
Not trying to make blanket statements, but people overly focused on code tidiness, formatting and documentation are often struggling with understanding the actual code (and it may not be their fault at all) and see those things as a way to improve navigating code. But it usually doesn’t help much.
Navigating code is everything. And yet I rarely see us discuss it. It’s a bit harder to discuss indeed.
8 Likes
I broadly agree with your opinion here, but it depends somewhat on how strictly to interpret it. Do you think your opinion is at odds with the style guide in the article?
There’s lots of good things in the article.
This is why you need to use your eyes. The other programmers who work with the code you write will also be using their eyes.
Yes, aesthetics matter.
And yet, especially in open source, I don’t want to impose style. I embrace a bit of anarchy there.
I’m much more interested in the design choices. I only have so much mental energy per day.
If you closely work with a couple of core people, your styles will kind of converge to something unique anyway. That kind of tight collaboration is one of the few things in software engineering that’s enjoyable. But it’s very rare these days.
If a comment doesn’t help the reader understand something, then it’s noise, which means it’s making it harder for the reader to follow and understand the code.
Indeed. There’s a similar argument to be made about tests: if tests don’t make the code more maintainable, then maybe they’re not a good idea.
Avoid using names that are so generic they are near enough meaningless, like “helper”.
Absolutely. What I hate the most is names (e.g. for modules) like “Common” or “Utils”. Everything is “common”. What did you intend to do here? I also do that sometimes, unfortunately… and it almost always is a sign that I didn’t think hard enough about how to structure code… and just made it harder to navigate it.
3 Likes
I agree 100%. Style consistency can be nice, but it’s nothing more than that—people massively overrate the importance of consistent formatting because it’s so legible. It’s much easier to talk about concrete formatting rules than more nuanced aspects of code quality and design, but the latter matters far more.
There’s a small subset of style rules that I do think are important, like having consistent naming conventions. And none of these exceptions are handled by automatic formatters!
9 Likes
I actually like most of this style guide! Modulo some differences in indentation style, it’s basically the one I stick to as well.
1 Like