Как называть классы в java

Как правильно называть имена классов в Java?

Как правильно называть имена классов в Java?

Есть у меня к примеру список классов. Удобнее читать так?

Половина кода у меня так половина так)). Это чем то похоже на

Strings str[] и Strings []str

Конечно для коротких названий без разницы. А если названия будут из 3-5 слов.

Только не пишите как хочешь). А то ведь если так то я и так могу называть классы

3 ответа 3

Стиль, как FragmentOne кажется удобнее тем, что в списке файлов классы будут сгруппированы по принадлежности, то есть сначала идут все активити, потом фрагменты и тд, так их удобнее искать в дереве проекта, если таких файлов достаточное количество. Однако, на самом деле, в поиске класса по имени не первостепенно важно, кто его родитель, более важно предназначение, которое выражается через собственное осмысленное имя. Если появляется необходимость в группировке по другому признаку, то обычно это делается через поддиректории в основной директории с кодом, как src/../service (то есть выделение в пакет), как в эталонном приложении Google I/O Sched

С точки зрения стиля Android правильным будет второй вариант

Про именование классов написано буквально следующее:

Class names are written in UpperCamelCase. Class names are typically nouns or noun phrases. For example, Character or ImmutableList. Interface names may also be nouns or noun phrases (for example, List), but may sometimes be adjectives or adjective phrases instead (for example, Readable).

Смысл этой белиберды состоит в том, что именование классов обычно состоит из существительных (иногда прилагательных) образующих или слова или фразу в виде CamelCase

Возвращаясь к вопросу, ни один из представленных вариантов (на мой английский) не удовлетворяет критериям фразы, посему я бы таки рассмотрел такие варианты:

Источник

Почему в java рекомендуется называть класс с большой буквы?

5 ответов 5

Для начала, давайте ответим на вопрос: а почему вообще нужны какие-то рекомендации по называнию классов? Вот бы каждый писал как ему вздумается, было бы наверное неплохо?

На самом деле, не так уж и хорошо. Дело в том, что в серьёзных проектах большая часть времени расходуется не на написание кода, а на его поддержку. Причём код поддерживает обычно не тот, кто его написал. Если код написан в одинаковом стиле, его легче понимать: не приходится подстраиваться под индивидуальный стиль каждого нового автора. Поэтому руководители крупных проектов часто (если не всегда) требуют от программистов соблюдения общепринятого стиля.

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

Отлично, почему же именно с большой буквы? Дело в том, что надо было установить хоть какое-то правило. Сообщество Java приняло такой стандарт (а может, Гослингу так понравилось), более-менее произвольно, важно было лишь чтобы стандарт существовал. И теперь нам ничего не остаётся, как следовать этому стандарту.

Для классов (вольный перевод):

Имя класса должно быть существительным. Если оно состоит из нескольких слов, слова пишутся вместе, каждое с большой буквы. Старайтесь, чтобы ваши имена классов были простыми и выразительными. Избегайте сокращений и аббревиатур (за исключением популярных и устоявшихся, наподобие URL или HTML).

Источник

Java Code Style: как правильно оформлять код Java

Статья об именах переменных, классов и методов, скобках, комментариях, форматировании кода и других правилах хорошего тона, принятых в языке Javа.

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

Зачем нужен единый стиль кода

Java Code Style — это рекомендации и соглашения о стиле кода, собранные вместе. Например:

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

Причины, по которым разработчики пришли к таким соглашениям, логичны и просты:

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

Преподаватель Skillbox. Пишет про Java, учит Go. Помнит рассвет PHP и как «грабить корованы».

Форматирование на практике

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

Источник

Как называть классы в java

Правила оформления кода

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

Хорошо написанный и оформленный код может рассказать о программе большую часть еще до ее запуска.

Также можно столкнуться с работами, где люди пришедшие в Java с других языков, тянут свои привычки. Но надо понимать, что и в Java есть свои правила, которым надо следовать.

Поэтому следование некоторым простым правилам является обязательным требованием к разработчикам.

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

1.2. Наименования классов и интерфейсов

Классы принято называть именами существительными, начинающимися с прописной буквы. При наименовании классов и интерфейсов в Java придерживаются стиля написания CamelCase.

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

