Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
«AV1520 Используйте var только тогда, когда тип переменной очевиден» ссылается на статью Липперта где написано практически обратное: НЕ использовать «var» только в редких случаях где совершенно необходимо знать точный тип.
Не вводите в заблуждение, в статье Ерика Липперта именно это и написано
Summing up, my advice is:
•Use var when you have to; when you are using anonymous types.
•Use var when the type of the declaration is obvious from the initializer, especially if it is an object creation. This eliminates redundancy.
•Consider using var if the code emphasizes the semantic «business purpose» of the variable and downplays the «mechanical» details of its storage.
•Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
•Use descriptive variable names regardless of whether you use «var». Variable names should represent the semantics of the variable, not details of its storage; «decimalRate» is bad; «interestRate» is good.
Мой перевод:
Суммируя, мой совет таков:
• Используйте var когда вас к этому принуждают; когда вы используете анонимные типы.
• Используйте var когда тип объявления очевиден из инициализатора, особенно если это создание объекта. Это устраняет избыточность.
• Рассмотрите использование var если код подчёркивает смысловое «назначение» переменной и скрывает «механические» детали её хранения.
•Используйте точные типы если это необходимо для понимания и поддержки кода.
•Используйте описательные имена независимо от использования «var». Имена переменных должны представлять смысл переменной, а не детали её хранения; «decimalRate» — плохо; «interestRate» — хорошо.
Из перечисленных пунктов только один рекомендует точные типы. Остальные варианты — в пользу var. Ну и собственно вся статья на 90% о том, что var использовать почти всегда хорошо.
Да чего тут спорить, 2015 год на дворе? Все уже давно используют var везде, смысл опираться на рекомендации из 2011? Даже в С++ народ привыкает а auto.
В статье не утверждается, что
В первую очередь мы пишем код для людей. И этот код должен быть понятным. Следовательно, использовать
var нужно использовать в 90% случаев, и она не противоречит правилу AV1520. Да, статья про неявную типизацию, но на этом все. В первую очередь мы пишем код для людей. И этот код должен быть понятным. Следовательно, использовать
var нужно тогда, когда тип нам не важен и мы можем им пренебречь в пользу читаемости. Неудобно, когда приходится заглядывать в функцию, чтобы понять, какой тип присваивается переменной по результату выполнения этой функции. Неявная типизация — это хорошо, но злоупотреблять не стоит. 
При чем тут var и неявная типизация? Var к неявной типизации через анонимные типы притягивается как лифчик на слона, в остальном — это о другом.
Серьёзно? Единственный способ понять тип, скрываемый за var это посмотреть на сигнатуру метода? Пора использовать возможности вашего редактора:
Не проще ли, когда для этого достаточно взгляда?
ReadableMayDomainEntityWithLongNameCollection myEntities = new ReadableMayDomainEntityWithLongNameCollection();
Как-то так…
Рекомендация AV1520 гласит, что в этом случае лучше использовать var т.к. тип переменной очевиден из инициализатора. Даже пример приведен. Липперт этот случай также упомянул в своей статье. Не утрируйте.
В текущих реалиях я придерживаюсь мнения что var надо использовать везде, где можно.
Этот код стайл не учитывает еще всякие штуки как JetBrains.Annotations.
Плюс Async не используется для имен экшенов контроллера в MVC.
У нас сейчас взят за основу вот этот гайдлайг для веб проектов: https://github.com/aspnet/Home/wiki/Engineering-guidelines. Может добавите чего оттуда :)
Этот код стайл не учитывает еще всякие штуки как JetBrains.Annotations.
Плюс Async не используется для имен экшенов контроллера в MVC.
У нас сейчас взят за основу вот этот гайдлайг для веб проектов: https://github.com/aspnet/Home/wiki/Engineering-guidelines. Может добавите чего оттуда :)
В первую очередь мы пишем код для людей.
А людей в 95% случаев конкретный тип не интересует.
var A = B;
Мне вполне достаточно, что тип A такой же, как и у B.
Напротив, явное указание типа в данном случае добавит шума в коде и нередко заставит сделать лишнюю правку при рефакторинге.
В «AV1220 Всегда проверяйте делегат обработчика события на null» неверная подсказка. Указанный метод «чтобы список делегатов не был совсем пустым» не поможет когда сначала подписались и потом отписались. После отписки последнего подписчика опять будет null и без проверки всё равно не обойтись.
В «AV1553 Используйте необязательные аргументы только для того, чтобы заменять перегрузки» судя по всему опечатка в ссылке «согласно правилу AV1235». Вместо AV1235 должно быть AV1135.
Что-то рекомендации какие-то для совсем плохо соображающих индусов…
AV1535 Всегда используйте конструкции if, else, while, for, foreach и case с фигурными скобкамиДа, да и еще раз да! Без скобок эти операторы создают хорошую почву для багов, плюс ухудшается читаемость кода.
AV1540 Старайтесь избегать нескольких объявлений returnДостаточно спорная рекомендация. Несколько return это нормально, только надо располагать их как можно раньше в методе.
AV1575 Не оставляйте закомментированные участки кодаНе соглашусь, нередко закомментированный код — лучшее решение. Однако нужно всегда комментировать, почему тот или иной код закомментирован.
AV1130 Возвращайте IEnumerable или ICollection вместо какой-либо конкретной коллекции И ловите проблемы с memory-traffic из-за того что компилятор не может использовать value-type enumerator при перечислении, да.
AV1025 — на этом построен целый паттерн разработки, успешно функционирующий во множестве современных игр. Component Based подход же. Компоненты не должны содержать методов и какой либо логики, обработка данных происходит в специальной системе которая её и реализует.
AV1200 — есть вещи, где бросая исключения налево и направо можно превратить код в огромную проверку этих самых исключений во множестве мест, когда как можно их все заменить одним статусным сообщением. Например ошибку ввода пользователем неправильных или нежелательных данных, которую тут же и вернуть пользователю по стеку. Может я конечно не прав, но я вообще не очень люблю исключения бросать и обрабатывать, мне эта система кажется плохо продуманной и чуждой.
Ну и еще не согласен с AV1540, AV1575 и частично AV1130, а также форматированием пробелами, скобками на следующей строке и т.д. (фломастеры)
AV1200 — есть вещи, где бросая исключения налево и направо можно превратить код в огромную проверку этих самых исключений во множестве мест, когда как можно их все заменить одним статусным сообщением. Например ошибку ввода пользователем неправильных или нежелательных данных, которую тут же и вернуть пользователю по стеку. Может я конечно не прав, но я вообще не очень люблю исключения бросать и обрабатывать, мне эта система кажется плохо продуманной и чуждой.
Ну и еще не согласен с AV1540, AV1575 и частично AV1130, а также форматированием пробелами, скобками на следующей строке и т.д. (фломастеры)
Комплексное выражение — сложное выражение! Чего ж огород городить.
Опциональный параметр — необязательный…
В целом, советы грамотные, но таких есть вагон и маленькая тележка. Почему вдруг предлагается следовать именно советам от какой-то Авивы?
Опциональный параметр — необязательный…
В целом, советы грамотные, но таких есть вагон и маленькая тележка. Почему вдруг предлагается следовать именно советам от какой-то Авивы?
AV1135
А чем в общем случае null строка в качестве результата хуже, чем пустая строка? Если пустая строка символизирует что-то определенное (например то, что что-нибудь не найдено), то уж лучше null, а еще лучше использовать AV1140 с null object или метод с out параметром.
А чем в общем случае null строка в качестве результата хуже, чем пустая строка? Если пустая строка символизирует что-то определенное (например то, что что-нибудь не найдено), то уж лучше null, а еще лучше использовать AV1140 с null object или метод с out параметром.
В случае с null можно получить NullReferenceException. Использование паттерна Null Object может быть хорошей альтернативой
NullReferenceException хотя бы виден. А string.Empty ничем не отличается от любой другой строки: без вдумчивого чтения метода догадаться, что его нужно определенным образом обрабатывать, шансов мало.
Речь не идет об исключительной ситуации. Речь о ситуации, когда возвращаемый результат может быть пустым. Например, метод вернул пустой список пользователей.
Эта рекомендация напрямую соотносится с «Правилом наименьшего удивления» (The Principle of Least Surprise). Если метод возвращает строку то, как ни странно, он и должен всегда возвращать строку. Если коллекцию — результатом выполнения всегда должна быть коллекция. Код должен иметь то поведение, которое от него ожидают
Эта рекомендация напрямую соотносится с «Правилом наименьшего удивления» (The Principle of Least Surprise). Если метод возвращает строку то, как ни странно, он и должен всегда возвращать строку. Если коллекцию — результатом выполнения всегда должна быть коллекция. Код должен иметь то поведение, которое от него ожидают
AV1250 Вычисляйте результат LINQ-запроса до того, как вернуть его
… и получайте N вместо 1 по памяти на пустом месте.
AV1025 Классы должны иметь состояние и поведение
Это прямо противоречит принципу единственной ответственности.
AV1540 Старайтесь избегать нескольких объявлений return
Неужели дополнительные уровни вложенности if else читаются лучше? Цикломатическая сложность с этим не согласна.
AV1702 Для каждого элемента языка используйте соответствующую нотацию
И как в вашем случае отличить присваивание локальной переменной (низкий уровень ответственности) или присваивания полю(высокий уровень ответственности)?
Всегда используйте конструкции if, else, do, while, for и foreach с парными фигурными скобками, даже если без этого можно обойтись
В окружении парных скобок особенно элегантно смотрится одиночный return (а также break, continue, throw...)
AV2406 Располагайте члены класса в строго определенном порядке
Приватные поля и константы (в #region)
Публичные константы
Публичные read-only статические поля
Фабричные методы
Конструкторы и финализаторы
События
Публичные свойства
Прочие методы и приватные свойства в порядке их вызова
Наиболее важные вещи для класса — его входы и выходы, то есть реализуемые интерфейсы и зависимости.
Отсюда логично вперед ставить публичные члены, причем на первое место из них конструктор (или фабричный метод, если публичного конструктора нет). А вот поля и т.п. нужны только тем, кому интересны потроха класса
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рекомендации по написанию кода на C# от Aviva Solutions