Читаемость

Не заботься о том, поймет ли написанное твой коллега или другой разработчик. Зачем лишний раз напрягаться? Пусть другой разбирается: это его хлеб, он же тратит 80-90% рабочего времени на чтение.

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

Правилом хорошего тона является красивая вложенность кода:

        if { ……….
   if { ……….
      if { ……….
         if { ……….
            if { ……….
               if { ……….
                   if { ……….
                    else { ……….
               else { ……….
            else { ……….
         else { ……….
       else { ……….

     else { ……….

else { ……….
    

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

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

Переменные, воображение, имена

Важное правило – следуй общепринятым соглашениям, но как можно реже.

char imya-polzovatelja и String moyVariant-ssilki – это то, к чему тебе нужно стремиться в первую очередь, и тимлид обязательно это одобрит при первом же ревью. Придерживайся своего подхода во всем коде: это очень профессионально, когда имена всех переменных и функций подбираются по одному принципу.

Пробелы между условиями цикла for (var i = 0; i < 100; i++) – это ненужные символы и занятое место. Ах да, и вместо общепринятых переменных (i, j, k) используй все, что хочешь, на твой вкус.

Когда в команду (или на твое место) придет новичок, ему будет сложно дописывать и сопровождать твою “писанину”: ему придется писать в твоем стиле – уже круто! Код непонятных присваиваний, наследований и прочих событий будет только расти, превращая программу в монстра.

Когда твоя способность к выдумке иссякнет, добавляй к имени переменной цифру: data1, data2 и т. д. Такой подход облегчит понимание кода (понятно же, что в переменной находятся данные), а нумерация разнообразит стену твоих заклинаний.

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

Вот пример. В программе ты работаешь с автомобилями. Для описания переменной с авто строго обязательно использовать в одном месте имя auto, дальше – avto, а в следующей строке – a. Вот она, инкапсуляция! Элементарно, понятно и эффективно, а не как Джошуа Блох с целой главой, посвященной этой теме…

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

        } else {

 // WTF?!

return userName;

}
    

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

Чем длиннее – тем хуже

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

        private int averageRoomRatePerNight;
    

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

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

        i = i ? i < 0 ? Math.max(0, len + i) : i : 0;
    

Ты же профессионал своего дела, и плевать на мнение других!

        float maxBooking = voyage.Capacity * 1.1
    

Что такое 1.1, откуда это берет начало? Сойдет! Поехали дальше.

Не нарушай ход событий

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

Если ты вдруг взялся переписывать чужой код и встретил метод, который что-то проверяет (например, isNumeric), немедленно перепиши его. Сделай так, чтобы он не только возвращал true/false, но еще и печатал что-то в консоль и выводил результаты какого-либо расчета. Писать под одну задачу свою функцию?! Вот еще! И вообще, лучше совсем не использовать функции. Пиши все одной “простыней” – это и более понятно и не нужно утруждаться. Не страшно, что такой подход увеличивает вероятность появления ошибок в совершенно разных местах и лишает код абстракций. Не зацикливайся на таких мелочах.

Заключение

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

        date.add(5);
    

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

Были ли у тебя на практике примеры ужасного кода? Делись в комментариях.