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

Именование

Вот несколько советов, которые вы можете использовать, пытаясь назвать переменную, метод, класс или что-то еще.

  • При выборе имен переменных старайтесь использовать логические имена вместо сокращений.

Вместо того, чтобы делать что-то вроде этого:

Попробуйте что-то вроде этого:

  • Избегайте очень длинных имен для переменных. Как правило, если он должен быть длиннее 30 символов, это обычно означает, что он слишком длинный.
  • Убедитесь, что у вас есть последовательные соглашения об именах. Например, если вы используете паскаль, продолжайте использовать его в кодовой базе.

Переменное размещение и магические числа

При создании переменных многие новые разработчики склонны объявлять все переменные, которые они будут использовать, в начале класса или метода. Однако затем происходит то, что вы получаете список переменных, которые вы в конечном итоге используете несколькими строками ниже. Это затрудняет чтение и не имеет смысла, так как зачем объявлять что-то, если вы не собираетесь использовать это сразу. Это может иметь потенциальные последствия для производительности вашего приложения в зависимости от того, что вы инициализируете.

Вместо этого:

Попробуй это:

Магические числа можно описать как случайные целые числа, используемые для битов логики. Например, у вас может быть оператор IF, который проверяет, равен ли статус чего-либо 1. Однако что означает 1? Как человеку, пишущему код, вам может быть совершенно ясно, что 1 означает «черновик», однако для тех, кто читает код, это может сбить с толку.

Вместо этого:

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

Вложенные условия

Обычная вещь, которую делают многие программисты, — это вложение условий if в свой код. Например, если у них есть две вещи, которые они хотят проверить, например, пуста ли эта переменная, и если она пуста, то сделайте еще одну, если внутри, чтобы проверить что-то еще, например, например, длина строки больше 0. Это может раздуть ваш код, затруднить рефакторинг и добавить дополнительную логику позже.

Например, постарайтесь не делать этого:

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

Глядя на приведенный выше пример, вы можете решить его двумя способами. В строке 25 вы можете видеть, что мы объединили оба оператора if в один. Для очень простого примера, приведенного в статье, вероятно, было бы разумнее их объединить. Однако в более реальном примере я бы предложил поставить операторы if, которые проверяют выполнение определенных требований, вверху. Если они не выполнены, то выход из метода. Это повысит производительность и удобочитаемость вашего метода.

Комментарии

Комментарии в вашем коде — одна из вещей, которые действительно могут сделать ваш исходный код очень громоздким без всякой причины. Очень многие программисты добавляют комментарии к своему коду, которые описывают, что делает строка ниже. В этом нет необходимости!

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

Всегда предполагайте, что человек, читающий код, может читать код и не нуждается в объяснениях вроде «Установка переменной в 1», потому что в строке ниже он может увидеть «var temp = 1;».

Например, не делайте этого:

Вместо этого используйте комментарии только в очень сложных сценариях бизнес-логики, где комментарии могут иметь смысл, чтобы дать пользователю контекст относительно того, почему что-то было сделано именно так. Но никогда не используйте комментарии для объяснения кода. Если вам нужны комментарии для объяснения кода, вам, вероятно, следует реорганизовать метод.

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