Стиль кода с [закрытыми] Аннотациями
Оба допустимы. Кавычка от xml.com :
ресурс А может иметь больше чем одно представление. Существует четыре часто используемых способа обеспечить корректное представление ресурса потребителям:
- управляемое Сервером согласование. Поставщик услуг определяет правильное представление от предварительных знаний его клиентов или использует информацию, предоставленную в HTTP-заголовках, любят, Принимают, Принимать-набор-символов, Принятый закодированный, Принимать-язык и Агент пользователя. Недостаток этого подхода состоит в том, что сервер не может иметь лучшего знания о том, что действительно хочет клиент.
- управляемое Клиентами согласование. Клиент инициирует запрос к серверу. Сервер возвращает список доступных из представлений. Клиент тогда выбирает представление, оно хочет и отправляет второй запрос к серверу. Недостаток состоит в том, что клиент должен отправить два запроса.
- управляемое Прокси согласование. Клиент инициирует запрос к серверу через прокси. Прокси передает запрос серверу и получает список представлений. Прокси выбирает одно представление согласно предпочтениям, установленным клиентом, и возвращает представление назад клиенту.
- определенное URI представление. Клиент определяет представление, которое это хочет в строке запроса URI.
5 ответов
Мы используем первый случай
В некоторых случаях аннотации не помещаются в одну строку .
- То, что происходит в этих аннотациях, продолжает складываться в нашем проекте, ответственность за ответственностью. Наличие аннотаций для действительно разных проблем в одной и той же строке становится беспорядочным.
- Кроме того, некоторые аннотации могут стать действительно большими и сами по себе быть многострочными (я думаю о переопределении отображения Hibernate в подклассе).
Я бы сказал, что для этого нет жесткого правила. В зависимости от ситуации вы можете выбрать любой из двух вариантов.
Например, если в вашем классе имеется большое количество коротких методов, иногда желательно объединить их в одну строку, чтобы уменьшить шум кода:
@MyAnnotation public int foo1(){ return 1; }
@MyAnnotation public int foo2(){ return 2; }
@MyAnnotation public int foo3(){ return 3; }
etc etc
Аналогично, если вы иметь более существенный метод со сложной аннотацией, более желательна развернутая форма.
Аннотации могут иметь параметры, они могут стать очень длинными, если вы поместите аннотацию плюс ее параметры плюс заголовок метода в одну строку.
@MyAnnotation(name = "This is the name", version = "1.0")
public void foo () {
// ...
}
Ну, мы даже не можем договориться, где поставить {: - (
Я предпочитаю первое, тем более что аннотаций может быть более одной.
Примеры I ' m знаком с этим стилем.
Я бы обычно использовал первый случай.
Однако один конкретный случай, когда я помещаю аннотацию в ту же строку, связан с @Test аннотация в JUnit. Он довольно короткий, обычно не принимает никаких параметров и, прежде всего, обычно появляется в контексте, когда человек, читающий, подсознательно ожидал, что он все равно будет там. Когда вы аннотируете общедоступные пустые нулевые методы в тестовом классе, я бы сказал, что дополнительная краткость вставки аннотации в ту же строку лучше (т. Е. Меньше отвлекающих факторов, можно увидеть больше кода на экран), чем помещать его в отдельную строку,
В общем случае вы действительно хотите, чтобы ваши аннотации выделялись, поскольку они ' Это часто отклонение от того, что разработчик ожидал бы от неаннотированного метода. Так, например, если я установил тайм-аут для аннотации @Test , я поместил ее в предыдущую строку, чтобы она не потерялась в шаблоне.