Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
Should newbies use IDE autocomplete (Intellisense)?

I was having a conversation with another developer the other night about the pros and cons of Visual Studio. He was of the opinion that Intellisense reduces productivity. Of course I thought that was insane but I could be wrong. Is there any evidence to support the idea that Intellisense reduces productivity?

share|improve this question

migrated from stackoverflow.com Aug 12 '11 at 0:25

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Mark Trapp Oct 16 '11 at 20:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

(I have evidence that VS 2010's IntelliSense reduces my productivity because it regularly freezes everything) –  Alexander Gessler Apr 7 '11 at 22:22
Maybe you shouldn't use it when you write your own API (to avoid creating bazillion-args functions, etc), but for accessing other APIs, it's a good thing to have. –  Macke Aug 12 '11 at 7:27
Freezing is the only downside of intellisense, as far as I can tell. Otherwise it only helps, and a lot. –  Coder Aug 25 '11 at 9:47

10 Answers 10

up vote 44 down vote accepted

Your friend was probably implying that intellisense allows developers to never memorize all of the properies and methods of every type of object, which in turn reduces the speed at which they write code.

But for anyone who has ever used a type, control, class, or object with which he or she was unfamiliar, intellisense is infinitely useful in reducing wasted time due to reading through the entire class.

So, basically, according to me, your friend is generally wrong.

share|improve this answer
With the number of classes in the .NET library in the TENS OF THOUSANDS, each with a dozen (or more!) properties and methods, I'll take Intellisense over trying to remember every jot and tiddle, not to mention all the method signatures. –  Jarrod Nettles Aug 12 '11 at 2:07
+1 also, even if the developer already know exactly what to type faster than with intellisense, he can do it without bothering about intellisense that becomes just visual noise as he types. You can learn to not bother easily. –  Klaim Aug 12 '11 at 10:39
+1 intellisense is my guardian tourch for diving into the unknown... doesn't mean I don't how to code by hand. –  Dal Aug 25 '11 at 12:30
Not only that; if you want to have readable code, you need rather long names, and Intellisense helps to avoid misspellings and wasted compilations due to them. –  zvrba Aug 25 '11 at 19:55

How can it possibly reduce productivity? Imagine having to hunt through the documentation every time you're looking for a namespace, class, method or property.

Intellisense is one of the great advances in IDE editors.

share|improve this answer
or maybe hes just a gramma/grandpa –  Wildling Aug 12 '11 at 4:53

It reduces productivity by making Microsoft think it's okay to design functions to take 10 or 12 parameters, so virtually nobody ever can or will even come close to learning how to use them without the assistance of (something like) Intellisense.

Edit: Okay, let's take a look at the CreateAnimatedSprite example. First, a function name with two verbs is a nearly-certain sign of poor separation of concerns -- i.e., you have a single function that's really doing two things. Our first step is to fix that so we get a CreateSprite (or, since it's apparently being loaded from a file, it should probably be LoadSprite), and an AnimateSprite. For the moment, let's even assume @Mason is wrong, and you really do need all those parameters -- but when we've separate concerns decently, we're apparently left with something like:

sprite LoadSprite(std::string filename, int imageHeight, int imageWidth);
void AnimageSprite(sprite s, int frameWidth, int frameHeight, int numColumns, bool isLooped);

By my count, we now have the parameter count down to a maximum of 5 -- half the number I'd mentioned as being excessive.

I'd consider this well short of ideal though. First of all, I'd advise against using a bool as a function parameter in most cases. Just glancing at a call to the function, it's not immediately obvious what true or false would refer to. It would be better to have something like:

enum {LOOP, NOLOOP};

When somebody's reading a call to the function, LOOP is much more meaningful than true. Depending on the situation, there are a couple of other possibilities to consider. One would be using object-orientation, so we'd get:

class Sprite {
    enum looping { LOOP, NOLOOP };

    load(std::string filename, int imageWidth, int imageHeight);
    animate(int frameWidth, int frameHeight, int numColumns, looping doLoop);

That gets us down to only four parameters for a function, still providing the data you thought was necessary.

In reality, we can probably do better still. First of all, the file from which we load our sprite can store the size of the image(s) it holds, so we may not need to supply that (it's primarily useful if we're selecting one sprite from a file that may hold several). Second, as @Mason pointed out, we probably don't need to supply a frameWidth/frameHeight or numColumns either. In addition, single-pass animation and looped animation are enough different that it's frequently more sensible to supply those as two separate functions. Finally, it might well make sense to just pass the file name from which we're going to read the sprite as a parameter to the ctor. Incorporating all those, we get:

class Sprite {
    Sprite(std::string const &filename);
    animate(page const &target);
    loop(page const &target);

So to load an animate a sprite, we now need something like:

Sprite x("somefile.spr");

Keep in mind that peoples' short-term memory ranges from about 4 items for a person of average intelligence to about 8 for the top geniuses.

That means 10 parameters is nearly always unreasonable. 7 parameters puts it within reach of a few, but honestly only a few. 4 puts it within reach of almost any programmer, and 1 (or even 3, if you really do need to specify resolution) puts it into the dead simple catgory.

share|improve this answer
+1 for intellisense encouraging microsoft (and others) to make overly complicated things. –  Christopher Mahan Aug 12 '11 at 0:29
What if those things need to be complicated? –  quickly_now Aug 12 '11 at 0:47
If no function should have that many parameters, reduce this: CreateAnimatedSprite(std::string filename, int imageWidth, int imageHeight, int frameWidth, int frameHeight, int numColumns, bool isLooped). Using std::pairs is just as bad because you either create them before hand or pass them as std::make_pair() calls which could make the call more confusing. –  Casey Aug 12 '11 at 1:06
@Casey: Umm... what in the world are frameWidth and frameHeight? That doesn't look like any sprite system I've worked with. I should only need to pass in a single Point describing the size of a single sprite, and let CreateAnimatedSprite work the rest out. Or, if I've got a badly designed sprite sheet with more than one character on it, I'd need to use 2 points: 1 for the size of an individual sprite, and one for the total number of sprite sets horizontally and vertically on the sprite sheet. There's no need for a numColumns in either case; that can be inferred from the sizes. –  Mason Wheeler Aug 12 '11 at 4:45
While I agree with your general idea, I don't think "LoadAnimatedSprite" is actually doing two things, it's loading a sprite that has multiple frames (i.e. an animated one) as opposed to loading a sprite which only has one frame. –  Dean Harding Aug 12 '11 at 7:29

It actually can reduce productivity - outside of visual studio, because you have to look up a lot in the documentation. Due to intellisense, you might never have learned the important methods and classes by heart.

share|improve this answer
But that's simply moving time from in front to in the middle. Since you can't know exactly what classes you'll need to know in advance doing it in front takes more time overall. The only possible savings is that frontloaded time may be off the clock. –  Loren Pechtel Aug 12 '11 at 3:33

It's been some years since I worked in C#, so I'll give my answer w.r.t. Eclipse and Java. Completion in Eclipse doesn't reduce my productivity. The need for completion due to the inconsistent Java API does reduce my productivity considerably. For example, Java has arrays, lists, sorted sets, and streams. They are all list-like, and have essentially no methods in common. It's the same for maps, and HTTP request parameters, and SQL query parameters, and the rows in a SQL result set, and JavaBeans. They are all map-like, but have different APIs, and converting between them is painful. I do fine without completion in languages where APIs are consistent, where everything that looks like a list is a list, and everything that looks like a map is a map.

share|improve this answer
I think this is what the OP's collegue was referring to, in part. People write sloppier code by relying on Intellisense too much, and that makes productivity go down. It's a secondary effect of coding with Intellisense. (It's useful for coding against horrible code, but it makes it easier to create horrible code.. so it may be a net loss.) –  Macke Aug 12 '11 at 7:26

The same sort of arguments happen around spellcheck, and the use of calculators in schools. The idea being that students having free access to calculators reduces their mental arithmetic ability.

I would agree that that effect is probably true, and would argue that it is also unimportant. Calculators are always available, and so it would be more productive to spend time learning to solve Second Order Differential equations than learning to do complicated division in your head.

If you use an IDE with a good implementation of something like Intellisense, then yes, certain skills will wither, and that's because you're spending more time doing other things. Things that are more productive for your code than remembering the precise name of a particular member function.

If you plan to go back to a non-Intellisense IDE, then you might have a problem. In that case, turn it off. For the rest of us who assume that IDE's will only advance, we're OK.

Yes, Intellisense may encourage API designers to put too many arguments in, but writing something like C++ requires a lot of discipline to not do any of the many bad things it allows you to do, and this is just one more.

One final analogy: you don't turn of syntax highlighting just in case you have to edit a file in notepad later, do you?

share|improve this answer
Let me disagree on the calculation stuff. The reason why you learn how to do that, is because it trains your brain for calculus. This would be the equivalent of saying that learning to swim is a waste of time because there are always boats available. I do agree though that learning pi by heart up to 15 digits would be rather stupid. –  Joris Meys Aug 25 '11 at 12:36

In my opinion, the only time it may reduce productivity is when you need to do something where intellisense is not available (e.g. when doing something dynamic). You're so used to it being there that you sort of think something is wrong when it's not there.

share|improve this answer

You use the tool that you feel makes you the most productive, and the other guy can use the tool that he feels make him feel the most productive. It'll never happen, but a world without the "my tool is the best because I use it therefore I must force it on everyone else" mentality would be really great.

On a related vector, I've noticed that people who use tools that highlight syntax tend to be less of the "bad Hungarian" style, there's no need to have mThis, mThat, aThing, and aNother if you have color to tell you the scope.

share|improve this answer
There's no need to have mThis, mThat, mAnother if you have a reasonable number of local variables. –  kevin cline Aug 12 '11 at 4:05
Syntax highlighting is generally useful: Rick Kazman and Riston Tapp, "Determining the Usefulness of Colour and Fonts in a Programming Task", cgl.uwaterloo.ca/~rnkazman/prog-comp.ps –  Bruce Ediger Aug 12 '11 at 13:05

I just ran into a situation where IntelliSense got so confused by nested macros in a particular header file that every edit operation took more than 30 seconds. This definitely reduced my productivity.


It turns out that the culprit was not IntelliSense, but a refactoring plug-in which also did analysis of the source in the background. So I still say it is possible for supposed productivity enhancers to slow you down, but I don't have a specific case against IntelliSense.

share|improve this answer

IntelliSense sometimes likes to be a tiny bit overzealous with auto-completion. For example, if I want to write something IntelliSense doesn't know about yet (mostly because of some keys it uses for auto-completion not making a lot of sense).

Say I have a C# file where I want to use the File class to copy something. I have not included "using System.IO" yet.

I type "File." and as I hit the period, it immediately goes "Aha! I know what you want. You want FileStyleUriParser." Then I have to go delete the word and try typing it again. I forget that the period turns on auto-completion and accidentally do the same thing again. Eventually I press the ESC key at the correct time and type it.

This is just because I know what I want to type and I don't need IntelliSense for it. I also don't want to spend the time going to the top of the file to put the using statement in (yet).

Now, to be fair, you can turn off this behavior. I like this behavior sometimes and hate it others (which is why I haven't turned it off).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.