Category: Complete and clean code

Antipatern: Negatively named boolean method

There is an inspection Java | Data flow issues | Negatively named boolean variable

Reports negatively named variables, for example ‘disabled’, ‘hidden’, ‘isNotChanged’. It is usually more clear to invert the boolean value and remove the negation from the name.

But no any inspections for methods.
For example the Apache Commons Lang library’s StringUtils class has two methods: isBlank() and isNotBlank(). The second one has a negativation «Not» and works like !isBlank().
This is antipattern, because we can use automatic refactoring from intellij to invert condition that calling this method.
I mean this refactoring Invert Boolean and Invert If-Else Statement intention.
For examle we can invert a conditionwith isBlank():
invert-if-condition
And result of this refactoringwill be:
invert-if-condition-result

But if you invert a condition with isNotBlank() you willl get a double negativation smell:
invert-if-not-condition
Now it’s readed as «not not blank» (i.e. blank).

Another one solution is to use method names that hasn’t inversion, for example hasText()

 

Please, avoid this in you code
We will create an Inspection for IntelliJ Idea that will check this cases

[Linkset] «Stringly typed» Antipatern: Avoid string where other types are more appropriate

[Чтиво] Три очень классные практические статьи-инструкции для программистов

Периодически почитываю что накопилось в закладках. Вот отличные прагматичные статьи вкурив которые сразу получите +2 к экспе девелопера.
Экстремальное программирование: Pair Programming чёткая инструкция по делу что такое парное программирование как его делать на практике и самое главное как его НЕ делать.

Парное программирование в аутсорсинге: достижение взаимопонимания с техническими специалистами заказчика Классная статья которую обязан прочесть каждый программист-аутсорсер. Вывод: если у вас есть часть удалённой команды то парно педалить код вы просто обязаны.

Практика рефакторинга в больших проектах в сотый раз о вечном. Для тех кто ещё халтурит и не прочёл замечательную книгу Working Effectively with Legacy Code

Код стайл не только для читаемости но и для редактируемости

Тема код стайла очень хорошо раскрыта в замечательной книге Clean Code.
От себя я бы хотел обратить внимание на пару не очень очевидных вещей к которым пришёл со временем.

  1. Во первых это вертикальная плотность кода (Vertical Density). Где-то я слышал что программист не может в голове держать больше 400 строчек кода. Собственно это и есть лимит на количество строк в вашем файле. Если больше — разбивайте на другие классы.
    Скролить файл вниз — утомляет. Более того, иногда похожие или связанные методы идут рядом и хотелось бы их сразу видеть рядом.
    Ещё один момент — обычно вертикально идут сами команды а горизонтально их параметры.
    Обычно когда ты смотришь в код тебе более важно понять логику и последовательность команд а не их уточнения.
    По сути это визуальное отображение принципа High Cohesion (Сильное Сцепление).
    Поэтому я начал очень сильно следить за вертикальной плотностью и несколько следующих принципов вытекают из этого требования.

  2. Принцип неразрывности — когда вы избегаете писать пустые строки внутри методов потому что обычно являются запахом что тут следовало бы экстрактнуть метод.
    В IntelliJ Ctrl+S > Code Style > Java > Blank lines всё выставьте по нолям или максимум 1

  3. Не переносите строки: сегодня у нас очень широкие мониторы и уже следует избегать переносов команд на две строки. На моём мониторе спокойно влезает по 256 символов. Это более чем достаточно, но обычно IDE переносят строки по границе в 120 символов. Более того, обычно если у час всё равно длинная строчка и не влезает полность на экран то это не страшно — обычно там идут неинтересные параметры вызова метода. В любом случае горизонтально скролить приходится в тысячу раз реже чем вертикально.
    Поэтому сразу полезайте и отключайте эти переносы или ставьте им границу в 400 символов.
    В IntelliJ Ctrl+S > Code Style > General > Right Margin

  4. Джавадоки тоже пытайтесь делать однострочными.
    Т.е. вместо

    /**
    * Some method description
    */
    void someMethod() {
    ...
    }
    

    пытайтесь писать так

    /** Some method description */
    void someMethod() {
    ...
    }
    

    В IntelliJ Ctrl+S > Code Style > Java > Java Doc > Do not wrap one line comments

  5. Отключите выравнивание (arange) кода. Очень многие IDE по умолчанию наводят «красоту» и выравнивают (тут я отметил нижним подчёркиванием _)

    void someMethod() {
    def params = [
    firstName:_'John',
    lastName:__'Doe',
    age:_______42
    ]
    }
    

    С одной стороны принято считать что это добавляет красоты и читаемости. С другой стороны, если вы удалите например первую строчку то вам придётся перевывравнивать соседние сточки и эти изменения подзагадят вам diff в системе контроля версий.
    В IntelliJ Ctrl+Alt+S > Code Style > Java > Wrapping > Align when multiline

Вместо заключения

На стиль кода влияют несколько вещей:
1. Удобство чтения кода — большую часть мы код читаем
2. Возможности IDE — очень многие вещи они могут отображать более удобно (сворачивать гетеры и сетеры, копирайт заголовки, импорт лист).
3. Система контроля версий — очень важно чтобы изменения были как можно более атомарными и в diff’е не было слишком много строк чтобы было проще понять суть.
4. Дебагинг — иногда лучше вместо method chaining выделить переменную потому что дебагер идёт построчно.