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.
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.
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.
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.
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.
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
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.