Предложения кода Resharper, делающим менее читаемый код?

Я соглашаюсь, что первая версия Вашего кода более читаема.

я нашел предложения Resharper в этих случаях к не всегда быть полезным, хотя иногда это может очистить вещи. Вот почему я настроил Resharper для показывания изменения "Подсказкой", а не "Предложением". Это заставляет зеленое подчеркивание быть менее видимым, и оно не будет выделено на правильной боковой панели.

А-ч, эстетика кода. Время священной войны. (утки)

я пошел бы с любым a?: выражение:

return attr != null ? attr.Value : String.Empty

или инвертирование, если и удаляют разрыв строки для создания защитный пункт :

if (attr == null) return String.Empty;

return attr.Value;

Ваш исходный код намного более читаем и понятен - сразу, Вы видите точно условие, которое заставляет string.Empty быть возвращенным. Без эти else, необходимо видеть, что существует возврат в if блок перед этим.

Просто помнят, Вы - человек и по сути более умный, чем машина. Если это говорит Вам, что что-то лучше, и Вы не соглашаетесь, то не слушайте его.

Если Вам не нравится путь, ReSharper предлагает, чтобы что-то, просто отключило определенное предложение (наклонная черта, предупреждающая подсказку наклонной черты). То же идет для стиля кодирования, который я думаю, вполне высоконастраиваемы . Утверждая ReSharper быть неприменимым (заключение в кавычки "я рад сказать, оно не выжило, никто здесь не использует его больше"), просто, потому что Вы не занимаете 5 минут для получения, знают, как настроить его, всего плоскость, глупая .

, Конечно, Вы не должны позволять некоторому инструменту продиктовать некоторую часть Вашего стиля кодирования, и ReSharper НЕ делает этого, если Вы говорите это не. Это - это простое.

Я заметил то же самое о ReSharper, таким образом, я действительно ценю его способность выключить некоторые объекты или понизить их предупреждение уровня. Я также озадачен этим предложением:

SomeClass varName = новый SomeClass ();

имеет предложенное изменение в:

var varName = новый SomeClass ();

Да, я знаю, что не делаю потребность начальный тип объявления, но это чувствует себя нечетным, чтобы предположить, что форма var так или иначе лучше , чем другой. Действительно ли кто-либо знаком с объяснением позади предложения, или Вы соглашаетесь со мной, что этот нечетен также?

Я думаю, что новая версия намного лучше, если Вы инвертируете, если

static public string ToNonNullString(this XmlAttribute attr)
{
    if (attr == null)
        return string.Empty;

    return attr.Value;
}

, поскольку Ваша исходная версия слишком симметрична, в то время как пустой случай является особым случаем.

Новая версия более читаема в терминах, "что она возвращает большую часть времени?".

Классический пример исключений, которые вползают во все, когда Вы используете размер небольшой выборки. Рефакторинг огромного if-elseif-else блока в защитное расположение пункта делает код намного более читаемым, но, как Вы говорите при применении тех же правил к синглу, если еще это не столь полезно. Я сказал бы даже, что это было (небольшое) отсутствие предвидения resharper devs для не перескакивания через очень маленькие блоки, такие как это, но это достаточно безопасно.

Быть новичком в C# и более привыкший к C и Java я все еще не могу привыкнуть к размещению угловых скобок в.NET C# и VS. Помещая все, что в стороне, я согласовываю с Andrey в том инвертировании, 'если' еще более читаемо. С другой стороны, я лично нахожу, что исключение 'еще' уменьшает удобочитаемость (немного). Я пошел бы с этим лично:

static public string ToNonNullString(this XmlAttribute attr)
{    
    if (attr == null)
        return string.Empty;
    else
        return attr.Value;
}

Некоторые мои коллеги начали использовать Resharper с того момента на страницах, которые они отредактировали, были ужасны в расположении и удобочитаемости. Я рад сказать, что это не выжило, никто здесь не использует его больше.

Об операторе под рукой я соглашаюсь с Jeffrey Hantin, встроенным - если очень хорошо для такого типа оператора, и решение Whatsit очень приемлемо для. За некоторыми исключениями i (лично) говорят, что методы/функции должны иметь только 1 оператор возврата.

Также, если Вы (почти) всегда еще реализуете с Вашим, если (даже если это не ничто иное кроме строки комментария, указывая Вам, ни в чем не выполняют с еще-оператором) это вынуждает Вас думать о той ситуации, как правило, это может предотвратить ошибки.

Оба комментария должны использоваться, как 'думают о' не как правило, точно так же, как большая часть этого вида проблем, всегда используйте мозг:) большинство ошибок происходит, когда Вы не делаете.

В заключении: Скажите "нет" Resharper! (да, мне истинно не нравится Resharper, извините.)

Единственное, что я бы добавил, должно быть с длиной задействованных выражений. Лично мне нравится компактность троичных выражений, но превращение чего-то вроде

if (testDateTime > BaseDateTime)
    return item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime;

return item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;

во что-то вроде

return testDateTime > BaseDateTime ? item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime : item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;

не кажется мне полезным.

Мой стандарт кодирования: всегда использовать квадратные скобки (даже если после команды if есть только одна инструкция)
Это требует немного усилий (больше печатать), но я так часто убеждаюсь, что оно того стоит!

Одной из наиболее распространенных ошибок (и, как это ни парадоксально, трудно найти) является добавление дополнительной инструкции после оператора if и забвение добавления скобок...

Поэтому мне нравится то, что предложил Resharper. Особенно при наличии вложенных операторов if:

Предположим, у нас есть такой код:

   if (condition1)  {
      instruction1;
   }
   else {
       if (condition2) {
           instruction2;
       }
   }

Его можно изменить, чтобы он выглядел следующим образом:

   if (condition1)  {
      instruction1;
   }       
   else if (condition2) {
      instruction2;
   }       

И это стало для меня гораздо более читабельным, чем прежде.
(Это также будет более заметно, если у вас более двух уровней вложенных операторов)