предисловие

«Руководство по Java-разработке Alibaba» всегда признавалось энтузиастами Java-разработки и представителями отрасли.

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

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

Спецификации программирования

стиль именования

1. [Обязательно] Имена в коде не должны начинаться и заканчиваться символом подчеркивания или знаком доллара.

Согласен, могу добиться соблюдения. Во-первых, это можно сделать при разработке реального кода, но эта спецификация должна быть согласована с коллегами по отрасли, а начало и окончание символами подчеркивания и знаками доллара не дает никаких других преимуществ.

2. [Обязательно] Во всех именах, связанных с программированием, строго запрещено использовать комбинацию пиньинь и английского языка, а также напрямую использовать китайский язык.

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

3. [Обязательно] Имя класса должно быть в стиле UpperCamelCase со следующими исключениями: DO/BO/DTO/VO/AO/PO/UID и т. д.

Согласен, могу добиться соблюдения. Именование в верблюжьем регистре в основном является консенсусом, но насчет ДО, БО и т. д., на самом деле, некоторые люди в проекте любят писать Бо, а некоторые люди сначала пишут БО. Лично я предпочитаю писать оба с большой буквы. на самом деле являются аббревиатурами некоторых специальных терминов, поэтому лучше использовать заглавные буквы, например, DTO, что на самом деле является аббревиатурой Data Transfer Object.

4. [Обязательно] Имя метода, имя параметра, переменная-член и локальная переменная используют стиль lowerCamelCase.

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

5. [Обязательно] Все имена констант в верхнем регистре, слова разделены символом подчеркивания, смысловое выражение должно быть полным и ясным, а имена не должны быть слишком длинными.

Согласен, могу добиться соблюдения. Все в верхнем регистре, разделенные символами подчеркивания между словами, это в основном консенсус, я видел некоторые коды из-за проблемы с длиной, некоторые сокращения используются для выражения, лично мне это не очень нравится, я бы предпочел быть длиннее, но предпочитают удобочитаемость Более сильные разработчики.

6. [Обязательный] Имя абстрактного класса начинается с Abstract или Base, имя класса исключения начинается с Exception, имя тестового класса начинается с имени тестируемого класса и заканчивается Test.

Согласен, могу добиться соблюдения. Это сделает понимание более ясным.

7. [Обязательный] Тип заключен в квадратные скобки для обозначения массива.

Согласен, могу добиться соблюдения. Это будет выглядеть более интуитивным и понятным Примером, упомянутым в руководстве, является использование String args[] для определения входных параметров основной функции. Я взглянул на текущий стиль аргументов String[], когда IDEA автоматически генерирует основную функцию.

8. [Обязательно] Не добавляйте префикс is к какой-либо логической переменной в классе POJO, иначе синтаксический анализ некоторых фреймворков вызовет ошибки сериализации.

Его нужно изучать и дополнять.Контрпримером, приведенным в мануале, является атрибут, определенный как базовый тип данных Boolean isDeleted, а также метод isDeleted().При обратном разборе фреймворк будет думать, что соответствующий атрибут имя удалено, поэтому атрибут не может быть получен, что затем вызывает исключение.

Так у каких фреймворков будут эти проблемы, есть ли еще эти проблемы, и нужно ли все-таки следовать этой спецификации с неким смыслом истории, все-таки я думаю после добавления is, если это булев тип, я пойму это лучше, а также может быть взаимно однозначное соответствие с именами в базе данных.

9. [Обязательно] Имя пакета должно быть в нижнем регистре, а между точками-разделителями должно быть только одно английское слово с естественной семантикой. Имя пакета использует форму единственного числа единообразно, но если имя класса имеет значение множественного числа, имя класса может использовать форму множественного числа.

Часть перед именем класса согласуется и может быть применена. Что касается множественного числа имени класса, вы можете использовать форму множественного числа. Основная проблема заключается в том, почему имя класса имеет множественное значение. Класс должен представлять собой набор функций и атрибутов. Согласно моему пониманию, он не должен иметь множественного числа числа смысл.

10. [Обязательно] Избегайте использования идентичных имен между переменными-членами дочернего и родительского классов или между локальными переменными разных блоков кода, чтобы уменьшить читабельность.

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

11. [Обязательно] Избегайте совершенно нестандартных сокращений и незнания смысла.

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

12. [Рекомендуется] Для достижения цели самообъясняющего кода любой пользовательский элемент программирования должен использовать как можно более полную комбинацию слов при его названии.

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

13. [Рекомендуется] При именовании констант и переменных помещайте существительные, обозначающие типы, в конце слов, чтобы улучшить распознавание.

Согласен, могу добиться соблюдения. Это также делается ежедневно.

14. [Рекомендуется] Если модули, интерфейсы, классы и методы используют шаблоны проектирования, они должны отражать конкретные шаблоны при их именовании.

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

15. [Рекомендуется] Не добавляйте никаких модификаторов (ни общедоступных) к методам и свойствам класса интерфейса, сохраняйте краткость кода и добавляйте допустимые комментарии Javadoc. Старайтесь не определять переменные в интерфейсе.Если вы должны определить переменные, убедитесь, что они связаны с методами интерфейса и являются базовыми константами всего приложения.

В принципе согласен. Я чувствую, что добавление общедоступного — это нормально, но по умолчанию в интерфейсе общедоступно, и его можно не добавлять.Интерфейс — это, как правило, API, который предоставляется, и вы должны написать комментарий, иначе вы действительно не знаете как использовать этот интерфейс. Как правило, константы не фиксируются в интерфейсе, и будет поддерживаться отдельный класс констант.

16-1. [Обязательно] Для классов службы и DAO, основанных на концепции SOA, открытые службы должны быть интерфейсами, а классы внутренней реализации должны использовать Суффикс Impl отличается от интерфейса.

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

16-2.[Рекомендуется] Если это имя интерфейса, описывающее возможность, возьмите соответствующее прилагательное в качестве имени интерфейса (обычно прилагательное –able).

Я чувствую, что это имеет смысл.Этот интерфейс обычно используется реже.Вообще заявленный интерфейс представляет собой кучу действий.Нейминг больше склоняется к существительным,типа XXXhandler.

17. [Ссылка] Имя класса перечисления должно иметь суффикс Enum, а имя члена перечисления должно быть все в верхнем регистре, а слова должны быть разделены символами подчеркивания.

Согласен, могу добиться соблюдения. Так это делается каждый день, и это более читабельно.

18. В основном речь идет о некоторых соглашениях об именах, подробности см. в руководстве.

Личное чувство, можно на него ссылаться, у каждой группы свой набор норм, и не надо заставлять его соответствовать мануалу. В настоящее время он обычно используется для вызова уровня сохраняемости и таблицы базы данных XXXPO, объект отображения называется VO, объект передачи в системе называется BO, а объект передачи данных по системе называется DTO.