Противоречивость стилей Java в команде

12

Я являюсь частью команды разработчиков Java с 6-недельным сроком. Это требует написания большого количества кода очень и очень быстро. Однако у нашей команды разработчиков разные стили кодирования. Все от именных соглашений до методов абстракции различаются в нашей команде. Кто-нибудь знает какие-либо документы, которые диктуют "стандарты" для Java?

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

java coding-standards

— Даниэль Гратцер
источник

18

Есть такая организация: Sun / Oracle сама. Этот документ называется « Условные обозначения кода для языка программирования Java» , и в нем описываются большинство необходимых вам соглашений. Просто пусть все согласятся прочитать его и следовать его рекомендациям.

— Андрес Ф.
источник

3

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

— Мартейн Вербург

1

@MartijnVerburg ограничение может побудить рефакторинг в методы и классы, чтобы избежать глубоких отступов.

Это соглашение, и оно может быть разумным отступлением, если вы не можете найти собственное соглашение, но, как следует из названия, оно не диктует - это соглашение.

— пользователь неизвестен

@userunknown Ты прав. Я даже не согласен со всеми конвенциями. Но это хороший компромисс, учитывая сроки проведения ФП.

— Андрес Ф.

8

Я действительно прислушиваюсь к ответу Андреса и концентрируюсь на аспекте, равномерно форматирующем код Java.

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

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

Я хотел бы предположить, что другие основные IDE Java (IntelliJ и Netbeans) имеют аналогичную функцию для экспорта настроек формата.

— Сэм Голдберг
источник

2

+1 Хороший ответ! Вы также можете установить плагин, такой как Checkstyle, и он будет предупреждать вас, когда вы нарушаете соглашения.

— Андрес Ф.

Мы тоже это делаем. Настройки -> Java -> Редактор -> Сохранить параметры и включить формат при сохранении. Основная причина заключается в том, чтобы гарантировать, что строки исходного текста, на которые воздействует формат, происходят как можно скорее, чтобы получить историю управления версиями как можно более чистой (снова различие).

Да, я начал это делать также недавно. Единственное, в чем я не уверен, это то, что я выбрал «удалить неиспользуемые частные переменные» в опции сохранения. Поэтому, пока я делаю TDD, я часто нахожу, что мои переменные исчезают, потому что код был сохранен до того, как я их использовал ... но кроме этого, эта опция была великолепна.

— Сэм Голдберг

6

Это [разные стили кодирования] имеет первостепенное значение, так как при таком коротком сроке мы не можем позволить себе тратить время на попытки понять код друг друга.

Фактически. Это не главное.

После 30 лет работы консультантом, я прочитал много кода от многих клиентов. Важно отметить, что у каждого клиента (и часто в пределах организации клиента) есть различные стили.

Прочитав так много стилей, я научился этому.

Стиль не имеет значения

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

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

— С. Лотт
источник

возможно это не имеет значения, но это также очень приятно иметь, и очень легко сделать.

— Кевин

1

Стиль не имеет значения, но последовательность имеет значение. Непоследовательный стиль значительно усложняет обслуживание программного обеспечения.

— Jesper

5

@Jesper: «Непоследовательный стиль делает обслуживание программного обеспечения« чуть-чуть »сложнее». Это не намного сложнее с любой натяжкой. Непрозрачный, плохой, глючный код гораздо сложнее поддерживать. Несовместимые стили в рабочем коде - это просто несовместимые стили. У некоторых людей есть акцент, и вы должны слушать более внимательно. Несовместимые стили - это чуть больше, чем другой региональный (или национальный) акцент.

— S.Lott

1

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

— Брайан Оукли

1

Msgstr "Ваш код будет в лучшем случае " немного лучше ". И да, это почти нулевая стоимость и, конечно, нулевой риск. Но. 100% тестовое покрытие намного, намного более ценно, чем последовательность.

— S.Lott

2

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

Согласованность улучшает совместную работу, совместная работа улучшает код.

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

— Брайан Оукли
источник

0

Упомянутому выше Sun Java CC не только 13 лет, и некоторые его правила устарели (например, 80 символов в строке), но также не определяют соглашения об именах, за исключением самых общих (верблюжья оболочка для классов, заглавные буквы) для статических конечных переменных и тому подобного).

Вы должны определить свои собственные стандарты для различных типов классов, таких как DAO, EJB, сущности, что бы вы ни использовали. Sun Java CC походит на абстрактный базовый класс, предназначенный для расширения :)

— Мада
источник

Я согласен с тем, что Java CC от Sun немного устарела, но это всего лишь отправная точка. Я полагаю, что у ОП не так много времени, чтобы тратить время на определение собственного CC, иначе он бы сказал это! (Кстати, где я сейчас работаю, они используют плагин Sonar, настроенный для обеспечения ограничения в 80 символов - так что это правило все еще живо и работает в некоторых магазинах).

— Андрес Ф.

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

— BillThor

Если вы сталкиваетесь с проблемами с 80 символами в строке, либо у вас есть удивительно длинные идентификаторы, либо вы слишком много читаете в одной строке. Первое глупо (разве вы не можете довести суть до меньшего?), А второе указывает на срочную необходимость рефакторинга. Автоформатирование при сохранении - это хорошо, так как вам больше не нужно беспокоиться о форматировании; программное обеспечение обрабатывает это для вас.

— Donal Fellows

@DonalFellows Да, в наше время ограничение в 80 символов есть, чтобы напоминать вам о рефакторинге, а не из-за небольших экранов терминала.

— Андрес Ф.

0

Как уже упоминалось здесь другими, вы можете найти в Интернете 1 из нескольких популярных «руководств по стилю» для Java и убедить всех в команде придерживаться их. Некоторые инструменты проверки кода в вашей любимой IDE могут помочь напомнить вам, когда вы этого не делаете.

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

Поэтому важно учитывать и вашу ситуацию.

— snowpolar
источник

Что это за страна? Звучит как культурная вещь.

@ ThorbjørnRavnAndersen Он имеет в виду, что люди могут сопротивляться переменам, когда «то, что они делали так долго». Политическая в этом смысле просто «офисная политика»

— Роботник

0

Дядя Боб показывает более современный и современный стиль кодирования в своей книге «Чистый код». К сожалению, он не содержит списка предметов. Вы должны прочитать это. Он сам говорит, что, чтобы увидеть его условности, вы должны прочитать его код. Дядя Боб, без сомнения, своего рода учреждение. В любом случае, эта книга отлично читается, поэтому даже если уже слишком поздно читать ее, прочитайте ее как можно скорее.

— Питер Кофлер
источник

0

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

Я предлагаю вам взглянуть на спартанское программирование .

Большинство стандартов кодирования говорят вам, как сделать плохо написанный код красивым, и большинство дискуссий о «стиле кодирования» на самом деле касаются форматирования. Форматирование кода - это визуальное представление структуры вашего кода. Это тривиально и автоматизируемо, и он почти ничего не делает со стилем кодирования, потому что стиль кодирования не в том, как вы представляете структуру кода, а в том, как вы структурируете код.
Есть также много религиозных войн по поводу соглашений об именах, хотя на самом деле они просто хак, чтобы обойти плохой дизайн. Имя хорошо, если оно говорит, что это значит. Чем меньше и четче ваши области видимости, тем легче выбрать такое имя.

— back2dos
источник