Запомните, что имя класса, перечисления или интерфейса всегда пишется с заглавной буквы!

Если класс участвует в наследовании или реализует интерфейс, то задумайтесь о том, чтобы прибавить к имени вашего класса какой-то корень имени класса-родителя или интерфейса:

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

Имена классов-исключений должны заканчиваться на Exception :

Что в принципе согласуется с правилом о наименовании классов, участвующих в наследовании.

1.3. Наименования переменных

При наименовании переменных в Java придерживаются стиля написания lowerCamelCase.

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

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

Название переменной обязано отражать то, зачем она нужна и какое состояние в себе хранит. Обязано отражать свою суть.

Это значит, что у вас не должно быть кода, похожего на подобный:

Если переменая объявляется в пределах метода или цикла, то давать подробнейшее имя не имеет смысла.

Если продемонстрировать эту мысль в коде, то можно написать следущий пример:

Более того, это вносит путаницу, хаос и катастрофически съедает все место на экране ноутбука.

Гораздо более лучше сократить это до:

или вообще заменить index на i :

Учитывая, что Java в целом довольно многословный язык, добавлять еще свои пять копеек в эту копилку не стоит, тем более, что использовать эту переменную вы будете только в области цикла.

1.3.2.1. Свойства класса

Совсем другое дело, если ваша переменная является свойством класса:

Поэтому вы довольно подробно должны описать такое свойство класса.

Также надо помнить еще и то, что частично о смысле переменной, являющейся свойством класса, говорит и название класса.

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

1.3.3. Место объявления переменной

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

Давайте посмотрим на следующий пример:

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

Поэтому старайтесь придерживаться правила: локальные переменные желательно объявлять ближе к месту использования.

Возвращаясь к нашему примеру: объявлять переменную в начале метода, а начинать работать с ней только в конце метода неправильно.

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

Объявление переменной, хранящей индекс массива происходит непосредственно в месте использования.

Таким образом логика будет объявлена компактно и вникнуть в нее будет проще.

1.4. Наименования методов

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

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

Это вводит в ступор и требует дополнительных усилий, чтобы понять почему getHost ничего не вернул.

Также помните, что если ваш метод возвращает коллекцию объектов, то и в имени должно содержаться отсылка к этому:

Плохим стилем считается использование символов подчеркивания, цифр и знаков пунктуации:

Хорошим вариантом будет, например:

В зависимости от того, как и что делает метод.

Имена методов, выполняющих преобразование к другому типу данных, желательно должны начинаться на to :

Имена методов, которые создают и возвращают созданный объект, желательно должны начинаться с create :

Отдельной строкой стоит сказать про именование методов и переменных, возвращаемых boolean тип.

Благодаря этому, использование таких имен выглядит в коде довольно органично и понятно:

1.6. Наименования пакетов

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

Имена пакетов дают дополнительную информацию о том, что за классы лежат внутри и какие задачи они призваны решать.

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

1.7. Общие рекомендации

1.7.1. Обрамление логических выражений фигурными скобками

Несмотря на то, что язык позволяет писать в виде:

Писать так я крайне не рекомендую.

Лично я предпочитаю вариант более явный:

На мой взгляд, это понятнее, хотя это, конечно зависит от человека.

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

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

В качестве иллюстрации приведу такой пример:

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

1.7.2. Выделение логических блоков кода

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

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

Явно выделяются блоки проверки репозиториев, инициализации тестовых данных, сохранения и новой проверки:

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

1.7.3. Дробление кода

В попытке повысить читаемость кода не надо уходить в крайность.

Чаще всего это неоправданно и выглядит нелогично:

Комментарии — это пояснения к исходному тексту программы, находящиеся непосредственно внутри комментируемого кода.

В Java существует две возможности добавить комменатрии к коду.

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

Однако такое не всегда выходит, в дополнении к этому, часто бывает так, что код выполняет запутанную бизнес-логику.

И такие места, я считаю, нужно комментировать и объяснять.

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

Не забывайте, что о переменной или метода сообщает также и имя класса, и имя переменной метода.

Код не нуждается в комментировании, более того, оно только усложнит читаемость.

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

Например, с помощью комментариев можно объяснить группировку объявлений полей:

