When it comes to implementing "quick fixes" there are two separate class hierarchies you can use, QuickFix (and LocalQuickFix) and IntentionAction. There also seems to be ways of implementing both (as in LocalQuickFixAndIntentionActionOnPsiElement).
I'd like to know the difference between those two base classes. When would I use one but not the other? Is one of those hierarchies obsolete and superseded by the other?
A QuickFix usually belongs to an Inspection, and should be implemented as an automated fix to the warning issued by the inspection.
Try, for example, using list.size() == 0 in Java. IntelliJ will suggest to replace this with list.isEmpty().
Note the highlighting (in IntelliJ).
The action that you can trigger with Alt + Enter is called the quick fix, and it will execute this replacement for you.
An intention is similar in the sense that it is an action specific to a piece of code that can be triggered by Alt + Enter. The main difference is that IntelliJ doesn't complain if you don't use the intention; there is no highlighting to indicate that something is or could be wrong here, because there probably isn't.
Intentions are meant to make the life of the user easier, but they don't get as in your face as inspections do.
To give an example, this could be used in LaTeX to replace any brace pair by their \left\right equivalent; it's not something to trigger an inspection for because often the simple brace pair is preferred, but it's nice to be able to do this replacement with a simple shortcut.
You'll regularly encounter loops in intentions as well, and even intentions that go in the opposite direction as a quick fix, but you won't see loops in quick fixes (unless you've explicitly enabled both directions of an inspection).
To summarise: use a quick fix when implementing an automated fix to an inspection, and use an intention action otherwise.
Related
Intellij has a really neat feature, that lets me seamlessly extract a block of code into its own method. I can then give this method a nice, descriptive name and move on with life.
However, intellij also tries to find other blocks of code that are similar, and then tries to perusade me that I should also refactor them too, to use this new method its made. And then, when I hit the oddly-named "cancel" button (which implies the whole operation is cancelled, but it's not, it just stops asking about any remaining blocks), it leaves me looking at whatever the block of code it last asked me about.
I really don't like this feature. Here's why: If I'm say comparing two ints - the naming of the code block will depend on the context of those two ints, but intellij will find any comparison between two ints anywhere in that file, and then insist that this is also a candidate for extraction.
Most times it is not, and to make it worse, when I ask intellij to stop it, in a fit of pique, leaves me wherever the last comparison was, so now I have to navigate back to where I was working.
How do I tell intellij just to extract exactly what I selected, and do nothing else?
Please follow/vote/comment the issue created for this usability problem at YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-233201
Currently, I am "forced" to develop my reports with SE80 / SE24, etc. and I can't use eclipse. There I've seen that if you have the "Source Code-Based" view in Z-Classes, above every method the signature is shown as a comment. See in the following picture:
Well, I know that those comments are not really in the source code, but shown anyway (generated somehow).
Do you know a way how to disable those "comments"?
I find them unnecessary and I am losing the overview over the class. And instead of a 27-row implementation part of a class I've got an 88-row-long implementation part.
These signature comments are automatically generated by the SAP GUI based class editor reached through transactions SE24 and SE80.
Use the ABAP Development Tools to avoid them.
There's no way to disable those comments. I genereally prefer the form editor when forced to use SE80, I think it gives a better overview. The best would be if you were allowed to use Eclipse, but politics can be difficult to change.
I'm using several of JetBrains' products, like IntelliJ IDEA, PyCharm and PhpStorm. One issue I'm having is that when viewing a diff codelines will look different even though they are identical.
(full image)
The lines are identical, but the rendering of them are different. That's pretty annoying, as it's hard to spot where there are actual differences.
This example can be mostly solved by turning off inspections, but that turns them off for the whole project, and I will need to constantly enable and disable it.
(full image)
In this example, there's also no differences. And there are no highlighting from inspections. But still the code is rendered differently. The comment reminded my that this is because of language injections. Turning them off makes stuff look right, but I want them when I work.
How can I make my diff become more readable and the differences easier to spot without all the clutter and without disabling everything?
It's been possible for a while now to change this just for a diff-view. For instance when committing, one can press the cog and change Highlighting Level.
The goal of IDEs is increase productivity. They do a great job at that. Refactoring, navigation, inline documentation, auto completion help increase productivity immensely.
But: Every tool is a weapon. The very same IDE helps to produce chunk code. Some IDE features are an invitation to produce bad code: code generation, code formatting tools, refactoring tools.
IDE overuse tends to isolate developers from the necessary details. It is a good thing that you can start working but at some point in your career you have to be able to figure out how to start a process. You can ignore this detail for some time, in the end they are important to write a working product (vs. bolted together stuff that works 90% of the time).
How do you encourage positive behavior of other developers working with an IDE? This is a question as old as copy and paste.
To get the right impression: developers have to have the maximum freedom to mobilize their maximum creativity and motivation. They may use IDEs and all the related tools as they see fit. Nobody should impose draconian measures on them. I don't want to demotivate and force someone to do something. Good behavior has to be encouraged. It has to itch little a bit if you do the wrong thing. In the same line as the SO "accept rate" metric (and reputation). You can ignore it but life is better if you follow the rules.
(The solution should work in a given setting. You can ignore reviews, changing the staffing or more education as potential solutions.)
Train your IDE, instead of being trained by it.
Set up code formatting the way you (or your team) wants it. Heck, even disable it in cases where it makes sense. I've never seen an IDE align something like this with a sensible combination of tabs and spaces (where \t is obviously the tab character):
{
\tcout << "Hello "
\t << (some + long + expression +
\t to_produce_the_word(world))
\t << endl;
}
In languages like Java, you cannot avoid boilerplate. The best option you have is to check generated code, ensuring that it is the same as what you'd have written by hand. Modify it as necessary. Configure your IDE to generate the exact code that you need, if possible. Eclipse is pretty good at this.
Know what's going on under the hood.
Know that your IDE is actually invoking the compiler. Have some insight into the flags that it passes. Be able to invoke the compiler from the command line.
Know about the runtime system. Be aware of the flags that are used or needed to launch your program. Be able to launch the program from a command line.
I think before anyone uses a RAD tool of any type they should be able to write the application from scratch (scratch being wiring together the framework components) in notepad potentially on a computer that is 10 years older than current technology :P. Not knowing the ins and outs of a paradigm/framework leads to bad code from novice developers who only learn things at a mile high view of the platforms they develop for. Perhaps they should do this in a few technologies -- i.e., GTK programming is completely different to MVC which is then also different to SWING and .NET.
I think the end result should be a developer that thinks of the finer details of a problem before they jump to thinking of how they will write an interface to it in a specific RAD environment.
its an open ended question, but...
We have a Eclipse format file that everyone shares, so that we all format the code in the same manor. (Except the one lone InteliJ guy we have).
Everyone shares a dictionary file. It helps to remove all the red lines from the code. Making it look cleaner and more readable.
I run EMMA over the code to find out who isn't testing their code, and then moan at them.
The main problems we face is that most of the team don't know all the features/power of the IDE (eclipse). The didn't know about CTRL + O (twice), or auto code gen. All I can do as a 'hot key wizard' is keep sharing my knowledge with them to help them become more productive.
I look forward to the day when my problem is that they auto gen as much as possible.
Rather than me finding bugs where the wrong value is returned from a getter method due to a typo.
Attempt development (at least occasionally) using only a text editor and launching the compilation, testing, etc. from the command line.
Typing the commands will get tedious very quickly so create scripts or (even better) learn rake, ant, msbuild.
If the IDE does code generation for you and that code generation is really important (such as generating classes from xsd or proxy classes from wsdl), try to find out how to run the code generation from the command line - then hook the code generation into a build (so you'll never be tempted to edit the generated code).
The idea of autoformatting code is great but it usually just turns your code into a mess. If you have less code, minor formatting inconsistencies are just not a big deal.
Adding code quality tools into your build - style checks, class and method sizes, complexity, code duplication, test coverage, etc (complexian, simian, flog, flay, ndepend, ncover, etc.) will discourage IDE generated code.
I downloaded IntelliJ IDEA and started with the 30 day evaluation.
Now I'm just wondering, why should I use IntelliJ for plain old java developement (so no Hibernate, JSP, etc)? It doesn't look that different from eclipse or NetBeans, so I hope some IntelliJ guru can give some examples of things IntelliJ can do to justify investing the money in it. I'm trying to use the evaluation to it's fullest and don't want to miss an important feature.
A list of things possible in IntelliJ but not in eclipse is already available, but I'm more interested in the daily workflow than some obscure features that will be used twice a month.
I've been using IntelliJ for about 5 years now (since version 4.5) and I also read through most of the Manning book "IntelliJ in Action" and I still wouldn't consider myself a guru on it. In fact, I also wanted to do "plain old Java development" with it, and honestly I have to say that it's quite good at that. Like the other answers, I can only say that there's a definite edge in it's helpfulness that really puts it over the top. We use Eclipse here at work also, and while I don't have as much experience, I can tell you that there are definitely a lot of basic things lacking in it. I put in some serious time and effort to learn Eclipse, looking up how to do the everyday sorts of things I take for granted in IntelliJ, and they're mostly not there or very poorly implemented. The refactoring stuff is definitely the thing that helps a lot.
Aside from the refactoring, I think there are just a ton of small touches that really make this helpful. I think an example might help clarify...
Try this:
Create a new, empty class. Move the cursor inside the braces and do psvm and hit Ctrl-J - this expands the "psvm" into "public static void main(String[] args)". There's a whole list of commonly-used idioms that this shortcut will handle (and it's configurable, too). Inside the main code block, enter this code:
public static void main(String[] args) {
int x = 1000;
sout
}
At the end of "sout", do Ctrl-J again - you'll see another popup that let's you choose from some different expansions, but in general this expands to "System.out.println("")" and helpfully puts the cursor between the double-quotes (it's small touches like this that really make it shine, I think. Compare with Visual Studio's "IntelliSense" - a total crock if you ask me).
Anyway, backspace over the first double-quote - notice it deletes the matching double-quote? It does the same thing with braces and brackets, too. I think there are a few corner cases where I prefer it doesn't do this, but the large majority of the time it helps a lot. Back to the code editing: just type x so the code now looks like this:
public static void main(String[] args) {
int x = 1000;
// add a few blank lines here too - the need for
// this will be obvious a little later
System.out.println(x);
}
Now, move the cursor over to the declaration of x, and do Shift-F6 - this is the refactoring in-place dialog (I dunno what to call it, so I just made that up). The name "x" gets a colored box around it, and you can start typing a new name for it - as you type, all uses of that name get dynamically updated too. Another neat touch I really like.
Try this: put a really long line comment somewhere, like so:
// this is a really long comment blah blah blah i love to hear myself talking hahaha
Now say you decide the comment is too long, so you move the cursor to the middle of it somewhere and hit Enter. IntelliJ will put the remaining portion of the comment with a "// " prepended - it "knows" this is a continuation of the previous comment, so it comments it for you. Another neat touch.
// this is a really long comment blah
// blah blah i love to hear myself talking hahaha
Another big bonus I like about IntelliJ compared to Eclipse is that it's much less intrusive - I really hated how Eclipse would manage to get popups on top of popups, and mouse focus would be somewhere but keyboard focus is stuck on something underneath, etc. I think it's possible to work in such a way that these sorts of things don't happen, but it annoyed me immensely in the first place. That reminds me, in IntelliJ if you move the mouse cursor over the package or file navigator in the left pane, that panel gets the mouse focus automatically, so I got accustomed to using the mouse wheel immediately to look around. In Eclipse? You mouse over, but focus stayed on the editing pane, so you have to CLICK with the mouse to transfer focus, and then be able to use the mouse wheel to look around. Like I said, it's a lot of small touches like that which help with productivity.
As you code around, pay attention to the left gutter bar for red "light bulb" type symbols on the current line - this is IntelliJ telling you there are possible things it can do. Use Alt-Enter to bring up a small in-place dialog box, and it will tell you what it can take care of automatically. Say you type in a method definition named "getFoo()" and there's no foo member - it will offer to create it for you. Or if you're using a class and call a non-existing method on it like getFoo() - it will offer to create a getter and a member, or a regular method. It's just plain helpful.
Overall, I'd say small touches are not what IntelliJ gurus will really want to talk about, but I really appreciate how these sorts of things are just "well done". They take care of small details so you don't have to spend so much mental runtime checking your own syntax. I think of it as a butler helping me out with my coding - it takes care of small chores for me so I don't have to. Batman has his Alfred, and I have my IntelliJ. All the settings are excruciatingly laid out for you to modify if you like, but it just seems like the defaults are all geared toward improving your productivity, instead of bothering you all the time with really mundane decisions (especially those which you would almost always make the same choice anyway).
There are some definite drawbacks to IntelliJ - the price is a bit high, and it's quite large that it can take a while to load up on a large project. I'm lucky in that my company pays for the license as well as a very nice workstation so it loads up reasonably quick, but your mileage will vary.
I have a day job where I use Eclipse (because that's all that is permitted). I also have my own company where I "moonlight" doing contract work and use IntelliJ.
I would say their feature sets are about the same. Pretty much the same refactorings, same code assists, same style of use, etc. Eclipse arguably has better plug-ins, and probably many more, than IntelliJ. IntelliJ just "knows" things right out of the box like Spring and Hibernate, and these things are better integrated than Eclipse plug-ins of similar functionality.
The reason I choose to use IntelliJ when allowed (personally purchased and upgraded several times) is that everything it does just feels cleaner. Its hard to put my finger on it, but the exact same functionality in IntelliJ feels more streamlined and easier to use than in Eclipse - enough that I would pay for it even though there is a full-featured free IDE available.
So, the activities you should do to decide are this: use IntelliJ everyday for all your development tasks for 30 days. Push through the curve of learning new shortcuts and ways of searching, refactoring, etc. and I suspect you will prefer it. If not, Eclipse is still there for you.
I've just moved back to Eclipse after 2 years with Intellij (due to a client's preferences).
I'm finding Eclipse to be less helpful. I know that's a nebulous term, but Intellij's feedback was clearer, the UI gave me better information on what was going on, the automatic building seemed more seamless. The project setup/configuration seems more intuitive.
This is perhaps subjective, but sometimes that's why you prefer one over the over. It just feels that little bit slicker, that little bit friendlier...
(I don't think the VIM plugin for Intellij is better, but that's another story!)
2weiji: use Tab instead of Ctrl+J :-) It's much handy :-))
sout then Tab
psvm then Tab
iter then Tab
etc... :o)
Why use IntelliJ? Because I find it more consistent in it's user interface and more polished. It allows you to keep your hands on the keyboard longer, rather than switching back and forth between keyboard and mouse. As other people have said, it's the little things that add up.
I found the user-intentions functionality a huge time-saver, and the way it reviews the code and suggests optimizations and corrects bad practices. That I can hit Alt-Enter in a lot of contexts and the IDE is able to figure out and insert what should be there. Pesky things like type declarations, optimizing an old-style for-loop to use the new JDK-5 type of loop, removing redundant value assignments or unused variables.
Being able to first type in the usage of a method that doesn't exist, and then hitting a key combination and having the IDE write out the bare structure of the method - huge timesaver. It makes for a better workflow for me, because it allows you to first think about how you'll be using a method, what it looks like when you read it in context.
Refactoring support - this was the big selling point when I first started using it in 2003, and I think it still leads the way (but I hear Netbeans is also pretty good now)
Highly recommend that you have a look at the IntelliJ KeyMap Reference.
Have a look at this discussion for often-used shortcuts: What are the most useful Intellij IDEA keyboard shortcuts?
I'm not an IntelliJ IDEA guru but what the fanboys usually like about IntelliJ are the great refactoring and code assist features. They often claim this product is far superior to its competitor from this point of view.
Personally, I'm a partisan of the following principle: use the IDE with which you feel the most productive, not the one somebody else prefer.