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.
Related
I've been trying to find any type of documentation or examples on how to use the "IDE scripting engine" (or other quick methods of enhancing PhpStorm/IntelliJ IDEs) and found literally nothing that works.
I'm hoping for a bit of a guideline, maybe a snippet that leads in the right direction.
What I want to do:
When pressing Ctrl + Tab (shortcut for GitHub Copilot completion) I want my custom-script to wait for the completion to be inserted into the IDE code.
I want to immediately remove the code again and display it as a completion suggestion (should be quick).
Now I want to press a shortcut to accept the completion word by word until finished.
The possibly biggest problem of Copilot with countless of bug/feedback/feature reports since 2021 is that it inputs tons of code when people just want a tiny part. Like half a line. So users of it are forced to accept 12 lines of bad code, remove all the bad parts.
The reason probably is their marketing, they take those 12 lines (11 of them garbage) as efficiency improvement (12 lines of code accepted). So they don't fix it.
I want to fix it using the above method, the easiest approach would be the most welcome one.
Here is the only available data on the IDE Scripting console:
https://www.jetbrains.com/help/idea/ide-scripting-console.html
However, none of the examples even worked and there are barely any.
Here are the linked examples:
https://gist.github.com/gregsh/b7ef2e4ebbc4c4c11ee9#file-samples-groovy
Nothing of that worked either, various errors usually already in the first "imports" and no examples in "javascript"
Here is the finished code, I switched to Kotlin and from the dysfunctional scripting console to "LivePlugin".
https://github.com/cmp-nct/Stewardess
Stewardess takes over the completions through a new shortcut and plays them in word by word.
Also shows the Copilot internal status as temporary hint notification when it changes.
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.
In every IDE I've tried so far, if I'm partway through writing a message and need to look at the code of another, the browser asks me if I want to save. But if I say I do want to save, it actually tries to compile/syntax check the code, and refuses to perform the save if it does not pass. The only way to view the source of another message seems to be to say "no" to save and have everything wiped. How can I look at another class incidentally, or save code I am partway through working on that might not build right now?
Smalltalk is a multi-browser system. You'll need to have lots of different browsers open. Smalltalk is opinionated. The system browser (Nautilus) doesn't make it easy to view long methods, steering you towards writing short ones. It doesn't make it easy to have non-compiling code in a method, to steer you towards making small changes.
Experimental/prototypical code you might want to have in a Workspace/Playground. That can save to disk.
We are aware that it is an issue for people new to Smalltalk. We tried some fixes, they were a lot worse.
For now there is no easy way to do that. The two easiest opting are
Make the current method syntactically correct and save it.
Open another browser. If you want to see a class or method that is in your current code, you can cmd+click it or use "browse it", "implementors of", shortcuts that will open another window.
Also in pharo you can use GTSpotter to quickly find what you are looking for and preview its source code
When you say "this seems like a pretty huge thing to be missing,
and it could be gotten around by just having the option to use
a regular editor" I'm afraid you've entirely missed the point.
Understandable, though -- happens to us all.
Or did. Perhaps it was long ago, but we
were all there.
You might be thinking about the task in terms of
scrolling a giant text up and down to find what
you want. Scroll up -- read a little -- scroll back --
and continue making your changes.
And when you say " I can't imagine any circumstance
where it is OK, in pursuit of any agenda, to throw away
the coder's work against their will "
you are spot on correct, of course.
Imagine -- scrolling around, making dozens of little changes,
and before you've saved them -- poof -- they're all thrown away --
a mistake, perhaps, but completely against your will.
That would be awful. We're agreed.
(In fact, the editor I'm using to type this
is like that -- I can scroll around the whole thing,
making little improvements, all over, but it could
all go --poof-- and disappear, All of it.
Fairly common occurrence, when editing the web.
)
So let's try another run through that same task.
You get one little teensy, DUMB AS A POST editor,
where you can only see one thing at a time.
And now you just want to scroll somewhere else,
for a moment, and come right back.
Which actually means that
you are attempting to look up a second method,
while already changing a first method
(which would require the browser toforget the
context of the first method, and move to the second).
The browser does not know how long you will be away
from this context. You might go chaining along from
place to place, stop and read an email, take a call,
and go to lunch.
So, the browser cautions
"Hey - want to save this first?"
as if to say:
"
Hey - I can't imagine any circumstance where it is OK,
in pursuit of any agenda, to throw away the coder's work
against their will.
So listen up, coder.
You want to save this first?
"
But you can't save it.
You must first look something up.
Conundrum.
Ah-ha! There is a list of methods in that other pane.
One of them is highlighted.
Not those -- that one.
Double click that one.
The one you're already in.
As if to say
" Thanks. Good catch.
Yes, I know - can't though.
I need to change contexts.
You stay right here.
And give me another context
to go wandering about in.
please.
"
Soon, I expect, they'll start actually talking.
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.