I thought it was so sweet that someone had thought of this very specific possible mistake and warned me about it to save me a little bit of time and trouble.
(Maybe not this exact one since it was in JS not Java I believe, but the same idea)
> The influx of AI-generated code, an ever-evolving threat landscape, and the push for shorter release cycles can jeopardize code quality. All of these factors dictate the need for continuous and accurate code analysis to help development teams spot and fix code issues early on so they can consistently deliver readable, maintainable and secure code.
You know, I read stuff like this and I wonder if anybody has thought maybe those things jeopardizing code quality should be discouraged as opposed to adding yet-another-tool.
Sadly, it's like outsourcing. People only learn once it comes back to bite them. It'll typically be in the form of a major security breach or the codebase becoming so painful to work in that it affects the business.
I mean, this isn't adding yet-another-tool. These inspections have existed for years inside of JetBrains IDEs. I feel like this is just an "encyclopedia of inspections." I don't see any other uses for it. They are just providing everything they are testing in the various tools they offer.
I think some free-for-open-source-projects licence or so would make sense here. Or maybe make this completely free? It's good advertisement for their IDEs.
This script generates exactly the same warnings as the IDE does.
It downloads some PyCharm Community version and installs it.
It uses the bin/inspect.sh tool which is provided by the IDE.
The IDE bin/inspect.sh needs an existing PyCharm project (all the XML files etc), so this script creates the project files automatically.
This also needs the Python stubs, so this script can create those as well, in the same way the IDE would create them, or alternatively it can download them (I created them in advance for some PyCharm versions).
But then, bin/inspect.sh does not generate all the warnings you see in the IDE. The IDE additionally runs pycodestyle, and so I do the same in the script.
So, as you see, it took a bit of effort to get to all that within the CI, but now it works and I get the same warnings as in the IDE.
It's a quite big project (maybe 100k-200k lines, not sure), takes about 10 minutes or less on the GitHub Action node I get, which is not so fast.
It's completely from scratch through the whole project, every time. Maybe I could do it more cleverly and cache the last state somehow and only check changes files or so. But I wanted to keep that logic simple.
PyCharm has saved me from so many stupid mistakes that would easily waste 15 minutes if I hadn't noticed them. I don't know how you could write high level code without an IDE.
You really can’t even begin to approach what the IntelliJ tools can do with a mere text editor. You’ll also spend more time tinkering with your Vim plugins than actually coding.
Neovim can be configured to practically become an IDE, complete with code analysis, refactoring tools, and AI assistants.
It'll also become as slow as an IDE, though. I think it's the Arch Linux (or maybe the Gentoo) of IDEs, where you have to know and configure every subcomponent of your IDE yourself.
I have tweaked my Neovim for small code snippets where a full IDE is overkill, but I can't be bothered to turn it into a full IDE like some others do.
And that's the USP of JetBrains IDEs. You don't have to spend days to configure your editor/IDE until it works for you. Just pick the right flavor for your favorite language and start working on your actual code.
IdeaVim has the usual Vim emulation problem. It does an okay job emulating baseline Vim, but it doesn't emulate your Vim setup, nor does it even try to integrate the rest of IntelliJ in a way that feels native (compared to something like evil-mode).
It's clearly not used by either its developers or the people who keep recommending it. It's the Microsoft POSIX Subsystem of text editors.
My IdeaVim setup is the default and most people just use the default. Obsessing over custom weird Vim configs is for junior devs who enjoy wasting time. I have been using it professionally for 10 years and it integrates well enough. All of the IDE shortcuts are available. No issues.
As I said I go back and forth between jetbrains products and vim and neovim.
As someone who crosses those boundaries I can tell you that you're dead wrong.
Im happy to sit down and write code in something like Goland. Im happy to pick pycharm to work on a LARGE python code base. But the moment that I need to deal with a JS spa, legacy code (python, ruby) and go im probably NOT going to pick intelij.
"tinkering with your vim plugins" is "tinkering with your Intellij plugins"... both involve search engines and RTFM, the former has more choice and a bit more downloading but the transition in either direction would amount to the same loss in productivity.
And I have played with VS code as well (and it too has its uses).
The only editor I dont like, is Emacs, and not because it is BAD but because you will spend more time tinkering with it than working.
> "tinkering with your vim plugins" is "tinkering with your Intellij plugins"... both involve search engines and RTFM, the former has more choice and a bit more downloading but the transition in either direction would amount to the same loss in productivity.
The OOTB setup for IntelliJ just works. The plugin with the bug you linked to is the "Rainbow Brackets" plugin. That is created by a third party and it is a useless toy plugin, not required for professional development.
Why would you be pissing around with that "rainbow brackets" nonsense instead of getting your work done with the OOTB setup that just works? Pointless and irrelevant.
I wonder what type of errors that are? My last experience with PyCharm was on an older 2014 ThinkPad on which it lagged too much, so I abandoned it. Could probably run it much better with my current laptop...
I just use VSCode for most things, or nvim if I want to edit something very specific that doesn't require much navigation between files. I'm not a huge fan of my editor annoying me with stuff all the time, but I'm wondering if I'm missing out.
Fun fact, not only that, since their support for "embedded languages" is second to none:
import re
if re.match(r'[aoeui', sys.argv[1]):
print('ok!')
is a red error in the ide because it understands regex syntax, and similar if it can either prove what the syntax is (based on its position, as seen in that re.match), or in all cases one can annotate the string literal to have it help you:
is similarly marked as red because that's not json
it's turtles all the way down:
# language=yaml
gitlab_yaml = """
stages:
- build
my build:
image: docker.io/library/busybox
after_cript:
# language=sh
- |
if true; then
echo "awesome"
fi
"""
spots the suspicious "after_cript" (in yellow, because it cannot prove it's wrong, just suspicious) and then it also highlights the embedded shell script in the embedded yaml string literal
Regrettably, it doesn't seem to run the shell validity checks on injected shell scripts, but I think that's a bug and not a limitation of the platform
Much easier to interpolate the hardcoded token rather than a string...despite the string being a final string and not some concatenation or dynamic value
Not really at all, the type checker understands it is a field reference (it's just an alternative syntax after all, it is absolutely 0% difference in behaviour.
However, it's a common typed-javascript idiom to use string-indexing when you're probing a value of unknown type. Even Typescript has settings to accept this.
I get it it's a nice idiom. But neither version is an error and the "correct" version is more verbose. Less verbose is better in my preference when it is just as clear or even clearer (because it is less verbose). And this is not TypeScript but JavaScript.
I guess my question is, how can I make the
ob.something
NOT be (listed as) an error? When is it not an error (according to WebStorm linter)?
I don't think "unresolved variable" is listed as an actual error in plain JS in WebStorm? At least by default.
In any case, like any inspection, you can adjust its severity to whatever you find appropriate, including "don't show it at all".
File > Settings > Editor > Inspections > Javascript and Typescript > General > Unresolved reference.
Or directly from the "Show Context Actions" action (Alt+enter or whatever you have it set to, the same combination that shows refactoring actions), you can navigate the inspection like a submenu and select "Edit inspection profile setting".
It is not an error true but it shows in the list with a yellow icon. But that means my list of "problems" is huge (because I prefer the shorter version of the expression). I would like the problems-list to be empty.
The problem is the long list often hides real errors in it. I would like to spot those more easily.
But I'll try your suggestions, maybe there's a way to make this warning disappear altogether from the list.
I still don't think, and don't understand, why it is a "problem" since the equivalent longer expression is not. It feels like WebStorm is mandating its own JavaScript-rules on me and my programming style.
All the Jetbrains IDEs have their own custom linter. It's pretty good, but my complaint has always been the inability to use it in CI/CD and to generate reports. The way I read this, they pulled their custom linter out of the IDEs and made it a standalone tool that can be added to CI/CD, which is great.
Intellij has some nice static analysis for Java.[1] But I want it in my face. Because we had a bug where we used `==` on a boxed primitive. And the inspection didn’t help because it was just sitting there with some faint yellow background or whatever it is if you happened to visit that file. And the light-bulb action thing is effectively active on any line since you get the option of “invert conditional” or “use block in lambda” and useless things like that.
Well I’ll just hedge and say that it wasn’t obvious to the three of us how to get an in-your-face warning.
[1] EDIT: I realize now that my brain for some reason thought that “in your face” would immediately translate to everybody else as “fail the build”. What a drunken (but not drunk though) mistake.
If I remember correctly, there is an extensive „Inspection“ settings page where you can enable / disable / set the levels (hoe much in-your/face) of exactly such checks.
You shouldn't rely on a human reading an in-their-face warning. If you consider a particular static analysis check to be vital, run it in CI and make the PR introducing it red. Everything else is just an upcoming post mortem with "we should have noticed this" waiting to happen to you.
> You shouldn't rely on a human reading an in-their-face warning. If you consider a particular static analysis check to be vital, run it in CI and make the PR introducing it red.
That’s what I meant (edited now). I want compilation to fail. Or whatever “CI” is.
We didn’t find a way to promote inspections to some kind of static analysis run.
I suspected that inspections would be tightly coupled to Jetbrain's IDEs (although I have no direct experience with them). There are probably equivalent static analysis tools available, but then you encounter the opposite problem of not having these errors available in your IDE, which is also not great for productivity.
You can change how inspection errors are shown under the Color Scheme settings. You can make it bold, striked out text with a bright red background if you want. I seem to remember at some point you could also make it blink, though I can't find that anymore (probably for the best).
https://www.jetbrains.com/help/inspectopedia/SuspiciousNameC...
I thought it was so sweet that someone had thought of this very specific possible mistake and warned me about it to save me a little bit of time and trouble.
(Maybe not this exact one since it was in JS not Java I believe, but the same idea)