Hacker News Reader

Comment by nicoburns | Hacker News Reader

You can configure linters for VS Code and other editors. If it's just "what IntelliJ enables by default" then that's pretty subjective. I've seen some terrible code as a result of developers changing things just because their IDE decided the old code was smelly.

View on HN

The developers in the team do not change linting rules as they want. But I am not referring at small stuff, recent things for last weeks(maybe VS code does this by default or maybe you need 12 extra extensions that makes things much slower, let me know)

- I go to fix some issue and my IDE shows me that the code is copy-pasted in 3 places so I knew I have to extract a function, do some cleanup and fix all 3 affected places.

- bug appeared other a refactor, checking the code in the IDE I can see a red variable name, it was red because it was undefined(this is in JS code)

- sometimes when using soem inner function I would try to do something like "this.something" but the IDE notices it and warns me that in this scope "this" is soemthing else

I am also impressed that it can most of the time understands frameworks and libraries like angular or jQuery

None od those would pass CI

Really? Are CI tools parsing the code and will detect that this.something is not defined here? I am presently surprised so let me know what tool does this.

The same tool that your IDE is using underneath the hood

Do you know more? I am assuming the IDE has only one AST and uses custom tools and not running 10 different tools in background but my assumption could be wrong.

For IntelliJ-based IDEs this is broadly correct, though some languages may occasionally call out to third party tools.

Most cli tools can be easily integrated with continuous integration platforms like GitHub actions / Travis CI. See static analysis tools and code quality one's, in php these are Psalm, php-stan, php code sniffer and others. For JavaScript see ESLint with recommended rules from different companies, typescript with allow js turned on to analyse javascript code and other tools for statically checking css, html and more.

CI won't notify you the same second you finished writing the expression.

Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.

Of course, it sounds like there is no real testing or review before your team commits to master anyway, so there is your low-hanging fruit.

It is an old project, setting up a strict automated CI would just block us until we fix all warnings or disable them. With a good IDE you can spot the issue int the location you work, you say change most of the "var" to "let" and "const" but you can ignore the ones that are not related with the thing you are working on. With an automated thing you either fix all at once or you have to set ignore rules or write ignore statements int he code.

I would be interested to read more on how to add such a strict CI to an existing project.

I'm sure you could get the linting tool to run only on changed files (we have a pre-commit git hook that does this at work, although we have CI set up to run against the whole codebase). To be honest though, I think the best approach would to pick a few of the rules you consider to be the most important and just be suck it up and spend a couple of days fixing all the errors. It likely wouldn't take you long to make that time back.

Agreed, but for sure having a CI with parts of the rule won't be as good as having that and on top an IDE that has all the rules On and even more you can see the warning as you type not after you committed and submitted a PR.

Well sure, but text editors like VS Code and Sublime can do this too. You usually need to install a plugin but everybody I know who uses these editors installs the relevant plugins for the languages they use.

VS Code is particularly smart in that will pull in TypeScript definitions for libraries and use those for auto-completion even if you are not using TypeScript (and are using plain JavaScript).

JetBrains IDEs do all of that stuff and more in my experience. Visual Studio Code plugins are a pretty basic IDE experience compared to them

This is definitely true. The tradeoff being that JetBrains IDEs are much slower (particularly to startup), much more resource intensive, and of course more expensive.

Startup time is bad, yes, but I think it’s a reasonable trade off for the features I get and plus I tend to launch it once and then open files with the command line tools, which is basically instant. Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.

> Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.

I think this makes a big difference. I also have 16GB RAM and a fast SSD, but I'm on a 2-core MacBook processor. I find that with all of the various different projects I have to interact with in a day (I'm the tech lead at my company) I can't leave an IntelliJ-based IDE open without it slowing the rest of computer down to the point that it's impacting my productivity.

I bet VS Code will be as slow if it could have the same features.

Well probably. That's why people accept fewer features in return for the speed.

What % of your work day is spent starting up projects?

IntelliJ rocks but you’re seriously underestimating tools like SonarQube and CI pipelines. If you’re working in a crusty old system, you will be blown away by the kinds of things they uncover out of the gate. “Strict” CI is all relative, one option is baselining your project, which adds suppressions everywhere that has errors, allowing you to track new violations and fix the old ones as you go.

I recently spent a day configuring SonarQube rules for Java and I'm not particularly impressed. It does not reveal much more than standard Intellij code analysis.

Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.

If you have relatively modern code with reasonably good practices, sure. I ran it with the default rule set on a 15 year old C# codebase of about 150kloc and it found several quite serious vulnerabilities and a whole boatload of logic errors.

> Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.

…minutes, hours or sometimes even days after the code was written. Not every project can run its CI pipeline in seconds, incrementally, or on the developer’s system.

The advantage of any IDE is the “integrated” part. Linting is one thing, showing the results in a way that makes it as easy as possible to act on them is where an IDE beats a DE that does the linting in a “decoupled way”.

Did the conversation just go from "smaller is better" to "just use a CI pipeline to do the missing stuff"?

Every sufficiently complicated text editor and CI setup re-invents half of a good IDE, but worse.

These two do not conflict. It’s the Unix philosophy.

Reply on news.ycombinator.com