3 ms·
> Compilers do reject code that doesn't meet a certain standard. Yes, a bare minimum standard, which must be backwards compatible. What a compiler enforces is
by Manishearth 10y ago
> Compilers do reject code that doesn't meet a certain standard.
Yes, a bare minimum standard, which must be backwards compatible. What a compiler enforces is not best practice, it is bare minimum. Something enforcing best practice has to be allowed to be backwards incompatible, since newer better ways of doing things will always come up (that's how languages evolve), and you want to discourage the older stuff.
"I've never met a linter I liked more than a real compiler" -- it's not an either or situation, use a linter on top of the compiler.
- dahart 10y ago> What a compiler enforces is not best practice, it is bare minimum. -Wall gives you a lot more than bare minimum. But, you can't really call it bare minimum when you compare compilers to linters in general. If a compiler enforces bare minimum, then a linter enforces less than bare minimum. Linters in general do not detect type errors that compilers catch and that prevent the program from running. A compiler is a bigger, better safety net than a linter. I have ~25 years experience with many linters and many compilers, and my opinion is that compilers provide more security than linters, on the whole. When I can, I try to use a real compiler for production use of scripting languages, for example Google's closure compiler in JavaScript rather than linters like eslint or jslint. > it's not an either or situation, use a linter on top of the compiler. This is true, and I agree completely, it's not an either-or situation. That's in part what I was trying to say. The compiler already does linting and it does much better static analysis, so you don't need to choose, you can just use a compiler. There are certainly higher level style analyzers, clang-tidy was mentioned already, and there are others. PEP-8, and Rubocop are in part a set of guidelines designed to prevent code mistakes and type errors precisely because the languages they represent don't come with a static type-checking compiler. Many of the linting rules and best practices only exist to prevent unsafe code that would have been prevented if there was a compiler involved, and only need preventing via style guides and linters because a compiler is not necessarily there. There are certainly best social practices that some linters enforce that many compilers don't, but for that it doesn't make any sense to avoid learning C++. The OP's comment - that he feels like C++ is a minefield without a linter - is missing the forest. It is easier to know you're writing correct C++ than it is to know you're doing correct Python, because of C++'s compiler. Unfortunately no compilers or linters are that good at preventing you from writing code that runs and then crashes.
- Manishearth 10y ago> If a compiler enforces bare minimum, then a linter enforces less than bare minimum. I'm considering linters as something you use in addition to compilers. Yes, they enforce fewer checks, but the assumption when running a linter is that the code compiles, already. Or, at least, that's what the assumption should be. > This is true, and I agree completely, it's not an either-or situation. Ah, okay. Yeah my issue was mostly with the either-or framing here. > because the languages they represent don't come with a static type-checking compiler. Yes, but this thread is about C++, which is a different world.
- dahart 10y agoTrue true, and this sub-thread is specifically about someone who is afraid to use c++ due to lack of a linter. I've used c++ for the majority of my career, and all I really wanted to say to @codebeaker is don't be afraid to learn c++ for lack of a linter, because it comes with one. My mistake that I framed it in an argumentative way, that ultimately wasn't my intent.
- Manishearth 10y agoAh, I see :)