Я думаю, что я не боюсь задавать этот вопрос и не высказываю своего мнения по этому вопросу :). Вот мои голоса.
Короче говоря, я против стандартных / автоматически сгенерированных комментариев. Я считаю, что комментарии не должны описывать очевидные вещи, объяснять конструкции языка Java / соглашения о коде или содержать информацию, которую можно легко получить с помощью IDE.
1) -5
(Раздел комментариев по умолчанию)
Эти комментарии, с одной стороны, пытаются описать соглашения Java-кода (или пытаются навязать макет пользовательского класса, поскольку они не следуют соглашениям), а с другой стороны, нарушают их - например, давайте возьмем раздел // Helper methods
: он принудительно размещает все приватные методы в этом разделе в конце файла. Это противоречит соглашениям по коду Java ( раздел 3.1.3 ):
Эти методы должны быть сгруппированы по функциональности, а не по объему или доступности. Например, метод закрытого класса может находиться между двумя открытыми методами экземпляра. Цель - облегчить чтение и понимание кода.
Очень легко ошибочно поместить метод в неправильный раздел - в этом случае они могут стать очень загадочными.
Хуже всего, когда кто-то решает иметь это во ВСЕХ классах, несмотря ни на что. Маленькие классы длиной 10 строк станут классами более 50 строк (см. Сам пример)
2) -5
Комментарии по умолчанию для получателя и установщика
Я нахожу это даже хуже беспорядка. Я полагаю, что они фактически пропускают информацию о внутренних классах. Весь смысл методов set / get состоит в том, чтобы скрыть тот факт, что они просто устанавливают и возвращают значение поля.
Эти комментарии самоочевидны и не добавляют никакой полезной информации - только беспорядок в исходном коде.
Мы также должны учитывать, как работает наш мозг. Со временем он действительно научится игнорировать эти комментарии. В этом случае мы можем упустить что-то важное или полезное.
3) -5
Мета-комментарии
Комментарии типа // Logger for this class
или // Default constructor
очевидны и не приносят никакой полезной пользы. Если кому-то действительно нужны такие комментарии, чтобы лучше понять или прочитать код, то я думаю, что пришло время ему прочитать какую-нибудь Java-книгу или учебник для начинающих.
@see IUserService#saveUser(User)
не имеет никакого смысла для меня (учитывая все усилия по обслуживанию, которые должны быть предприняты, чтобы эти комментарии были актуальными). Все основные Java IDE могут предоставить вам эту информацию - они дают видимые признаки того, что метод переопределяет / реализует что-то, что вы можете перейти с помощью ярлыка, обычно вы также можете увидеть, какой метод был переопределен в подсказке, если хотите.
Теперь рассмотрим возможность того, что метод в родительском классе (который вы переопределили) был удален (но в родительском классе родительского класса все еще есть метод, у которого все еще есть метод). В этом случае вы должны обновить эти комментарии во всех подклассах, чтобы синхронизировать их. И я могу сказать вам по опыту, что в какой-то момент большинство этих комментариев будут не синхронизированы и будут служить только двум целям: 1 - загрязнять код и 2 - озадачивать и вводить в заблуждение других разработчиков.
Теоретически вы можете найти способы синхронизировать их (написать плагин IDE, создать сложный код, переписывать во время сборки и запускать его каждую ночь и т. Д.), Но я твердо верю, что это просто трата времени.
4) -3
@SuppressWarnings («не используется»)
Я думаю, что @SuppressWarnings("unused")
имеет место в некоторых обстоятельствах, но не в примере, показанном в вопросе. LOG
комментируется, потому что никогда не используется. Но если он никогда не используется, то IMO LOG
следует удалить из класса. Это закрытое статическое поле, поэтому оно может использоваться только текущим классом. Если класс не использует его, то это беспорядок.
Для context
это также довольно бесполезно.context
аргумент по определению не предполагается использовать.Он представляет информацию, которая может быть полезна для подклассов, но не более того.Поэтому я думаю, что само собой разумеется, что context
иногда не будет использоваться, и это нормально.Я думаю, что IDEA может часто распознавать такие ситуации и не показывает предупреждения, если вы не используете context
.
И лично мне трудно читать сигнатуры методов со всеми этими @SuppressWarnings("unused")
аннотациями (особенно, если их несколько).
5) -4
I
префикс для интерфейсов
Лично я нахожу это уродливым и неестественным.Если я хочу интерфейс для пользователя, я назову его User
, а реализация будет иметь имя UserImpl
.Я думаю, что это можно сравнить с Единый принцип доступа .Пока он называется User
, мне все равно, является ли он интерфейсом абстрактного класса или конкретным классом.Если автор интерфейса User
в какой-то момент решит сделать его абстрактным классом - мне не следует вносить изменения в мой код, потому что, скорее всего, он не изменит имя.Но это не относится к IUser
.
С другой стороны, IDE дает нам более чем достаточно подсказок, чтобы различать классы и интерфейсы.
Насколько я знаю, это наименование происходит от Microsoft COM .В C ++ они не имеют интерфейсов, поэтому они ставят префикс конкретных классов C
(например, CUser
) и интерфейсные классы I
(например, IUser
).В Java у нас есть интерфейсы и Соглашения об именах .И я думаю, что мы должны следовать им, если у нас нет действительно веских причин не делать этого.
6) -1
final
для аргументов метода - запрещает коду в теле метода изменять его значение
Пожалуйста, не поймите меня неправильно.Я считаю, что это действительно плохая практика - менять значения аргументов.Я стараюсь писать в своем коде как можно больше неизменяемого кода.
Но когда я читаю код, все эти final
в сигнатурах методов для меня просто беспорядок.Для меня само собой разумеется, что это должно быть окончательным.Но они делают сигнатуру метода большой и трудной для чтения.
Я думаю, что можно обеспечить соблюдение этого правила с помощью инструментов (таких как FindBugs или CheckStyle).И я думаю, что это лучший способ сделать это.Часто люди не пишут все эти final
сами, но позволяют IDE добавлять их при сохранении файла (например, eclipse может создать).Но если вы действительно изменили значение аргумента (случайно), то IDE просто не вставит final
для вас.