Java has different codestyle, i.e. camelCase instead of snake_case, brackets shouldn't break the line, no space before param blocks after signature, etc.

Also explicit throws is so 2000s, nowadays it would be a better approach to return class that encapsulates (Result | Error)

https://github.com/brainflow-dev/brainflow/blob/4.3.2/java-p... fails to close that InputStream, which leaks file handles every time that method is invoked. Even the javadoc shows the correct usage of wrapping the InputStream in a try-with-resources block https://docs.oracle.com/javase/8/docs/api/java/nio/file/File...

The line right above that one fails to check the return type for file.delete() as that is a _request_ to delete the file and may not succeed for any number of reasons that might interest the code. If the file fails to delete, it can be retried, or one can use file.renameTo to try and move the _name_ out of the way, even if the on-disk allocation still remains. Of course, one should similarly check the result of file.renameTo as it is also a request

Swallowing exceptions is a pet peeve of mine https://github.com/brainflow-dev/brainflow/blob/4.3.2/java-p... because (among other things) it doesn't even acknowledge that an exception occurred in the error message right below it, meaning if one wished to debug _why_ that error occurred, now one must either use a debugger or recompile to include that information. The method similarly does not disclose that the result may be null, and NullPointerExceptions are my other pet peeve since unless running on a bleeding edge JVM, the error message is always "NullPointerException: null" meaning it says absolutely nothing about what it was trying to do when it fell over

Kind of related to that, the javadoc for some of the further down methods say "throws WhateverError" but not _why_ or what influence the caller has over that outcome

That's as far as I looked before closing the tab and wondering if I should mention the file handle leak, since if you only found the repo, then telling you wouldn't accomplish anything. But if it was your repo, then raising your awareness might be helpful

Then, yes, of course I agree with the sibling comments that the code style is very, very distracting, but there's no way I would have bothered to comment in HN about code style since to each his/her own so long as I don't have to work in it :-)

It could be through a plugin like sonarlint that helps spot common bugs etc. I'm not sure if there is a way to integrate that into vim. If there is I'd love to know how.

I've been using JetBrains products for a long time; I hear these tales of slowness but I've never seen it. Very odd.

Back in the day, (90's, for me), I heard the same about emacs. "It takes too long to start." My counter then is the same as it is now; I don't ever start it but once on reboots. It is never NOT up for me.

Oh, wow, those both are good ways to get me wound up :-) I'll do my best to avoid making this into an essay, and also try and avoid the burnout from having this exact conversation over and over and over and over and over and over and over and over in my career

For the first one (which actually is very closely related to the second one), PyCharm understands the files are python, and not text. That enables a few things: jump-to-declaration doesn't use pattern matching, which is fantastic in a codebase that has a bunch of methods named "to_json" or whatever. Find usages isn't "git grep and-good-luck". And, highest of all: PyCharm (and the JetBrains family of editors) have an indescribably good system of inspections and intentions. It's like having an angel on your shoulder spotting things it can prove are wrong. Similar to the sibling comment, people often "but flake8!11" and yeah, better than nothing, but offline inspection systems are nowhere near what I'm talking about. Then, the intention system ties closely into the refactoring system: extract variable finds the other 3 copy-pasta usages and extracts _those_ to a variable, too. Vim, and similar text editors do not have the context enough to know which ones are in scope enough to pull upward and be replaced

I know everyone and their cousin believes their code workflow is awesome, and good for them, so long as I don't have to work with their code or wait the 15 minutes while they manually enact a change that PyCharm would do instantly and correctly. So don't "at" me :-)

For the second, yes, I also deeply regret that JetBrains haven't spent as much time optimizing their IDEs as I would like. But for the aforementioned reasons, I get something for the frustration I endure waiting for that indexing stupidity to finish, or when it eats so much RAM I have to restart it.

And, as I hinted at: I strongly, strongly recommend to colleagues that they don't try to use IdeaVIM because of what I just tried to lay out: text is not code, and thus the primitives that one would use to describe operations done to text are at the wrong level of abstraction for things done to code

    def example():
        jimbo.doit(a, (alpha, beta, charlie))
        timmy.yup(b, (
            #<CURSOR>#
            alpha, beta, charlie
            ))

With ones cursor at the designated spot, pressing "expand selection" (alt-up in the macOS keyboard layout, command-w in the cross-platform one) 4 times will place the selection around that tuple, then command-shift-v will extract both of those tuple usages (after prompting, of course) to a variable awaiting its new name. command-z will undo that _one operation_ and undo the 3 changes to the text file because they were _one operation_. I believe those who say "but I'm a vim ninja, and I can do that same thing" but the amount of mental energy expended to calculate the sequence could be spent thinking about the problem and not the text.

I had almost this same discussion verbatim in the thread about SemGrep with folks because the _source_ is not _the AST_

Hmm, I didn't do a good job about avoiding the essay, and I could keep going literally the rest of the week on this topic, but hopefully that gives insight into the Sisyphusian task I have faced at almost every job my whole career