3 ms·

> I've found with experience and heavy linting you can avoid the vast majority of bugs. No, you can't. In fact, I can't even begin to see how "apply this spec

by luord 8y ago

> I've found with experience and heavy linting you can avoid the vast majority of bugs. No, you can't. In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in configuration screws up your application at run time". You seem to be primarily a java developer so I understand why you prefer avoiding tests (among the many things that Java makes absurdly difficult, writing tests is one of them) but you should still write tests . Look at any serious open source project, most of them have hundreds, thousands of tests. It's almost presumptuous to think that one knows more than the community. > I swear it's like 95% bug reduction. The only situation where linting really causes that much of an impact, that I've seen, is in an application where a huge portion of the code was just connecting or boilerplate that should've been brought from third party libraries anyway, and was written only because of the NIH syndrome. Mind you, having code style is necessary so that any given developer can quickly get up to speed and more easily review other developer's code, but it doesn't (nor it shouldn't) tell you whether whatever you wrote actually works. Assuming otherwise is like pretending that a movie featuring state of the art special effects, cinematography, etc, isn't still Transformers or similar garbage.

spricket 8y ago
Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, and in my experience it catches mistakes constantly. For the average crud app, if you're wrong about the requirements the tests will be wrong anyways. It sounds like you're talking more about TDD which IMO is a cargo cult. And I'm hardly the only one with that opinion. Integration tests are important but that's more about running data through the code all at once than testing each function in isolation. Also, many open source projects get along with hardly any tests. The Linux kernel is probably the best example, but there's tons of popular projects without good or any tests. Check NPM popular repositories, I'll bet you more than half of the top 500 are under 10% code coverage. Tons of huge apps are doing fine without tests, and many I've worked on with tests are still horrible. I haven't really noticed any contribution from having lots of tests. IMO what's far more important is linting and maintaining code standards. It's hard to write a function that's horrible to debug when the linter limits you to 300 lines. Or a class that's totally incomprehensibly long when the linter limits you to 1000. All of my debugging nightmare projects have been due to lack of sound OOP principles, huge files of spaghetti. Good linting prevents that from happening. Besides Java my other big language is TypeScript. Using Mockito in java isn't that bad, and JUnit5 or TestNg are decent. Certainly easier than getting tests working in the garbage fire that is Angular6 + Jasmine + Karma.
- deleted 8y ago
  [deleted]

by luord 8y ago

spricket 8y ago

Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, and in my experience it catches mistakes constantly. For the average crud app, if you're wrong about the requirements the tests will be wrong anyways. It sounds like you're talking more about TDD which IMO is a cargo cult. And I'm hardly the only one with that opinion. Integration tests are important but that's more about running data through the code all at once than testing each function in isolation. Also, many open source projects get along with hardly any tests. The Linux kernel is probably the best example, but there's tons of popular projects without good or any tests. Check NPM popular repositories, I'll bet you more than half of the top 500 are under 10% code coverage. Tons of huge apps are doing fine without tests, and many I've worked on with tests are still horrible. I haven't really noticed any contribution from having lots of tests. IMO what's far more important is linting and maintaining code standards. It's hard to write a function that's horrible to debug when the linter limits you to 300 lines. Or a class that's totally incomprehensibly long when the linter limits you to 1000. All of my debugging nightmare projects have been due to lack of sound OOP principles, huge files of spaghetti. Good linting prevents that from happening. Besides Java my other big language is TypeScript. Using Mockito in java isn't that bad, and JUnit5 or TestNg are decent. Certainly easier than getting tests working in the garbage fire that is Angular6 + Jasmine + Karma.

deleted 8y ago
[deleted]