Pull to refresh

Comments 11

Извините за оффтоп. Никогда не понимал кодестайлы где приватные поля идут первыми. Публичные методы класса есть его интерфейс (логический) и когда он сверху то быстрее вникнуть в роль класса.
Честно говоря с навигацией по классу которую предоставляют MSVS + Resharper или Idea не так уж и сложно наоходить и свойства и методы.

Но что-то мне подсказывает, что контекстно-связаные свойства находящиеся в пределах одного экрана несколько более читаемы, чем совершенно никак не связаные, но отсортированые члены класса (например add, close, remove).
Навигация, конечно, да, Go to Everything и Go to File Member очень помогает. Сортировка, скорее даже не для быстрого нахождения чего либо, а для поддержания хоть какого-то порядка.

Дело вкуса и стандарта, которого вы придерживаетесь.
Ведь для этого пост и был написан, чтобы показать что можно настроить сортировку, как вам угодно.
Вы ведь можете сортировать, например, только по типу члена, не трогая имя.
Очень полезная вещь. Только нужно быть осторожным при Cleanup всего проекта, особенно с частями унаследованного кода, так как он может полагаться на определённое расположение полей в структурах. Для предосторожности, я бы порекомендовал отключить сортировку для структур вообще по умолчанию (а также автоматическое преобразование свойств в автосвойства, кстати). Один раз я очень удивился, когда после Cleanup программа перестала работать, хотя она и не содержала небезопасный код.
По умолчанию, Resharper создает правило для сортировки, которое вы описали:
Спойлер
  <!--Do not reorder COM interfaces and structs marked by StructLayout attribute-->
  <Pattern>
    <Match>
      <Or Weight="100">
        <And>
          <Kind Is="interface"/>
          <Or>
            <HasAttribute CLRName="System.Runtime.InteropServices.InterfaceTypeAttribute"/>
            <HasAttribute CLRName="System.Runtime.InteropServices.ComImport"/>
          </Or>
        </And>
        <HasAttribute CLRName="System.Runtime.InteropServices.StructLayoutAttribute"/>
      </Or>
    </Match>
  </Pattern>


Очень полезная штука, давно применяю. Вкупе с проверкой naming conventions позволяет не забивать голову стандартами того или другого проекта.
Только у нас есть правило — не делать cleanup существующему коду. Это приводит к каше в code review и лучям зла от тех, кто их делает. Cleanup делаем только для новых файлов, где он не приведёт к «лишним» изменениям.
Что-то я не совсем уловил мысль. А если я смотрю в старый файл и вижу говнокод, который требует рефакторинга (переносов, переименования), то сделать его не могу?
Да, потому что если туда потом ещё внести изменения, то не понятно, что поменялось на ревью.
А может просто зарефакторить, переименовать, перенести и зачекинить под задачей РЕФАКТОРИНГ ИЛИ ЧТО ТАМ ЕЩЁ?
Sign up to leave a comment.

Articles