Плохой код Java, чтобы вы почувствовали себя лучше

Сколько раз вы это слышали? Чистый код, осмысленное именование и тестирование. Кричал на тебя все время. Вы знаете, я знаю, и все знают.

А как насчет грязного кода? Вот 9 фрагментов плохого кода. Подробно объясняя, почему они важны.

Давайте начнем.

1. Передайте более 255 аргументов

.java:796: error: too many parameters

Вы не видите метода с более чем 4 параметрами. В плохой день более 5 парам. Вы думаете, что это обычная практика? Неправильно, еще есть вопросы по количеству параметров.

2. Вызовите конструктор объекта.

Нет необходимости добавлять super(). Компилятор сделает это за вас.

Другое дело, что getAdress возвращает String, а не a dress. Ложные ожидания, которые мы видим в повседневной работе.

3. Однострочный

Парень с однострочником. Пишет код в одну строку и думает, что это круто. Однострочники просты, читабельны и удобочитаемы. Верно? Только для однострочных парней.

4. Иначе, если

Видно, что это в образовательных целях. Итак, для этого достаточно switch. Он выполняет свою работу и полезен для практики.

Для опытного разработчика решений не существует. Можно было создать Room класс. Room будет содержать roomNumber и message.

5. Анти-шаблон стрелки.

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

6. Использование карты daysOfTheWeek

Любительский кодекс. С точки зрения образования, это нормально. Что не так с кодом? Перечисление DayOfWeek реализовано и готово к применению. Эксперты используют реализацию по умолчанию, выполняют итерацию быстрее и единообразно.

Что еще не так? Понедельник, не настоящий день, а число. Понедельник по умолчанию кодируется как 1. Понедельник, поскольку 0 может вызвать путаницу, затруднить отладку кода и не интуитивно понятен. Примените реализацию по умолчанию в своем коде.

Я указываю свой ввод как Вт, а через 10 дней ищу следующий день. Жду ответа Пт - оригинальный плакат

Наглядный пример проблемы XY. Где вы представляете решение Y без проблемы X. Посмотрите на проблему, объясните проблему и не показывайте свое решение. Вот одно простое решение проблемы.

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

7. Подсчет непробельных символов String

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

input.replaceAll("\\s+", "").length();

Немного чище и удобнее для чтения. Но я не профессор, решать вам.

8. Создание объектов без их назначения.

Почему тогда фрагмент кода плохой? Это сбивает с толку, занимает много времени, а инициализация заканчивается в байт-коде. Согласно эксперименту, сделал один комментатор. Байт-код действительно содержит неназначенную строку. Не пишите такой код, так как байт-код содержит бесполезную строку.

Вы еще можете увидеть такой фрагмент. Даже в официальных Oracle docs. В чем разница? Для неназначенного экземпляра вызывается метод.

// correct usage of unassigned instance
public static void main(String args[]) {
        (new HelloThread()).start();
}

9. Странный isNegative метод

Плохой комментарий. Комментарий не описывает метод. Хотя метод плохой, комментарий плохой. isNegative - это предикат. правильный комментарий: «Возвращает false, если x отрицательно, в противном случае возвращает true».

Использование исключений для потока управления. Код Java наихудшего случая. После перехвата исключения код возвращает true. Не следует заходить дальше этого. Очистите такой код.

Использование System.out.println - это плохо. Почему? Просмотр журнала затруднен, вы можете потратить часы и потерять фокус.

При развертывании программы эти журналы теряются. Пропал с логированием сервера. Использование Logger показывает уровни сбоев, сохраняет их в файл, и вы можете их отключить. Использовать собственный логгер вместо System.out.println. На мой взгляд, ведение журнала проще. Легче проводить посмертный анализ, устранять проблему и кодировать.

Интересно, methodname? Есть способ найти метод вызывающего абонента. Согласно ответу, лучше всего использовать Reflection. По возможности избегайте Reflection и проблем с оптимизацией.

Забрать

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

Хотите больше плохих сниппетов? Подробнее читайте в моей бесплатной электронной книге.

Ключевые выводы:

  • Стремитесь к простому решению
  • Проверьте код на наличие анти-шаблона стрелки
  • Применяйте принципы ООП, чтобы избежать смещения стрелок
  • Примите реализацию Java по умолчанию, не изобретайте велосипед
  • Не используйте исключения для управления потоком
  • Полагаться на настраиваемый регистратор, а не на средство ведения журнала по умолчанию

Есть ли у вас плохой пример? Опубликуйте его в комментариях. Спасибо за прочтение!

Укради мою электронную книгу

Я уже написал много плохих фрагментов Java. Вы можете украсть их из my Gumroad.

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

Большинство из них поступает из subreddit.