Читаемость

Не заботься о том, поймет ли написанное твой коллега или другой разработчик. Зачем лишний раз напрягаться? Пусть другой разбирается: это его хлеб, он же тратит 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);

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

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

https://vanar.md/ro/cursuri-profesii

Источник: https://proglib.io/p/kak-pisat-uzhasnyy-kod-delimsya-opytom-2019-10-31