> One of my pet peeves about programming languages is that they don't go > far enough in mandating a particular coding style.
I remember your blog post. I have to say I don't much agree. Here are my concerns: - Lint tools are a fine way for any group to enforce its preferred style. (Our compiler is designed to be modular and shared as a library, so we will make it pretty convenient to write lint tools. We could even provide hooks to allow the compiler to integrate a user-provided lint tool into the compiler pipeline. All of this would be fine with me.) - In my experience, different styles between projects don't really distract much. You get used to the style used there, and everyone's a grown-up and understands they stick with the style of that group, even if it's not their preferred style. - There are always stylistic things to disagree about. We can nail down some and people will still find other minutiae to disagree about. - I think there's as much danger of compiler pettiness wasting developers' time as arguments about style do. - There's a real danger of alienating our potential users by being too petty. And perhaps my biggest objection: - *Compilers* that are obnoxious about dotting every i and crossing every t are a very different thing from *tools* that enforce style. Running a lint tool, or tying a lint tool to a build process, or to a check-in process -- those things all make perfect sense to me. But yelling at me for indentation when I'm trying to hack? That sounds like a recipe for getting in the programmer's way for questionable gain. Restrictions need to have clear payoff. I just don't see this experiment as worthwhile when we have so many important problems to work on. Dave _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
