Comments 11
Спасибо. Забираю в избранное.
+1
Извините за оффтоп. Никогда не понимал кодестайлы где приватные поля идут первыми. Публичные методы класса есть его интерфейс (логический) и когда он сверху то быстрее вникнуть в роль класса.
+3
Честно говоря с навигацией по классу которую предоставляют MSVS + Resharper или Idea не так уж и сложно наоходить и свойства и методы.
Но что-то мне подсказывает, что контекстно-связаные свойства находящиеся в пределах одного экрана несколько более читаемы, чем совершенно никак не связаные, но отсортированые члены класса (например add, close, remove).
Но что-то мне подсказывает, что контекстно-связаные свойства находящиеся в пределах одного экрана несколько более читаемы, чем совершенно никак не связаные, но отсортированые члены класса (например add, close, remove).
0
Навигация, конечно, да, Go to Everything и Go to File Member очень помогает. Сортировка, скорее даже не для быстрого нахождения чего либо, а для поддержания хоть какого-то порядка.
Дело вкуса и стандарта, которого вы придерживаетесь.
Ведь для этого пост и был написан, чтобы показать что можно настроить сортировку, как вам угодно.
Вы ведь можете сортировать, например, только по типу члена, не трогая имя.
Дело вкуса и стандарта, которого вы придерживаетесь.
Ведь для этого пост и был написан, чтобы показать что можно настроить сортировку, как вам угодно.
Вы ведь можете сортировать, например, только по типу члена, не трогая имя.
0
Очень полезная вещь. Только нужно быть осторожным при Cleanup всего проекта, особенно с частями унаследованного кода, так как он может полагаться на определённое расположение полей в структурах. Для предосторожности, я бы порекомендовал отключить сортировку для структур вообще по умолчанию (а также автоматическое преобразование свойств в автосвойства, кстати). Один раз я очень удивился, когда после Cleanup программа перестала работать, хотя она и не содержала небезопасный код.
0
По умолчанию, 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>
+1
Очень полезная штука, давно применяю. Вкупе с проверкой naming conventions позволяет не забивать голову стандартами того или другого проекта.
Только у нас есть правило — не делать cleanup существующему коду. Это приводит к каше в code review и лучям зла от тех, кто их делает. Cleanup делаем только для новых файлов, где он не приведёт к «лишним» изменениям.
Только у нас есть правило — не делать cleanup существующему коду. Это приводит к каше в code review и лучям зла от тех, кто их делает. Cleanup делаем только для новых файлов, где он не приведёт к «лишним» изменениям.
0
Что-то я не совсем уловил мысль. А если я смотрю в старый файл и вижу говнокод, который требует рефакторинга (переносов, переименования), то сделать его не могу?
0
Sign up to leave a comment.
C#. Сортировка членов типа с помощью ReSharper