Правильная организация публичных / защищенных / частных функций в классах

Question

Resharper (в сочетании с StyleCop) сделал меня немного уродливым, когда дело доходит до выполнения большинства его правил. Один из наборов правил (я полагаю из StyleCop) заставляет сначала размещать открытые функции, затем защищенные статические, затем защищенные, затем закрытые статические и, наконец, закрытые.

Частные функции - это, как правило, резервные копии функций общих функций в качестве помощников. Допустим, у меня есть порядок функций, приведенный в соответствие с StyleCop:

public FunctionA
public FunctionB

private FunctionAHelper1
private FunctionAHelper2
private FunctionBHelper1
private FunctionBHelper2

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

public FunctionA
private FunctionAHelper1
private FunctionAHelper2

public FunctionB
private FunctionBHelper1
private FunctionBHelper2

Что вы узнали, что руководило организацией методов в классе? Каковы причины, по которым StyleCop хочет заказать публичный / защищенный / частный заказ? Это действительно сводится к вопросу о предпочтениях, или есть ли преимущества, которых я не вижу?

Answer 1

Это действительно сводится к тому, что вы предпочитаете и как вам нравится перемещаться по коду.

Вы можете заказать свои методы:

• В алфавитном порядке (GetEntityA, GetEntityB, StoreEntityA,...)
• По функциональной области (методы EntityA, методы EntityB, ...)
• По классификации (методы проверки, методы преобразования, вспомогательные методы, ...)
• По видимости (публичные методы, внутренние методы, защищенные методы, ...)

Конечно, вы можете комбинировать в алфавитном порядке с видимостью или чем угодно.Я предпочитаю комбинацию по алфавиту с наглядностью и для больших классов с классификацией.Для занятий DAO иногда функциональная зона).

Answer 2

Если вы используете что-то похожее на IDE, это в принципе не имеет значения. Вы будете перемещаться по коду через графический интерфейс, упорядочивая список свойств, членов и т. Д., Как вам действительно нужно.

(Я считаю, что форматирование кода не должно быть проблемой при программировании. Конечно, оно должно быть нормальным и соответствовать стандартам компании, но есть инструменты, выполняющие форматирование автоматически.)

Answer 3

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

Как и вы, я предпочитаю сохранять приватностьфункции рядом с публичными функциями, которые их используют.Точнее говоря, я предпочитаю группировать функции по их использованию или функциональности, а не по алфавиту или видимости.

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

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