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

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

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

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

Ниже мы рассмотрим:

Соблюдайте стандарты кодекса

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

СУЩЕСТВУЕТ разница между использованием неправильных общепринятых интервалов и реализацией ваших собственных соглашений.

Ссылка, которую я всегда рекомендовал, — это Руководство по стилю Java от Google. Помимо стандартов кодирования, в нем также описаны некоторые интересные случаи, о которых следует знать программистам, что делает его интересным для чтения.

Не бойтесь создавать классы/пакеты

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

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

Не называйте классы просто так

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

Вот почему слова Manager или Processor в именах классов — не лучшая идея.

Все мы знаем, что использование таких постфиксов имен — это самый простой выход. Наличие класса EntityManager, предлагающего операции для объектов Entity, может показаться идеальным названием. Проблема с этим подходом заключается в том, что EntityManager не является осмысленным именем, так как оно почти ничего не говорит о том, что делает класс, кроме какого-то управления. Но разве другие классы, которые используют или изменяют экземпляры Entity, также не управляют сущностями?

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

Много советов по именованию классов и переменных можно почерпнуть из книги Роберта К. Мартина Чистый код: руководство по Agile Software Craftsmanship, и я советую каждому прочитать ее хотя бы раз в своей карьере.

Не оставляйте исключения необработанными

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

  • Регистрация исключения;
  • Повторное создание того же исключения или нового завернутого исключения.

При этом некоторые исключения не должны забивать лог (консоль) или перебрасываться.

В этом примере вызов someObject.doSomething(String) может вызвать исключение, а может и нет, но кто-то, кто просматривает код, не видит причину, по которой исключение не видно.

В Effective Java — Item 77: Don’t Ignore Exceptions Джошуа Блох говорит, что «Если вы решите игнорировать исключение, блок catch должен содержать комментарий, объясняющий, почему это уместно, а переменная должен быть названignored “.

В заключение, если вы окажетесь в ситуации, когда блок catch следует оставить пустым:

  • Дважды проверьте, не требуется ли обработка или можно ли предотвратить ситуацию;
  • Переименуйте переменную исключения, чтобы правильно выразить истинное намерение;
  • Включите комментарий и объясните, почему был выбран именно этот подход.

Модульные тесты предназначены для функциональных возможностей, а не для классов

Надеюсь, это ответит на вопрос Должен ли я тестировать частные/абстрактные классы/интерфейсы?

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

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

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

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

Роберт С. Мартин — Чистый код: руководство по гибкому программному обеспечению