Using Visual Studio 2010, I keep running into a very annoying habit in its IntelliSense feature. Instead of prioritizing local variables and properties, it seems to default to picking whatever random class out of the standard libraries happens to have the same sequence of characters in the name. It's almost invariably some class I've never heard of or had any use for, and always completely inappropriate in the context. I'm finding myself having to type everything out fully instead, which begs the question of why I have IntelliSense in the first place?
Is there a way to make it choose local variables or properties first, since those are the things I'm most likely to use? Or failing that, it should choose classes within my current project over obscure random classes from the depths of the standard libraries. I know other IDEs work like this, such as Eclipse. I've looked at the options in VS, and pretty much the only thing I can do that helps is to check the "Pre-select most recently used member". That's great, but it seems like it should be possible to do better than that, perhaps keeping a stack of recently used members so you can get the next-most-recently used, etc.
Related
I'm a Unity developer and just made the jump from Monodevelop to Visual Studio Community. Overall Visual Studio Community is a huge improvement but there is one thing I miss that Monodevelop did better: With Monodevelop's auto-completion, it would always sort the functions / variables by class. With VSC, it just shows every possible conclusion in alphabetical order, including all class and base class methods and properties.
So, in the example shown here, if I start by typing "PauseManager." in Monodevelop, it will show autocomplete suggestions first for PauseManager, and then below that for it's base class System.Object.
However when I type the same thing in Visual Studio, it will show me a huge list of methods and properties in alphabetical order, the majority of which I'm unlikely to be using.
This is a very simple example of a small class with only one ancestor; you can imagine that this gets especially unwieldy when I've got a class with a dozen public methods and multiple ancestors, each of which have their own public methods and properties.
I've looked at the documentation for Intellisense here: https://code.visualstudio.com/docs/editor/intellisense and I don't see any options for what I'm trying to accomplish.
Does anyone know of a way that this can be done? If not I may have to reluctantly go back to Monodevelop - looking through all these methods to sort out the ones relevant to what I'm doing it turning into an annoying little time waster.
Nope, apparently it is not possible currently.
There was an issue/feature request but they closed it 5 months ago with kind of "won't do" as answer.
They linked it to a "duplicate" issue though I honestly don't really see that as a duplicate ...
Maybe you can search for plugins but built-in it seems not possible currently .. what is a pity because now that I know it exists somewhere I also miss it a bit :'D
Go to
Tools -> Get Tools and Features -> Modify
If you have multiple versions, select the proper version.
Scroll down and find Visual Studio Development Extension.
Click the checkbox and hit Modify.
That's all you need to do.
Enjoy✌️
I am in a new team. I am shocked by their coding guidelines.
Example:
strName
iCount
structRectangle
listCustomers
retVal (for the return value... that is really biting me... how someone can do this)
They demand to write the datatype before the variable with the argument that this way the developer knows everytime what datatype the variable is without scrolling up to the declaration.
Well that is true, but my argument would be then a method should not be longer than 30 lines (else put code in another method) which fits into a common 24" screen...
But I am not totally convinced because there are things like Action<T>, Dynamic, Func<T> in .NET. which force me too to go the same way and do "actionCustomers" for a delegate holding a method gettings a list of customers.
What advice can you give me as an alternative to e.g. "actionCustomers" which should render the argument of the team useless?
I would suggest that you adopt the coding style of the team you are coding with. They have adopted their style to deal with their own systemic problems. Unless you are in a position to judge their code (which it seems you are not) or you can appeal to a higher authority on code style (seems unlikely from your post) then, if you want to keep your job and demonstrate that you're a team player, you need to conform to the rules you've been given.
Why is datatype in variables bad coding style?
It's not. A relatively ancient form of it called Systems Hungarian Notation that actually encoded the type has received a lot of criticism for a lot of reasons, including redundancy, inconsistency, and poor readability. But that's not what you're dealing with. I sometimes find it helpful to include datatypes in my object names when I haven't fully decided on which container I'm going to use (list, no, set, no, dict... and usually in that order.)
This coding style is very useful when you are not using an IDE.
I often open old code files with Notepad++ (just to read it and convert to newer code, no need to open huge project to read one single file) and without this coding style, every time I see a variable, I have to search for its name inside the document just to find out its type. And that hurt my time schedule A LOT.
Long story short: you may not like the old school methods but they existed because people needed them. You will never know if one day you wish for it.
Encoding the type of a function into the name (so-called Hungarian
notation) is brain damaged—the compiler knows the types anyway and can
check those, and it only confuses the programmer.
Linus Thorvalds, Linux Kernel Coding Styles
I really love that quote.
I'd like to know if anyone has found a solution for writing human-readable method tests names, so non-tech guys may read test list and they'll be able to understand what's going on, and, in instance, programmers won't need to use "non-tech-guy-friendly naming conventions" like "Whatever_Whatever2_Whatever3_DoesHelloWorldTest" anymore...?
There is a lot to be said for the clear and understandable convention:
MethodName_StateUnderTest_ExpectedBehavior
(not restricted to VS2010 or even .NET)
OK so that title sucks a little but I could not think of anything better (maybe someone else can?).
So I have a few questions around a subject here. What I want to do is create a program that can take an object and use reflection to list all its properties, methods, constructors etc. I can then manipulate these objects at runtime to test, debug and figure out exactly what some of my classes / programs are doing whilst they are running, (some of them will be windows services and maybe installed on the machine rather than running in debug from VS).
So I would provide a hook to the program that from the local machine (only) this program could get an instance of the main object and therefore see all the sub objects running in it. (for security the program may need to be started with an arg to expose that hook).
The "reflection machine" would allow for runtime manipulation and interrogation.
Does this sound possible?
Would the program have to provide a hook or could the "reflection machine" take an EXE and (if it knew all the classes it was using), create an object to use?
I know you can import DLL's at runtime so that it knows about all sorts of classes, but can you import individual classes? I.E. Say I have project 'Y' that is not compiled to a DLL but I want to use the "reflection machine" on it, can I point at that directory and grab the files to be able to reference those classes?
EDIT: I would love to try and develop it my self but I already have a long list of projects I would like to do and have already started. Why reinvent the wheel when there is already a great selection to choose from.
Try looking at Crack.NET. It is used to do runtime manipulation and interrogation on WPF/WinForms but the source is available and might be a good start if it already doesn't meet your needs.
It sound as if Corneliu Tusnea's Hawkeye might be close to what you're looking for runtime interrogation of objects/properties/etc. He calls it the .NET Runtime Object Editor. I'm not sure if the homepage I linked to above or the CodePlex project is the best place to start.
It's a bit out of date now, I think, but there's an earlier version of it on CodeProject where you can see the source code for how and what he did.
Powershell actually does nearly all of this, if I properly understand what you are saying.
See this answer on how to build a "reflection engine".
All you need to do is to drop that set of machinery in the your set of available
runtime libraries and it does what you want, I think.
(It might not be as easy as I've made it sound in practice).
My guess is you'll also want a runtime compiler, so that you can
manufacture instrumented/transformed variants of the program under inspection
to collect the runtime data you want. You may find that such
machinery provide static analysis results that let you avoid
doing the runtime analysis in many cases.
I was poking around in XNA and saw that the Vector3 class in it was using public fields instead of properties. I tried a quick benchmark and found that, for a struct the difference is quite dramatic (adding two Vectors together a 100 million times took 2.0s with properties and 1.4s with fields). For a reference type, the difference doesn't seem to be that large but it is there.
So why is that? I know that a property is compiled into get_X and set_X methods, which would incur a method call overhead. However, don't these simple getters/setters always get in-lined by the JIT? I know you can't guarantee what the JIT decides to do, but surely this is fairly high on the list of probability? What else is there that separates a public field from a property at the machine level?
And one thing I've been wondering: how is an auto-implemented property (public int Foo { get; set; }) 'better' OO-design than a public field? Or better said: how are those two different? I know that making it a property is easier with reflection, but anything else? I bet the answer to both questions is the same thing.
BTW: I am using .NET 3.5 SP1 which I believe fixed issues where methods with structs (or methods of structs, I'm not sure) weren't in-lined, so that isn't it. I think I am using it at least, it's certainly installed but then again, I'm using Vista 64-bit with SP1 which should have DX10.1 except that I don't have DX10.1 ..
Also: yeah, I've been running a release build :)
EDIT: I appreciate the quick answers guys, but I indicated that I do know that a property access is a method call, but that I don't know why the, presumably, in-lined method is slower than a direct field access.
EDIT 2: So I created another struct that used explicit GetX() methods (o how I don't miss my Java days at all) and that performed the same whether I disabled in-lining on it (through [MethodImplAttribute(MethodImplOptions.NoInlining)]) or not, so conclusion: non-static methods are apparently never inlined, not even on structs.
I thought that there were exceptions, where the JIT could optmize the virtual method call away. Why can't this happen on structs which know no inheritance and thus a method call can only point to one possible method, right? Or is that because you can implement an interface on it?
This is kind of a shame, since it will really make me think about using properties on performance critical stuff, yet using fields makes me feel dirty and I might as well write what I'm doing in C.
EDIT 3: I found this posting about the exact same subject. His end conclusion is that the property call did get optimized away. I also could've sworn that I've read plenty of times that simple getter/setter properties will get in-lined, despite being callvirt in the IL. So am I going insane?
EDIT 4: Reed Copsey posted the answer in a comment below:
Re: Edit3 - see my updated comment: I believe this is x86 JIT vs x64 JIT issues. the JIT in x64 is not as mature. I'd expect MS to improve this quickly as more 64 bit systems are coming online every day. – Reed Copsey
And my response to his answer:
Thanks, this is the answer! I tried forcing a x86 build and all methods are equally fast, and much faster than the x64. This is very shocking to me actually, I had no idea I was living in the stone age on my 64-bit OS.. I'll include your comment in my answer so it stands out better. – JulianR
Thanks everyone!
Edit 2:
I had another potential thought here:
You mentioned that you are running on x64. I've tested this same issue on x86, and seen the same performance when using auto-properties vs. fields. However, if you look around on Connect and mailing list/forum posts, there are many references online to the fact that the x64 CLR's JIT is a different code base, and has very different performance characteristics to the x86 JIT. My guess is this is one place where x64 is still lagging behind.
Also, FYI, the struct/method/etc thing fixed in .net 3.5sp1 was on the x86 side, and was the fact that method calls that took structs as a parameter would never be inlined on x86 prior to .net3.5sp1. That's pretty much irrelevant to this discussion on your system.
Edit 3:
Another thing: As to why XNA is using fields. I actually was at the Game Fest where they announced XNA. Rico Mariani gave a talk where he brought up many of the same points that are on his blog. It seems the XNA folks had similar ideas when they developed some of the core objects. See:
http://blogs.msdn.com/ricom/archive/2006/09/07/745085.aspx
Particularly, check out point #2.
As for why automatic properties are better than public fields:
They allow you to change the implementation in v2 of your class, and add logic into the property get/set routines as needed, without changing your interface to your end users. This can have a profound effect on your ability to maintain your library and code over time.
---- From original post - but discovered this wasn't the issue--------
Were you running a release build outside of VS? That can be one explanation for why things aren't being optimized. Often, if you are running in VS, even an optimized release build, the VS host process disables many functions of the JIT. This can cause performance benchmarks to change.
You should read this article by Vance. It goes into detail about why methods are not always inlined by the JIT'er even if it looks completely obvious that they should be.
http://blogs.msdn.com/vancem/archive/2008/08/19/to-inline-or-not-to-inline-that-is-the-question.aspx
Public fields are direct assignments
Properties are methods, then more code, insignificant but more.
XNA has to target the XBox 360, and the JIT in the .NET Compact Framework isn't as sophisticated as its desktop counterpart. The .NET CF JIT'er won't inline property methods.
Accessing a field is just a memory reference whereas using a property is actually invoking a method and includes the function call overhead. The reason to use properties rather than fields is to insulate your code from changes and provide better granularity over access. By not exposing your field directly you have greater control over how the access is done. Using automatic fields allows you to get the typically getter/setter behavior but builds in the ability to change this without a subsequent need for the changes to propagate to other parts of the code.
For example, say that you want to change your code so that access to a field is controlled by the current user's role. If you had exposed the field publicly, you'd have to touch every part of the code that accessed it. Exposing it through a property allows you to modify the property code to add your new requirement but doesn't result in unnecessary changes to any code that accesses it.