Поэтому старайтесь максимально ответственно подходить к этому моменту, думайте над названиями классов, методов, пакетов и переменных.

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

Если вы написали код, то отвечайте за то, что написали.

Если вы автор какого-то метода, то именно вы в ответе за поведение метода и за то, что его контракт выполняется верно.

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

Такие ситуации вызывают только раздражение по отношению к автору кода.

Источник

Nikolay995 / JavaCodeStyle.md

Файлы с исходным кодом

Файлы с исходным кодом хранятся в кодировке UTF-8.

Символы пустого места

Кроме символов перевода строки, только ASCII-пробел (0x20) встречается в файлах. Это означает:

Для любого символа, который имеет специальную escape-последовательность (b, \t, \n, \f, \r, «, ‘ и \), эта последовательность используется вместо соответствующего octal (например \012) или Unicode-символа (например \u000a).

Для остальных не-ASCII символов, используется или сам Unicode-символ (например ∞) или соответствующий Unicode escape-символ (например \u221e). Выбор символа зависит только о того, насколько легко код с ним читать и понимать, хотя Unicode escape-символы вне строковых литералов и комментариев вставлять не рекомендуется.

Совет: в случае использования Unicode escape-символа, и иногда даже когда используется сам Unicode символ, поясняющие комментарии могут быть полезны.

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

Файл с исходным кодом состоит из:

Секции разделяются одной пустой линией.

Имя пакета не разделяется переносом строки. Заданная нами длина строки не распространяется на строку с именем пакета.

Использование wildcard и static импортов не рекомендуется. Исключение: если ситуация оправдана, и все испортируемые методы и константы близки по смыслу к классу в данном файле.

Импорт не разделяется переносом строки. Заданная нами длина строки не распространяется на строку с импортом класса.

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

Каждый класс верхнего уровня находится в отдельном файле с его именем.

Порядок расположения членов класса

Члены классы располагаются в таком порядке:

Не разрываем последовательность перегруженных методов

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

Ставим скобки, даже если это необязательно

Непустые блоки: стиль K & R

Скобки ставятся в соответствии со стилем Кернигана и Ричи (Египетские скобки) для непустых блоков:

Исключения делаются для Enum-классов.

Пустые блоки не укорачиваем

Ставим перевод строки и комментарий, даже если тело блока пустое:

Отступы слева для блоков

Каждый раз, когда мы открываем новый блок, отступ увеличивается на 2 пробела. Когда блок заканчивается, отступ возвращается до прежнего значения. Отступ применяется и для комментариев в блоке.

Одно выражение на строку

Каждое выражение или оператор заканчивается переводом строки.

Длина строки в коде имеет лимит в 120 символов. Кроме исключений, любая строка больше лимита должна быть разбита на 2 строки, как описано в разделе Перенос строки.

При переносе строк, каждая перенесенная строка после самой первой отступает слева на 8 пробелов от начальной строки. В общем случае, отступ для 2 перенесенных строк будет одинаковым только если начинаются с синтаксически параллельных конструкций.

Вертикальное пустое место

Одна пустая строка стоит:

Несколько пустых строк подряд разрешается, но не обязательно.

Горизонтальное пустое место

Одиночный ASCII-пробел встречается в следующих местах (помимо требования синтаксиса языка, литералов, комментов и javadoc):

Правила относятся к пробелам внутри строки, а не отступам (оговариваются в другом разделе).

Горизонтальное выравнивание не используется

Выравнивание может улучшить читаемость, но создает проблемы для дальнейшей поддержки. Допустим, последующее изменение затрагивает всего 1 строку. Часто такое изменение сбивает выравнивание, что выглядит уже не так хорошо. Но чаще разработчик стремится поддержать порядок выравнивания и меняет оступы в других строках, инициируя каскадную серию форматирований. Это однострочное изменение теперь имеет «радиус поражения». Это бесполезная работа, также это ухудшает читаемость истории версий, замедляет ревьюеров и затрудняет разрешение merge-конфликтов.

После каждой запятой после определения Enum-константы нужен перевод строки. Дополнительно допускается пустая строка после этого. Пример:

Enum-классы в остальном подчиняются общим правилам оформления классов.

