C # - StyleCop - SA1121: UseBuiltInTypeAlias ​​- Правила читабельности - PullRequest
34 голосов
/ 14 мая 2011

Не найдено в справочном руководстве StyleCop, в SO и Google, вот оно;)

Во время использования StyleCop у меня есть предупреждение:

SA1121 - UseBuiltInTypeAlias ​​- Правила читабельности

Код использует один из основных C # типы, но не использует встроенный псевдоним для типа.

Вместо того, чтобы использовать имя типа или полное имя типа, встроенные псевдонимы для этих типов всегда следует использовать: bool, byte, char, десятичный, двойной, короткий, int, long, object, sbyte, float, string, ushort, uint, ulong.

так что String.Empty неверно (зависит от вышеуказанных правил), а string.Empty - хорошо.

Почему лучше использовать встроенные псевдонимы? Могут ли String. Int32, Int64 (и т. Д.) Что-то усложнить в коде в особых сценариях?

Ответы [ 6 ]

54 голосов
/ 14 мая 2011

Просто чтобы уточнить: не все согласны с авторами StyleCop. Win32 и .NET гуру Джеффри Рихтер пишет в своей превосходной книге CLR через C # :

В спецификации языка C # говорится: «По стилю использование ключевого слова предпочтительнее использование полного имени типа системы ». Я не согласен с языковой спецификацией; я предпочитаю использовать имена типов FCL и полностью избегать имен примитивных типов. На самом деле, я хочу, чтобы компиляторы даже не предлагали примитивных имен типов и заставляли разработчиков использовать FCL вместо этого введите имена. Вот мои причины:

  • Я видел, что некоторые разработчики были сбиты с толку, не зная, использовать ли string или Строка в их коде. Потому что в C # строка (ключевое слово) отображается именно на System.String (тип FCL), различий нет, и их можно использовать. Так же, Я слышал, что некоторые разработчики говорят, что int представляет 32-разрядное целое число, когда приложение работает в 32-битной ОС и представляет 64-битное целое число, когда приложение работает на 64-битной ОС. Это утверждение абсолютно неверно: в C # int всегда отображается System.Int32 , и, следовательно, он представляет собой 32-разрядное целое число независимо от ОС код работает Если программисты будут использовать Int32 в своем коде, то этот потенциал путаница также устранена.

  • В C # long отображается на System.Int64 , но на другом языке программирования, long может отображаться на Int16 или Int32 . Фактически, C ++ / CLI обрабатывает long как Int32 . Кто-то, читающий исходный код на одном языке, может легко неверно истолковать намерение, если он или она привыкли к программированию на другом языке программирования. Фактически, большинство языков даже не воспринимают long как ключевое слово и не будут компилировать код который использует это.

  • В FCL есть много методов, имена которых являются частью имен их методов. За Например, тип BinaryReader предлагает такие методы, как ReadBoolean , ReadInt32 , ReadSingle и т. Д., А тип System.Convert предлагает такие методы, как ToBoolean , ToInt32 , ToSingle и так далее. Хотя это законно, чтобы написать следующее код, строка с float кажется мне очень неестественной, и не очевидно, что строка правильно:

    BinaryReader br = new BinaryReader(...);
    float val = br.ReadSingle(); // OK, but feels unnatural
    Single val = br.ReadSingle(); // OK and feels good
    
  • Многие программисты, использующие исключительно C #, склонны забывать, что другие программы языки могут использоваться против CLR, и из-за этого C # -измы проникают в код библиотеки классов. Например, FCL Microsoft почти исключительно написан на C # и разработчики из команды FCL теперь внедрили в библиотеку такие методы, как Array 's GetLongLength , который возвращает значение Int64 , которое long в C #, но не на других языках (например, C ++ / CLI). Другой пример - System.Linq.Enumerable LongCount метод.

20 голосов
/ 14 мая 2011

Это действительно усложнило бы код, если бы у вас были собственные типы String, Int32 и т. Д., Которые могли бы в итоге использоваться вместо System.* - и, пожалуйста, не делайте этого!В конечном итоге это личное предпочтение.Я использую псевдонимы везде, но я знаю, что некоторые люди (например, Джеффри Рихтер) советуют никогда , используя их.Вероятно, неплохо быть последовательным, вот и все.Если вам не нравится это правило StyleCop, отключите его.

Обратите внимание, что имена методов и т. Д. Должны использовать имя платформы, а не псевдоним, чтобы не зависеть от языка.Это не так важно для частных / внутренних членов, но вы можете использовать те же правила для частных методов, что и для открытых.

1 голос
/ 14 мая 2011

Потому что встроенный псевдоним - более естественный способ выражения концепции на этом языке.

Некоторые культуры говорят о футболе, другие говорят о футболе.Какой из них более уместен, зависит от контекста.

0 голосов
/ 25 июня 2013

Может помочь аналогия: строка - System.String , как мушкет - для винтовки. string является реликвией старого языка и предоставляется старым программистам.C # не имеет «встроенных» типов данных, и эти псевдонимы предназначены для поколения программистов на «C», у которых есть проблемы с этой концепцией.

0 голосов
/ 02 июня 2011

Менее запутанно? Мне кажется очень неудобным для базового типа данных, который традиционно является просто значением, включать статические функции. Я понимаю, что использовать эквивалент базового типа данных, если вы просто сохраняете значение, но для доступа к членам класса, очень неудобно ставить точку (.) После имени базового типа.

0 голосов
/ 14 мая 2011

Это правило StyleCop предполагает, что использование псевдонимов вводит меньше путаницы в так называемого «среднестатистического пользователя».Который знает, например, тип 'long', но почему-то страшно типа 'System.Int64' и запутывается, затем видит его.Лично я думаю, что важно просто быть согласованным в вашем стиле кода, невозможно удовлетворить всех .

...