В Java частные помощники должны идти выше или ниже общедоступных методов? [закрыто]

Я заметил, что у нас с коллегами разные практики в отношении порядка методов в наших классах Java. Один из нас начинает урок с его основными публичными методами, а затем назначает всех частных помощников. Другой из нас следит за тем, чтобы публичные методы были в самом конце.

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

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

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

public void doSomething()
{
     helpMe();
     helpMeAgain();
}

Ваш файл будет структурирован как

public void doSomething() { }
private void helpMe() { }
private void helpMeAgain() { }

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

Открытые методы являются интерфейсом класса. Кто-то заинтересован в использовании вашего класса, будет заботиться только об интерфейсе. С точки зрения пользователя класса, было бы полезно сначала использовать публичные методы, чтобы уменьшить прокрутку.

В C и C ++ вспомогательные методы часто ставятся на первое место, потому что тогда вам не нужно объявление. Многие люди перенесли эту привычку на другие языки, где это не имеет значения.

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

Мне нравится, что порядок методов в классе основан на удобочитаемости и контексте, а не на видимости.

то есть «открытый» метод, вероятно, принадлежит перед «закрытым». Если два открытых метода «a» и «b» вызывают приватное «c», и они единственные, кто его вызывает - тогда мне нравится «c», чтобы быть рядом с ними.

Я не думаю, что соглашение о порядке методов, основанное на видимости, является хорошей вещью.

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

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

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

Это, как вы сказали, дело вкуса.

Однако, работая над кодом, который не является моим, я постараюсь найти все, что используется в проекте.

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

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