Geek Answers Handbook

Using the "Common Type System" as the coding standard

One of our standard coding rules:

  • Use a generic type system. For example, use Int32 instead of int .

I have not seen such a rule before, although our other recommendations are roughly based on the Microsoft Design Rules Development Guide . It seems that the Common Type System does not exist.

It seems inconvenient to me, because I have to rewrite the default refactoring of Visual Studio and ReSharper to convert string to string , float to Single , long to Int64 , etc. It has also been applied rather inconsistently (for example, not for object to object ), perhaps due to its inconvenience, and there is no StyleCop rule to test its application.

So I wonder why this rule was set. Could there be a good reason? Are there any cases (possibly historical) where Int32 should be used instead of int for example?

Update

I read the recommended Framework Development Guides (2006, Cwalina and Adams), section 3.2.3. Avoid language specific names and they state that “it is important to avoid using these language type names in identifiers ” (my emphasis). Agreed.

However, Jeffrey Richter then goes on to comment: "I take this a step further and never use the alias names of the language [as it] does not add anything useful and introduces a huge mess." Perhaps this is where this rule comes from?

+4
source share
4 answers

I suspect this rule comes from a misinterpretation of the guidelines.

Recommendations under General naming conventions :

Use the common name of the CLR language, and not the name for a particular language, in rare cases when the identifier does not have a semantic value that goes beyond its type.

For example, a method that converts data to Int16 should have the name ToInt16 , not ToShort , because Short is the name of the language type for Int16 .

If you create identifiers that contain the type as part of their name, for example, the set of SomeType ReadSomeType() methods, then you should use the actual type name for SomeType , not a C # alias.

A programmer who works in another language can associate different values ​​with a type. For example, if you had the ReadFloat() method, a C # programmer would assume that it returns System.Single , and a F # programmer would assume that it returns System.Double . Therefore, you should call it ReadSingle or ReadDouble .

This rule does not apply to simple type names that you use to indicate the type of your code. The programmer consuming your library will never see what you used.

+3
source

Recommendation for class library developers regarding public names:

In rare cases when an identifier does not have a semantic value beyond its type, use the name of the common execution language (CLR) type, rather than the name for a particular language.

However, I never knew this was a recommendation when it comes to, for example, internal variables.

+2
source

I can’t come up with any resonance for this, but I must warn about this by saying that I used version 3.5+ of the framework and maybe some historical reason that I don’t know about. Basically, simple types ( int ) are just aliases for the predefined types struct ( System.Int32 ). Some points that may help you establish that reans are not needed for this come directly from the C # laungage manual ...

"Simple types are identified by reserved words ( sbyte , byte , ..., int , long , ..., float , double ), but these reserved words are just aliases for the predefined struct types in the System namespace ( System.SByte , System.Byte , ..., System.Int32 , etc.). Since the simple type of aliases is a struct , each simple type has, for example, int has members declared in System.Int32 , and members inherited from System.Object , and expressions of type

 int i = int.MaxValue; // System.int32.MaxValue constant. string s = i.ToString(); // System.Int32.ToString() instance method.

allowed. "

This goes on, but the general point is that simple types are just aliases - this. There is no reason to do what you describe, something never.

Hope this helps.

0
source

This rule makes sense if you are working in a multilingual environment or are developing an infrastructure or shared library.

Firts, this ensures that all types used are supported by CLS (see 1 ). Secondly, this avoids the possible confusion caused by the same type that has different names in different .Net languages.

This section is discussed in the book Framework Design Guides: Conventions, Idioms, and Templates for Reusable .Net Libraries, which I highly recommend.

General language specification

0
source

More articles:


All Articles