Чистый код на Java: правила, которые спасут ваш проект

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Почему чистый код — это не роскошь, а необходимость

Представьте, что вы заходите в чужой проект. Классы называются Class1, Manager, UltraProcessor. Методы делают всё сразу: и запрос в базу, и рендеринг HTML, и отправку email. А переменные — x, y, temp. Знакомо? Если да, то вы знаете, как быстро такой код превращает жизнь разработчика в ад.

Чистый код на Java — это не про педантичность. Это про уважение к коллегам, к будущему себе и к бизнесу. Грязный код замедляет разработку в 2-3 раза, делает баги неуловимыми, а рефакторинг — невозможным. В этой статье мы разберём конкретные правила, которые помогут вам писать код, который хочется читать и поддерживать.

Правило №1: Именование — 50% успеха

Роберт Мартин (дядя Боб) в книге «Чистый код» утверждает: хорошее имя заменяет комментарий. Java-разработчики часто грешат абстрактными названиями. Давайте исправим это.

Переменные: говорите, что храните

Плохо:

int d; // elapsed time in days

Хорошо:

int elapsedTimeInDays;

Плохо:

List<String> list = new ArrayList<>();

Хорошо:

List<String> customerNames = new ArrayList<>();

Методы: глагол + контекст

Метод должен отвечать на вопрос «что делает?». Избегайте общих слов вроде process, handle, doStuff.

Плохо:

public void process(int id) {
    // 50 строк кода: проверка, расчёт, отправка email
}

Хорошо:

public void sendEmailConfirmation(int orderId) {
    // только логика отправки email
}

Классы: существительные без суффиксов-паразитов

Избегайте Manager, Processor, Util, если это не оправдано. Класс должен отражать сущность.

Плохо: DataProcessor, UserManager

Хорошо: UserRepository, InvoiceCalculator, EmailSender

Правило №2: Методы — короткие и однозадачные

Золотое правило: один метод — одна ответственность. Если в методе больше 15-20 строк, скорее всего, его нужно разбить. Это повышает читаемость кода Java и упрощает тестирование.

Пример рефакторинга

До:

public boolean isValidOrder(Order order) {
    if (order == null) return false;
    if (order.getItems().isEmpty()) return false;
    double total = 0;
    for (Item item : order.getItems()) {
        total += item.getPrice() * item.getQuantity();
    }
    if (total > 10000) {
        // проверка кредитного лимита
        User user = userRepository.findById(order.getUserId());
        return user.getCreditLimit() >= total;
    }
    return true;
}

После:

public boolean isValidOrder(Order order) {
    if (isOrderNullOrEmpty(order)) return false;
    double total = calculateTotal(order);
    if (isHighValueOrder(total)) {
        return hasSufficientCredit(order.getUserId(), total);
    }
    return true;
}

private boolean isOrderNullOrEmpty(Order order) {
    return order == null || order.getItems().isEmpty();
}

private double calculateTotal(Order order) {
    return order.getItems().stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
}

private boolean isHighValueOrder(double total) {
    return total > 10000;
}

private boolean hasSufficientCredit(int userId, double total) {
    User user = userRepository.findById(userId);
    return user.getCreditLimit() >= total;
}

Правило №3: Комментарии — только когда без них никак

Комментарий часто — это оправдание плохого кода. Вместо того чтобы писать «// получаем данные пользователя», лучше переименовать метод в getUserData(). Однако есть исключения:

Юридические комментарии (лицензии, копирайты).
Пояснение сложной бизнес-логики (например, расчёт налогов по неочевидной формуле).
Todo и FIXME — но только временно.

Плохой комментарий:

// Set name
user.setName(name); // это и так очевидно

Хороший комментарий:

// Используем паттерн Strategy для выбора способа оплаты
// на основе региона пользователя (EU — SEPA, US — ACH)
PaymentStrategy strategy = PaymentStrategyFactory.forRegion(user.getRegion());

Правило №4: Форматирование — дышите равномерно

Java-сообщество давно договорилось о стилях. Используйте автоформатирование IDE (Ctrl+Alt+L в IntelliJ IDEA). Вот ключевые моменты:

Отступы — 4 пробела (или табуляция, но не мешайте).
Фигурные скобки — на той же строке (K&R стиль).
Максимальная длина строки — 120 символов.
Пустые строки между логическими блоками.

Пример хорошего форматирования:

public class OrderService {

    private final OrderRepository orderRepository;
    private final EmailService emailService;

    public OrderService(OrderRepository orderRepository, EmailService emailService) {
        this.orderRepository = orderRepository;
        this.emailService = emailService;
    }

    public void processOrder(Order order) {
        validateOrder(order);
        orderRepository.save(order);
        emailService.sendConfirmation(order);
    }

    private void validateOrder(Order order) {
        if (order == null || order.getItems().isEmpty()) {
            throw new IllegalArgumentException("Order must not be null or empty");
        }
    }
}