IntelliJ IDEA team notes

I have been a small-team lead trying to help new members adopt an IDEA and, in some cases, a language (Java) they have little experience in. These are random notes to that effect.

IntelliJ IDEA tip of the day: File → Invalidate Caches/Restart...

This is used when a) stuff is just inexplicably going from bad to worse for you (in editing, running unit tests, etc.) and b) when you're tired of seeing old editor tabs pop up on files that no longer interest you.

There's a edit order queue that you can navigate via the left and right arrows toward the left of the toolbar. It works like a breadcrumb menu to take you back to where you were (especially nice when debugging). But, if you're through with some file, you don't want to keep it popping back up when you click the left arrow a few times.

A lot of this annoyance depends on working habits.

Asterisks in Java imports...

Never, ever permit the use of an asterisk in an import statement.

The reason you should never permit that is because it obscures where a class is coming from. It's too facile. It mocks the reader of your code because they have to do extra work to figure out where you got the class from. If you have many asterisks in import statement, that becomes practically impossible. Don't do it, please. There is a setting in IDEA to block that. Go to Settings... → Editor → Code Style → Java and set Class count to use import with * and Names count to use static import with * to 999. This will keep IntelliJ from doing it; you'll have to avoid doing it yourself.

The green check-mark in IntelliJ IDEA's Java editor...

Your code-writing, changes-making editing task isn't done until the only thing (in this image, which is of the upper right-hand corner of the IntelliJ IDEA editor) is a green check-mark.

Anything else up there is a warning (or a red error—not shown here) that must be understood and fixed.

If you click on the yellow warning or on the red error, you will see what's in the image below; a list. There are (obviously) really bad things (errors), somewhat bad things (warnings that betray errors), and so-so things like warnings about unused imports, mispelled words, etc. Below, I will deal with each of these... ...except errors. I don't think you need me to talk about that. You can't even run JUnit tests if there are errors (unless you stand on your head to tell the IDE that you insist on doing it).

Warnings that betray errors are subtle. They're warnings, they say something that you can ignore and it will still compile, but the code may not behave the way you thought it would and you will get a) a runtime error or b) bad logic during execution that might torpedo your program. The point is, if you get a warning, figure out what it means before passing on it (i.e.: not fixing it).

Warnings that are harmless, sort of. My feeling is this. When you have a big build with thousands of files, you cannot afford to have any of them come out with warnings because it's too hard to squint through the warnings to separate them from the errors and to separate the bad warnings from the not-so-bad warnings. Leaving any warnings at all is just bad practice.

Now, if something's misspelled, is that okay? Sure, unless it's going to reach the user. If you misspell a word and it reaches the log, that's sort of bad, embarrassing for the company.

What about unused imports? Well, it's pointless, right? They're easily fixed.

Other warnings...

Sometimes there are warnings about stupid stuff. If the stuff is too stupid, I turn it off by going to the warning, clicking on the code, waiting for the yellow lightbulb pop-up, clicking it, then pressing the right arrow when the topmost item (not clearly shown here because Cinnamon's Take Screeenshot utility isn't sophisticated enough to snapshot the middle of UI operations) and choose from a long list of options.

These options include disabling the check leading to the warning completely, inserting code mark-up (comments or Java annotations beginning with @) to tell the compiler to ignore for a) the whole class, b) the method c) the statement only, etc. This commenting or annotating is good because it leaves what caused the warning in place, but also a note to someone else reading the comment or annotation what your idea was that made the warning not important.

Eclipse does not offer this feature. That, with the debugger, is the main reason I stopped using Eclipse six years ago after a decade of using it and despite that Eclipse is free. (Free, yes, but it's a pile of plug-ins that you have to make work together and it's incredibly complex.) I functioned even in the answering forums as a responder for Eclipse. I have two awards for doing so much. Ultimately though, once I tried PyCharm after trying Eclipse's PyDev, I was finished and ready to spend my own money annually—$90—to use a professional environment with a much better debugger. I don't get any money from JetBrains for saying this. I just thought I'd stroke my long, white beard this morning.

Misspellings and the dictionary...

Misspellings are made more annoying and urgent now in the last two IntelliJ IDEA updates. When you reach them (sort of like you handle warnings as describe above), you can designate that the misspelling be "certified" by adding it to the dictionary. Yes, I know this can get tedious and the presence of spelling warnings will not prevent the sole green check mark that started today's diatribe, but, well, you decide.

Oh. for example, I saved "LOINC" to the dictionary. That's going to help a lot in what's coming our way. Some typos, though, aren't typos. For example, James got ding'd for writing "blood pressure [sy/dia]stolic readings." If he knew more about medicine, he might have more correctly written "[sys/dia]stolic," but, hey, it's a comment, no?

Unfortunately I have found no way to shut IDEA up on misspellings in comments, but, arguably, their position is very justifiable. Making that change, for example, well, "tolic" is also not in the dictionary nor will I put it there.

When I make decisions like the above, and I commit code, sometimes there are IDEA files that get committed—meaning you'll benefit from my decisions, and sometimes there aren't. I'm not a catalog of which action any warning is tied too. Sorry.

Last, if warnings appear in a file you've written or maintained, I'm not going to jump down your throat. I'll fix as many as I can. You should try to fix as many as you can. It will take a while of you fixing warnings before you begin to catch on to the important ones not to ignore and the ones that need only to be pencil-whipped. Take care not to dismiss from consideration very many warnings to keep the rest of us from seeing them. Tend to fix them either genuinely by recoding, or by comment or annotation. That way, they won't be permanently lost from view.

I hope this is helpful.