Стиль программирования и наименования

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

Оформление кода

Пользуемся Java Code Conventions, за исключением того что стандартное выравнивание - два символа.

Аббревиатуры пишем в camel case, т.е. UserDao (а не UserDAO)

Названия классов

• @Controller: должен оканчиваться на Controller, например UserModificationController.
• Dao (@Repository): окачивается на Dao, например UserDao
• Данные формы (@ModelAttribute для формы): оканчивается на Request, например AddCommentRequest
• Валидатор формы: оканчивается на RequestValidator, например AddCommentRequestValidator
• Базовый доменный объект: без окончания, например User и Comment
• Составной доменный объект: начинается на Prepared, например PreparedComment. PreparedComment, в отличие от Comment, содержит построенные объекты автора комментария (т.е. User author, а не int authorId), вычисленный текст lorcode и т.п.
• Сервис построения Prepared-объектов: оканчивается на PrepareService, например CommentPrepareService. Общие вещи живут в классе PrepareService
• DTO: оканчивается на Dto, например TrackerItemDto. Dto применяем только когда нет доменного объекта, например если нужно передавать результаты какой-то хитрой выборки которая нужна в одном контроллере
• Boxlet (блоки на главной странице): оканчиваются на Boxlet, например GalleryBoxlet

Логика организации пакетов

В текущий момент логика отсутствует. В процессе переезда на Spring новые классы добавлялись в ru.org.linux.spring, а старые жили в ru.org.linux.site, однако сейчас смысл в подобном разделении изчез.

По возможности, стараемся организоввывать пакеты по назначению, а не по типу классов. Например ru.org.linux.search для поиска, ru.org.linux.poll для опросов, ru.org.linux.user для работы с пользовательскими аккаунтами. Тесты также группируются по назначению классов.