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?

  • 14
    (I have evidence that VS 2010's IntelliSense reduces my productivity because it regularly freezes everything) Commented Apr 7, 2011 at 22:22
  • 1
    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
    Commented Aug 12, 2011 at 7:27
  • 2
    Freezing is the only downside of intellisense, as far as I can tell. Otherwise it only helps, and a lot.
    – Coder
    Commented Aug 25, 2011 at 9:47

10 Answers 10


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.

  • 12
    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. Commented Aug 12, 2011 at 2:07
  • 2
    +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
    Commented Aug 12, 2011 at 10:39
  • 1
    +1 intellisense is my guardian tourch for diving into the unknown... doesn't mean I don't how to code by hand. Commented Aug 25, 2011 at 12:30
  • 3
    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
    Commented Aug 25, 2011 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.

  • 2
    or maybe hes just a gramma/grandpa
    – Chani
    Commented Aug 12, 2011 at 4:53
  • It's been said that, aside from trying to do fancy logistical things across projects and such, Intellisense is really the only big reason you wouldn't just use a simple text editor. Text editors are far less cluttered, but you'll notice that whether a programmer chooses a text editor or an IDE to work with largely depends on just how dynamic their language is. Something like JavaScript really defeats the purpose of Intellisense, so that's why it's generally done in things like NotePad++ and Sublime. But Intellisense is great for learning, research, avoiding typos, etc. when it's applicable. Commented Oct 17, 2014 at 16:09
  • Of course, IDEs also help with generating manifest and reference files and such... Commented Oct 17, 2014 at 16:13
  • @Panzercrisis: the fact that these files say nothing interesting, allowing them to be generated, but are still necessary in the source tree is a process smell. Commented Oct 17, 2014 at 21:25
  • Your answer is "how can it?" That's a logical fallacy, as well as uncritical. It would take an average/good programmer about 30 seconds of thought to figure out how Intellisense could reduce productivity in some areas, while improve it in others. Commented Aug 6, 2020 at 16:11

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.

  • 9
    +1 for intellisense encouraging microsoft (and others) to make overly complicated things. Commented Aug 12, 2011 at 0:29
  • 1
    What if those things need to be complicated? Commented Aug 12, 2011 at 0:47
  • 1
    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
    Commented Aug 12, 2011 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. Commented Aug 12, 2011 at 4:45
  • 3
    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. Commented Aug 12, 2011 at 7:29

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 off syntax highlighting just in case you have to edit a file in notepad later, do you?

  • 2
    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
    Commented Aug 25, 2011 at 12:36
  • 2
    @JorisMeys Some of the arithmetic I did without a calculator helped me quickly estimate quantities in later life when there was no time to find a calculator--but calculus seemed to require very different skills. And we used to memorize digits of pi for fun (and maybe a little friendly competition). I guess it was stupid to memorize more than 15 places past the decimal point, since I can only remember 14 of them now.
    – David K
    Commented Oct 17, 2014 at 23:07

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.

  • 2
    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. Commented Aug 12, 2011 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.

  • 1
    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
    Commented Aug 12, 2011 at 7:26

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.


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.

  • There's no need to have mThis, mThat, mAnother if you have a reasonable number of local variables. Commented Aug 12, 2011 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 Commented Aug 12, 2011 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.


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

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