Is it possible to make Visual Studio to display tooltips on operators?
The following image demonstrates a tooltip hint for a function, but it does not work for operators.
Operators usually have simple type specs like 'T -> 'T -> 'T, but such hints can be useful for custom ones.
Following Daniel's suggestion, I'm posting a workaround that I've been using for myself.
The workaround is only partially helpful, and I'm still looking for any better ideas.
let (!><) a = ()
let z1 = op_BangGreaterLess 5
This code is fully valid, since an operator expression generates a function with a compiler-generated name. See this MSDN article, section "Overloaded Operator Names" for complete list of operator names.
Good news is that op_BangGreaterLess supports IntelliSense hints and it also supports "Go to Definition" (F12) command of IDE, pointing to an original operator declaration.
Bad news is that IntelliSense does not allow rapid entry of the full operator name (Ctrl+Space), so you have to type the entire name manually.
I'm afraid this is not possible (and even in Visual Studio 2012, I don't get tooltips for operators).
I suppose this could be implemented, but as you say, operators usually have simple types. When using custom operators, these should be probably simple enough so that people can use them without looking at their type (or the associated XML documentation). Otherwise, it might be better to use a named function.
That said, if you're using F# Interactive, then you can easily use that to explore the operator type:
> (!><);;
val it : ('a -> unit) = <fun:clo#2>
If I cannot use F# Interactive, I usually define a simple dummy symbol to get the IntelliSense:
let dummy () = (!><)
Note that I added unit argument to define a function and avoid value restriction error.
Is it possible to search or filter intellisense in visual studio?
Basically i know there is an enum in the project that contains 'column', but the enum doesnt begin with 'c'.
There has been lots of times where id rather not scroll through the hundreds (if not thousands) of valid objects it gives me.
I wonder if the real answer here is (and I won't be surprised to be voted down for this) that your enum isn't properly named. If it was then I'd expect the name to be obvious in the use context, may be consider renaming the enum?
You can search in Class View. Type "column" and hit enter.
Visual Studio 2010 changes all of this, giving you multiple very easy ways to do this type of search quickly.
If you're using ReSharper, you can use "Go To Symbol..." and type "column", and it will give you all symbols (types, properties, fields, methods, etc) that match.
Otherwise your best bet is to use the Object Browser and search.
I really don't know about doing that in intellisense itself, but assuming the objective is to actually find a member whose name you don't remember, you can write a small utility for that purpose using the underlying mechanism intellisense uses, reflection.
Open the Object Browser under View menu. From there, you can search within all the language constructs available to you.
I have a VS project with an IntermediateDirectory like this: "....\temp\$(SolutionName)\$(ProjectName)".
I can read this value using a macro or add in, however, I would need the actual directory to manipulate files there. Right now, I manually replace the "$(SolutionName)" and "$(ProjectName)" with the respective values, which works fine but might become complicated when different macros or even user macros from property sheets are used.
So my question is:
Does the Visual Studio API have a built in function to expand macros like these? Or is there some other elegant solution?
There is an elegant solution! But I only know the one that applies to C++ projects.
Assuming you're in a C# add-in:
// Get the main project from the first startup project
VCProject vcMainProject = (VCProject)(_applicationObject.Solution.SolutionBuild.StartupProjects as IVCCollection).Item(1);
Project mainProj = (Project)_vcMainProject .Object;
// Get the configuration we'll be using
IVCCollection cfgs = (IVCCollection)_vcMainProject .Configurations;
VCConfiguration vcCfg = (VCConfiguration) cfgs.Item(mainProj.ConfigurationManager.ActiveConfiguration.ConfigurationName + "|" + mainProj.ConfigurationManager.ActiveConfiguration.PlatformName);
string finalString = vcCfg.Evaluate("....\temp\$(SolutionName)\$(ProjectName)");
You can also check out this page:
http://msdn.microsoft.com/en-us/library/czt44k0x%28VS.71%29.aspx
If you're not using this for C++, there should be a similar interface for the Project, Configuration, and Solution classes provided for other languages (C# and VB).
As far as i know, there is no API available that will expand those macro values. Although it shouldn't be too hard to write a quick and dirty implementation that deals with only the values that you care about.
For instance, in this case you only care about 2 values (SolutionName and ProjectName). If these are the values you are primarily interested in use a simple search and replace with the best values.
Yes this is a sub-optimal solution. But it may help to unblock your progress.
No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.
But what kind of prefix do you use?
I have been working on projects where we used m_ as prefix, on other projects we used an underscore only (which I personally don't like, because an underscore only is not demonstrative enough).
On another project we used a long prefix form, that also included the variable type. mul_ for example is the prefix of a member variable of type unsigned long.
Now let me know what kind of prefix you use (and please give a reason for it).
EDIT: Most of you seem to code without special prefixes for member variables! Does this depend on the language? From my experience, C++ code tends to use an underscore or m_ as a prefix for member variables. What about other languages?
No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.
I dispute this claim. It's not the least bit necessary if you have half-decent syntax highlighting. A good IDE can let you write your code in readable English, and can show you the type and scope of a symbol other ways. Eclipse does a good job by highlighting declarations and uses of a symbol when the insertion point is on one of them.
Edit, thanks slim: A good syntax highlighter like Eclipse will also let you use bold or italic text, or change fonts altogether. For instance, I like italics for static things.
Another edit: Think of it this way; the type and scope of a variable are secondary information. It should be available and easy to find out, but not shouted at you. If you use prefixes like m_ or types like LPCSTR, that becomes noise, when you just want to read the primary information – the intent of the code.
Third edit: This applies regardless of language.
I do not use any prefix at all. If I run into danger of mixing up local variables or method parameters with class members, then either the method or the class is too long and benefits from splitting up.
This (arguably) not only makes the code more readable and somewhat "fluent", but most importantly encourages well structured classes and methods. In the end, it thus boils down to a completely different issue than the prefix or no-prefix dillema.
UPDATE: well, taste and preferences change, don't they.. I now use underscore as the prefix for member variables as it has proven to be beneficial in recognizing local and member variables in the long run. Especially new team members sometimes have hard time when the two are not easily recognizable.
None. I used to use underscore, but was talked out of it on a project where the others didn't like it, and haven't missed it. A decent IDE or a decent memory will tell you what's a member variable and what isn't. One of the developers on our project insists on putting "this." in front of every member variable, and we humour him when we're working on areas of code that are nominally "his".
Underscore only.
In my case, I use it because that's what the coding standards document says at my workplace. However, I cannot see the point of adding m_ or some horrible Hungarian thing at the beginning of the variable. The minimalist 'underscore only' keeps it readable.
It's more important to be consistent than anything, so pick something you and your teammates can agree upon and stick with it. And if the language you're coding in has a convention, you should try to stick to it. Nothing's more confusing than a code base that follows a prefixing rule inconsistently.
For c++, there's another reason to prefer m_ over _ besides the fact that _ sometimes prefixes compiler keywords. The m stands for member variable. This also gives you the ability disambiguate between locals and the other classes of variables, s_ for static and g_ for global (but of course don't use globals).
As for the comments that the IDE will always take care of you, is the IDE really the only way that you're looking at your code? Does your diff tool have the same level of quality for syntax hilighting as your IDE? What about your source control revision history tool? Do you never even cat a source file to the command line? Modern IDE's are fantastic efficiency tools, but code should be easy to read regardless of the context you're reading it in.
I prefer using this keyword.
That means this.data or this->data instead of some community-dependent naming.
Because:
with nowadays IDEs typing this. popups intellinsense
its obvious to everyone without knowing defined naming
BTW prefixing variables with letters to denote their type is outdated with good IDEs and reminds me of this Joel's article
We use m_ and then a slightly modified Simonyi notation, just like Rob says in a previous response. So, prefixing seems useful and m_ is not too intrusive and easily searched upon.
Why notation at all? And why not just follow (for .NET) the Microsoft notation recommendations which rely upon casing of names?
Latter question first: as pointed out, VB.NET is indifferent to casing. So are databases and (especially) DBAs. When I have to keep straight customerID and CustomerID (in, say, C#), it makes my brain hurt. So casing is a form of notation, but not a very effective one.
Prefix notation has value in several ways:
Increases the human comprehension of code without using the IDE. As in code review -- which I still find easiest to do on paper initially.
Ever write T-SQL or other RDBMS stored procs? Using prefix notation on database column names is REALLY helpful, especially for those of us who like using text editors for this sort of stuff.
Maybe in short, prefixing as a form of notation is useful because there are still development environments where smart IDEs are not available. Think about the IDE (a software tool) as allowing us some shortcuts (like intellisense typing), but not comprising the whole development environment.
An IDE is an Integrated Development Environment in the same way that a car is a Transportation Network: just one part of a larger system. I don't want to follow a "car" convention like staying on marked roads, when sometimes, its faster just to walk through a vacant lot. Relying on the IDE to track variable typing would be like needing the car's GPS to walk through the vacant lot. Better to have the knowledge (awkward though it may be to have "m_intCustomerID") in a portable form than to run back to the car for every small change of course.
That said, the m_ convention or the "this" convention are both readable. We like m_ because it is easily searched and still allows the variable typing to follow it. Agreed that a plain underscore is used by too many other framework code activities.
Using C#, I've moved from the 'm_'-prefix to just an underscore, since 'm_' is an heritage from C++.
The official Microsoft Guidelines tells you not to use any prefixes, and to use camel-case on private members and pascal-case on public members. The problem is that this collides with another guideline from the same source, which states that you should make all code compatible with all languages used in .NET. For instance, VB.NET doesn't make a difference between casings.
So just an underscore for me. This also makes it easy to access through IntelliSense, and external code only calling public members don't have to see the visually messy underscores.
Update: I don't think the C# "this."-prefix helps out the "Me." in VB, which will still see "Me.age" the same as "Me.Age".
It depends on which framework I'm using! If I'm writing MFC code then I use m_ and Hungarian notation. For other stuff (which tends to be STL/Boost) then I add an underscore suffix to all member variables and I don't bother with Hungarian notation.
MFC Class
class CFoo
{
private:
int m_nAge;
CString m_strAddress;
public:
int GetAge() const { return m_nAge; }
void SetAge(int n) { m_nAge = n; }
CString GetAddress() const { return m_strAddress;
void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }
};
STL Class
class foo
{
private:
int age_;
std::string address_;
public:
int age() const { return age_; }
void age(int a) { age_ = a; }
std::string address() const { return address_; }
void address(const std::string& str) { address_ = str; }
};
Now this may seem a bit odd - two different styles - but it works for me, and writing a lot of MFC code that doesn't use the same style as MFC itself just looks ugly.
I prefix member variables with 'm' and parameters (in the function) with 'p'. So code will look like:
class SomeClass {
private int mCount;
...
private void SomeFunction(string pVarName) {...}
}
I find that this quickly tells you the basic scope of any variable - if no prefix, then it's a local. Also, when reading a function you don't need to think about what's being passed in and what's just a local variable.
It really depends on the language.
I'm a C++ guy, and prefixing everything with underscore is a bit tricky. The language reserves stuff that begins with underscore for the implementation in some instances (depending on scope). There's also special treatment for double underscore, or underscore following by a capital letter. So I say just avoid that mess and simply choose some other prefix. 'm' is ok IMO. 'm_' is a bit much, but not terrible either. A matter of taste really.
But watch out for those _leadingUnderscores. You'll be surprised how many compiler and library internals are so named, and there's definitely room for accidents and mixup if you're not extremely careful. Just say no.
Most of the time, I use python. Python requires you to use self.foo in order to access the attribute foo of the instance of the current class. That way, the problem of confusing local variables, parameters and attributes of the instance you work on is solved.
Generally, I like this approach, even though I dislike being forced to do it. Thus, my ideal way to do thos is to not do it and use some form of attribute access on this or self in order to fetch the member variables. That way, I don't have to clutter the names with meta-data.
I'm weirdo and I prefix member variables with initials from the class name (which is camel-cased).
TGpHttpRequest = class(TOmniWorker)
strict private
hrHttpClient : THttpCli;
hrPageContents: string;
hrPassword : string;
hrPostData : string;
Most of the Delphi people just use F.
TGpHttpRequest = class(TOmniWorker)
strict private
FHttpClient : THttpCli;
FPageContents: string;
FPassword : string;
FPostData : string;
If the language supports the this or Me keyword, then use no prefix and instead use said keyword.
another trick is naming convention:
All member variables are named as usual, without any prefix (or 'this.' is it is usual to do so in the project)
But they will be easily differentiated from local variable because in my project, those local variables are always named:
aSomething: represents one object.
someManyThings: list of objects.
isAState or hasSomeThing: for boolean state.
Any variable which does not begin by 'a', 'some' or 'is/has' is a member variable.
Since VB.NET is not case-sensitive, I prefix my member variables with an underscore and camel case the rest of the name. I capitalize property names.
Dim _valueName As Integer
Public Property ValueName() As Integer
I'm with the people that don't use prefixes.
IDEs are so good nowadays, it's easy to find the information about a variable at a glance from syntax colouring, mouse-over tooltips and easy navigation to its definition.
This is on top of what you can get from the context of the variable and naming conventions (such as lowerCamelCase for local variables and private fields, UpperCamelCase for properties and methods etc) and things like "hasXXXX" and "isXX" for booleans.
I haven't used prefixes for years, but I did used to be a "this." prefix monster but I've gone off that unless absolutely necessary (thanks, Resharper).
A single _ used only as a visual indicator. (C#)
helps to group members with intellisense.
easier to spot the member variables when reading the code.
harder to hide a member variable with a local definition.
_ instead of this.
I use _ too instead of this. because is just shorter (4 characters less) and it's a good indicator of member variables. Besides, using this prefix you can avoid naming conflicts. Example:
public class Person {
private String _name;
public Person(String name) {
_name = name;
}
}
Compare it with this:
public class Person {
private String name;
public Person(String name) {
this.name = name;
}
}
I find the first example shorter and more clear.
It kinda depends what language you're working in.
In C# you can reference any member using the 'this' prefix, e.g. 'this.val', which means no prefixes are needed. VB has a similar capability with 'Me'.
In languages where there is a built-in notation for indicating member access I don't see the point in using a prefix. In other languages, I guess it makes sense to use whatever the commonly accepted convention is for that language.
Note that one of the benefits of using a built-in notation is that you can also use it when accessing properties and methods on the class without compromising your naming conventions for those (which is particularly important when accessing non-private members). The main reason for using any kind of indicator is as a flag that you are causing possible side effects in the class, so it's a good idea to have it when using other members, irrespective of whether they are a field/property/method/etc.
I use camel case and underscore like many here. I use the underscore because I work with C# and I've gotten used to avoiding the 'this' keyword in my constructors. I camel case method-scoped variants so the underscore reminds me what scope I'm working with at the time. Otherwise I don't think it matters as long as you're not trying to add unnecessary information that is already evident in code.
I've used to use m_ perfix in C++ but in C# I prefer just using camel case for the field and pascal case for its property.
private int fooBar;
public int FooBar
{
get { return fooBar; }
set { fooBar = value; }
}
I like m_ but as long as convention is used in the code base is used I'm cool with it.
Your mul_ example is heading towards Charles Simonyi's Apps Hungarian notation.
I prefer keeping things simple and that's why I like using m_ as the prefix.
Doing this makes it much easier to see where you have to go to see the original declaration.
I tend to use m_ in C++, but wouldn't mind to leave it away in Java or C#. And it depends on the coding standard. For legacy code that has a mixture of underscore and m_ I would refactor the code to one standard (given a reasonable code size)
I use #.
:D j/k -- but if does kind of depend on the language. If it has getters/setters, I'll usually put a _ in front of the private member variable and the getter/setter will have the same name without the _. Otherwise, I usually don't use any.
For my own projects I use _ as a postfix (as Martin York noted above, _ as a prefix is reserver by the C/C++ standard for compiler implementations) and i when working on Symbian projects.
In Java, one common convention is to preface member variables with "my" andUseCamelCaseForTheRestOfTheVariableName.
None if it's not necessary, single underscore otherwise. Applies for python.
If it is really necessary to prefix member variables, I would definitely prefer m_ to just an underscore. I find an underscore on its own reduces readability, and can be confused with C++ reserved words.
However, I do doubt that member variables need any special notation. Even ignoring IDE help, it isn't obvious why there would be confusion between what is a local and what is a member variable.