Я являюсь частью команды разработчиков Java с 6-недельным сроком. Это требует написания большого количества кода очень и очень быстро. Однако у нашей команды разработчиков разные стили кодирования. Все от именных соглашений до методов абстракции различаются в нашей команде. Кто-нибудь знает какие-либо документы, которые диктуют "стандарты" для Java?
Чтобы прояснить, мне было интересно, существует ли организация, которая могла бы диктовать правильное соглашение о присвоении имен для переменных и функций, например. Это имеет первостепенное значение, так как при таком коротком сроке мы не можем позволить себе тратить время на попытки понять код друг друга.
java
coding-standards
Даниэль Гратцер
источник
источник
Я действительно прислушиваюсь к ответу Андреса и концентрируюсь на аспекте, равномерно форматирующем код Java.
Если вы используете Eclipse, вы можете настроить его форматирование Java на автоматическое форматирование в соответствии со стандартом Java. В формататоре Eclipse также есть другие полезные настройки, такие как количество символов в строке (т. Е. Сколько символов в строке до того, как он переходит на новую строку) и многие другие. Стандартизация символов в каждой строке делает его легче дифф кода , написанного разными разработчиками , не имея много отличий только от расстояния и разрывы строк.
Наконец, в Eclipse, после того, как вы установили все необходимые настройки, экспортируйте ваш форматтер в файл, который может быть импортирован любым членом команды. Поэтому, если вы используете Eclipse, я настоятельно рекомендую полностью изучить все параметры, которые он будет автоматически форматировать и редактировать для вас, а затем поделиться настройками со всей командой.
Я хотел бы предположить, что другие основные IDE Java (IntelliJ и Netbeans) имеют аналогичную функцию для экспорта настроек формата.
источник
Фактически. Это не главное.
После 30 лет работы консультантом, я прочитал много кода от многих клиентов. Важно отметить, что у каждого клиента (и часто в пределах организации клиента) есть различные стили.
Прочитав так много стилей, я научился этому.
Стиль не имеет значения
Пожалуйста, сосредоточьтесь на написании кода, который всегда работает, и написании модульных тестов, которые доказывают, что он всегда работает.
После того, как вы отправили рабочий код, вы можете одеть его, если у вас закончились ошибки для исправления и улучшения для установки.
источник
Не беспокойтесь о выборе идеального универсального стандарта. Все, что вам нужно, это чтобы ваша команда согласилась с одним стандартом и придерживалась его. Придумай свое, если хочешь, но будь последовательным.
Согласованность улучшает совместную работу, совместная работа улучшает код.
Даже если фактическая последовательность не помогает, тот факт, что ваша команда работала вместе, чтобы прийти к соглашению, - это хорошо. Их неспособность согласиться на что-то столь простое, как соглашения о кодировании, говорит о том, что могут скрываться проблемы с командной работой.
источник
Упомянутому выше Sun Java CC не только 13 лет, и некоторые его правила устарели (например, 80 символов в строке), но также не определяют соглашения об именах, за исключением самых общих (верблюжья оболочка для классов, заглавные буквы) для статических конечных переменных и тому подобного).
Вы должны определить свои собственные стандарты для различных типов классов, таких как DAO, EJB, сущности, что бы вы ни использовали. Sun Java CC походит на абстрактный базовый класс, предназначенный для расширения :)
источник
Как уже упоминалось здесь другими, вы можете найти в Интернете 1 из нескольких популярных «руководств по стилю» для Java и убедить всех в команде придерживаться их. Некоторые инструменты проверки кода в вашей любимой IDE могут помочь напомнить вам, когда вы этого не делаете.
Однако иногда политика вовлечена. Я однажды попал в ситуацию, когда самый старший разработчик в команде продолжает делать это по-своему, даже после того, как кто-то упомянул о необходимости стандартизации. В такой ситуации, возможно, было бы лучше наблюдать за его стилем кода и следовать за ним, поскольку он, вероятно, обладает наибольшим знанием о кодовой базе и требованиях, и вы, возможно, не захотите тратить время на то, чтобы наступить ему на ноги, даже если он труден. Что мы и сделали в этой конкретной ситуации, и я с неохотой следую.
Поэтому важно учитывать и вашу ситуацию.
источник
Дядя Боб показывает более современный и современный стиль кодирования в своей книге «Чистый код». К сожалению, он не содержит списка предметов. Вы должны прочитать это. Он сам говорит, что, чтобы увидеть его условности, вы должны прочитать его код. Дядя Боб, без сомнения, своего рода учреждение. В любом случае, эта книга отлично читается, поэтому даже если уже слишком поздно читать ее, прочитайте ее как можно скорее.
источник
Что действительно важно в коде, так это низкая цикломатическая сложность, небольшая область применения, высокая согласованность и выбор выразительных идентификаторов. Учитывая это, код становится легко понять, и такой код хорош.
Я предлагаю вам взглянуть на спартанское программирование .
Большинство стандартов кодирования говорят вам, как сделать плохо написанный код красивым, и большинство дискуссий о «стиле кодирования» на самом деле касаются форматирования. Форматирование кода - это визуальное представление структуры вашего кода. Это тривиально и автоматизируемо, и он почти ничего не делает со стилем кодирования, потому что стиль кодирования не в том, как вы представляете структуру кода, а в том, как вы структурируете код.
Есть также много религиозных войн по поводу соглашений об именах, хотя на самом деле они просто хак, чтобы обойти плохой дизайн. Имя хорошо, если оно говорит, что это значит. Чем меньше и четче ваши области видимости, тем легче выбрать такое имя.
источник