В каждой строке определяется только одна переменная

Каждое определение (поле или локальная переменная) состоит только из одной переменной: определения вида int a, b; не используются.

Переменные определяются по мере надобности

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

Квадратные скобки ставятся рядом с типом, а не самой переменной: String[] args, но не String args[].

Внутри скобок в switch-блоке располагаются одна или несколько групп операторов. Каждая группа содержит одну или несколько меток (например FOO: или default:), за которой следуют операторы.

Как и с другими блоками, оступ для содержимого составляет +2 пробела. После метки стоит перевод строки, и отступ снова увеличивается на +2, как в случае с открытием нового блока. Следующая метка находится на предыдущем уровне, как будто блок закрылся.

Провалы в следующие метки: не используются

Исключения делается только для пустых меток (пример выше с case 1:). Для каждого switch должна быть default-метка, даже если она не содержит кода.

Аннотации, применяемые к классу, методу или конструктору ставятся сразу после блока документации, и находятся на отдельной строке (по одной аннотации на строке). Отступ слева после аннотации не увеличивается. Пример:

Нет специальных правил для форматирования аннтотаций на параметрах, локальных переменных, типах.

Модификаторы классов и методов ставятся в порядке, рекомендованном Java Language Specification:

public protected private abstract default static final transient volatile synchronized native strictfp

Числовые литералы типа long используют большую букву L, никогда не используется нижний регистр (чтобы избежать путаницы с цифрой 1). Например, надо писать 3000000000L вместо 3000000000l.

Правила для всех идентификаторов

Имена пакетов пишутся в нижнем регистре, слова просто последовательно конкатенируются друг с другом (без нижних подчеркиваний). Например, com.example.deepspace, а не com.example.deepSpace или com.example.deep_space.

Имена классов пишутся в UpperCamelCase.

Нет специальных правил для именования аннотаций.

Тестовые классы начинаются с имени класса, который они тестируют, и заканчиваются на Test. Например, HashTest или HashIntegrationTest.

Имена методов пишутся в lowerCamelCase.

Имена констант используют CONSTANT_CASE: все буквы в верхнем регистре, слова отделяются нижним подчеркиванием. Но что есть константа?

Каждая константа является static final полем, но не все static final поля являются константами. Прежде чем именовать переменную константой, подумайте реально ли она является ей. Например, если видимое состояние экземпляра обьекта может измениться, это точно не константа. Просто мысли о том, что объект не будет меняться в процессе работы, не достаточно. Примеры:

Имена неконстантных полей

Имена параметров пишутся в lowerCamelCase. Односимвольных имен параметров в публичных методах следует избегать.

Имена локальных переменных

Имена локальных переменных пишутся в lowerCamelCase. Даже когда они final и immutable, локальные переменные не надо путать с константами, и именовать их как константы.

Имена переменных типов

Каждая переменная типа именуется одним из 2 способов:

Определение Camel Case

Иногда есть несколько способов конвертировать английскую фразу в camel case, например для аббревиатур или необычных имен типа «IPv6» или «iOS». Чтобы имя было предсказуемо, предлагается такая схема.

Примите во внимание, что регистр букв в оригинальных словах не принимается во внимание. Примеры:

Примечание: некоторые слова имеют несколько написаний через дефис в английском языке, например оба «nonempty» и «non-empty» верны. Таким образом, имена методов checkNonempty и checkNonEmpty тоже оба верны.

@Override: всегда используется

Метод всегда помечается аннотацией @Override, если это верно с точки зрения языка. Это включает в себя:

Исключение: @Override можно опустить, если метод родителя обьявлен как @Deprecated.

Перехватываемые исключения: не игнорируются

Кроме случая, описываемого ниже, очень редко является корректным ничего не делать в ответ на перехваченное исключение (типовые способы: логгировать его, если же обьявлено «невозможным», выбросить заново как AssertionError).

Когда реально ничего не надо делать в catch-блоке, причина указывается в поясняющем комментарии:

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

Статические члены класса: указываются через имя класса

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

Finalizers: не используются

Совет: не делайте этого. Если позарез надо, сначала прочитайте и поймите Effective Java Item 7, «Avoid Finalizers», а после этого не делайте этого.

Источник