Соглашение о кодировании Java для статического метода - PullRequest
10 голосов
/ 23 сентября 2011

Это очень простой вопрос, но я думаю, что он немного спорный.

Когда я кодирую классы Java, я использую следующий порядок.

class Foo {

    // static fields
    // instance fields
    // constructors
    // methods (non-static and static methods are mixed but sorted based on their functionalities)
}

Я читаю статьючто говорит:
(из http://code.google.com/webtoolkit/makinggwtbetter.html#codestyle)

Типы Java должны иметь следующий порядок членов:

Вложенные типы (смешивать внутренние и статические классы можно)
Статические поля
Статические инициализаторы
Статические методы
Поля экземпляра
Инициализаторы экземпляра
Конструкторы
Методы экземпляра

Если я следую статье, порядок выше должен быть

class Foo {

    // static fields
    // static methods
    // instance fields
    // constructors
    // instance methods
}

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

Ответы [ 7 ]

21 голосов
/ 23 сентября 2011

Я считаю, что стандарты Java-кодирования Sun (ныне Oracle) используются более широко. Это то, что вы используете в настоящее время тоже.

С Соглашения о коде для языка программирования Java TM :

3.1.3 Объявления класса и интерфейса

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

  1. Комментарий документации класса / интерфейса (/*.../)
  2. class или interface выписка
  3. Комментарий к реализации класса / интерфейса (/.../), при необходимости
  4. Переменные класса (static)
  5. Переменные экземпляра
  6. Конструкторы
  7. Методы
4 голосов
/ 23 сентября 2011

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

3 голосов
/ 23 сентября 2011

Только для справки, это из статьи GWT, которую вы связали:

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

Поэтому стиль, который они используют

  1. , предлагается для GWTдля общего пользования
  2. несколько отличается от стандартных соглашений
  3. признан одним из многих хороших стандартов

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

2 голосов
/ 23 сентября 2011

Условные обозначения Java Code предлагают следующее (что, в основном, вы уже делаете):

  • Классовые (статические) переменные: сначала общедоступные переменные класса, затем защищенный, затем уровень пакета (без модификатора доступа), а затем приватный
  • Переменные экземпляра: сначала общедоступный, затем защищенный, затем уровень пакета (без модификатора доступа), а затем приватный
  • Конструкторы
  • Методы: эти методы должны быть сгруппированы по функциональности, а не по объему или доступности. Например, метод закрытого класса может находиться между двумя открытыми методами экземпляра. Цель состоит в том, чтобы облегчить чтение и понимание кода.
0 голосов
/ 23 сентября 2011

Я ставлю статические инициализаторы и методы перед конструкторами, так что, думаю, я следую вашей цитате.

Почему дискомфорт?Вроде мелочь.

0 голосов
/ 23 сентября 2011

Конечно, все зависит от предпочтений ...

Ваше соглашение более соответствует порядку по умолчанию в Javadoc (то есть статические и нестатические методы, смешанные вместе).Это то, что я обычно делаю тоже.

Однако внутренние классы часто помещаются внизу класса, поскольку они часто являются «вторичными» или «вспомогательными» классами, и кажется странным помещать их до главное мясо внешнего класса.

0 голосов
/ 23 сентября 2011

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

Исключением являются статические фабричные методы, которые я намереваюсь использовать вместо конструкторов - если это так, они предшествуют конструкторам, а ctors являются частными / защищенными.

...