views:

182

answers:

3

Can I get Visual Studio to transform the built-in aliases into the System types? For example, if I define the following interface

public interface IExample
{
    Int32 DoWork(String input);
}

and use VS to automatically generate the interface, I get the built-in types.

public class Demo : IExample
{
    public int DoWork(string input) { }
}

I want those to automatically change to the System types

public class Demo : IExample
{
    public Int32 DoWork(String input) { }
}

I'm not looking for a full installable solution, just a starting point. Can I write a script in VS that's hooked to text completion or on-save? Should I write an add-on that has a context menu item for projects - 'Convert aliases to System types'?


Note: I prefer the System types because they are formatted by VS like other types. Built-in aliases are formatted like keywords. Also, it's a coding style guideline at my current job.

Update: It's clear from MS that existing VS code-generation will always produce the built-in aliases.

+1  A: 

The two types mean exactly the same thing, there is no danger that one will mean something different.

The only difference is how they look, if thats important to you, you can write a macro that will replace any built-in-aliases with System types.

Binary Worrier
It's not entirely accurate to say they're the same. One requires a using statement (Int32 requires you to import System) whereas the other is an alias to the full type name (int = System.Int32).
Kent Boogaart
True, but under the covers the CLR treats them as exactly the same thing. The only difference here is how pretty one version is over the other, and as we all know, "beauty is in the eye of the beholder"
Binary Worrier
So.. they're the same but they are not the same. Let's just assume they are different for sanity's sake.
Joe Philllips
A: 

If you build the program on the same (32bit) PC there's no difference.

PoweRoy
There IS a difference. In the source. Forget the binaries. Perhaps ajmastrean has stringent coding guidelines he must adhere to.
Kent Boogaart
BTW, architecture has nothing to do with it. int is an alias for System.Int32, so the resultant binaries will be equivalent no matter which style you use on whatever architecture.
Kent Boogaart
@kent Boogaart:So when I build an application on a 64bit pc, int would still be int32? I thought it would be int64.
PoweRoy
No, int is an alias for Int32 so it is guaranteed to be 32 bits. long is an alias for Int64 so is guaranteed to be 64 bits.
Kent Boogaart
A: 

The built-in aliases are formatted like keywords because the are keywords. The compiler performs the translation from language data type keywords to underlying CLR type for you.

There is nothing in Visual Studio that will automatically do this translation for you so you will need to write your own utility that will do this. There are several different ways to do this - you can write a macro or a VS plugin - but (IMHO) none of them will be trivial to write and ensure correctness.

You state that this is both personal preference and coding style requirements. I think the formatting concerns seem misplaced. It is generally easier/cleaner/preferred to use the language aliases instead of the CLR types. Other than the syntax coloring in the text editor there is absolutely no difference between the two and really no reasons to use the CLR names for your types. What are the reasons (if any) given in the coding style requirements for forcing the use of the CLR types instead of the language aliases?

Scott Dorman
(1) Capitalization of types is PascalCase. The System types meet this requirement. The aliases do not.(2) When customizing formatting (changing color scheme), the System types adhere to rules applied to the System types. The built-in types do not.
Anthony Mastrean
@ajmastrean: I would definately argue that those are not reasonable to enforce in a coding standard, especially #2. Color schemes absolutely do not belong in a coding standard. As far as the capitalization rules go, they should only be applied to types that are either user-defined (your own classes) or those types provided by the .NET Framework itself that do not have corresponding or direct language support. The language provides direct support for these types and that should be utilized over the BCL type names.
Scott Dorman
I'm under no duress to meet these requirements. But I am interested to know if they're attainable. I'm surprised at the negative responses toward System types!
Anthony Mastrean
As long as you don't consider the C# aliases as types, yes they are achievable, although #2 really shouldn't apply to a coding style. I wouldn't say there are negative responses towards System types but rather that there is no benefit in using them over the aliases.
Scott Dorman