Несколько советов по программированию и принципов написания читаемого кода

Написание кода для Программного обеспечения часто бывает сложной задачей, особенно когда мы создаем большое программное обеспечение, когда разные люди имеют доступ к исходному коду, и каждому разрешается писать свой фрагмент кода. На протяжении последних лет я работал над разными программными проектами с разными командами, и должен сказать, что не весь код, который я написал, я мог даже понять, но он просто работал. Я часто задаюсь вопросом, как это сделать. Статистика доказала, что разработчики программного обеспечения (кодеры) тратят больше времени на чтение, чем на написание кода. Прежде чем я начну писать какой-либо фрагмент кода, я выполняю следующие шаги:

  • Разберитесь в проблеме:

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

  • Определите как минимум два возможных способа решения проблемы:

Наличие различных способов решения проблемы помогает разработчику или команде выбрать наиболее эффективный путь или курс для достижения решения. Например. Давайте возьмем реальный пример: когда мы используем современный GPS, он просто дает нам два или более разных маршрута для выбора, так что мы выбираем тот, на который меньше времени, или тот, который нам удобнее.

  • Выберите лучшее решение среди различных возможностей:

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

  • Документ:

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

  • Выберите лучший язык программирования для решения проблемы:

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

Разработка решения

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

  • Организация папок и файлов:

Как новички, мы, как правило, пишем наш код в одном файле для всего решения («Я делал это много»), но по мере расширения решения для нашего программного обеспечения мы получим длинную страницу, и мы можем получить потеряны в нашем коде, поддерживать который будет кошмаром. Решение состоит в том, чтобы разделить ваш код с помощью папок и файлов, содержащих определенные части вашего программного обеспечения.

  • Выберите схему именования для использования во всем проекте:

Это возвращает меня к распространенной ошибке, которую большинство из нас совершало при запуске. Наличие схемы именования ваших переменных или функций буквально помогает определить чистый и последовательный стиль. Я часто использую camelCasing (где первая буква каждого слова пишется с заглавной буквы, кроме первой) в качестве схемы для наименования моей переменной, функций и классов.

string myString //variable 
myFunction() //function 
MyClassName //class

Обратите внимание, что для классов; желательно начинать регистр с заглавной буквы.

  • Используйте легко запоминающиеся имена для переменных:

Переменная с правильным названием помогает разработчику кода или другим членам команды легко понять, когда использовать эту переменную и почему она там есть. Допустим, мы хотим суммировать два числа, тогда мы будем использовать следующие имена для наших переменных: сумма, число1 и число2.

int num1; //receives the first number
int num2; //receives the second number
int sum; //will store the result of the sum of both numbers

При именовании нашей переменной, или даже функции, или класса вы должны помнить, что имя, которое вы выбираете, должно определять желаемое действие. «Длинное описательное имя лучше, чем короткое загадочное имя. Длинное описательное имя лучше, чем длинный описательный комментарий ». - Дядя Боб

  • Прокомментируйте свой код:

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

  • Принцип СУХОЙ:

DRY означает не повторяться; этот принцип утверждает, что; «Каждая часть знания должна иметь единственное, недвусмысленное и авторитетное представление в системе». По сути, вы должны избегать кодирования одного и того же более одного раза, разделяя общий код с помощью функций.

Https://www.youtube.com/watch?v=Mw0AdBg4c8M

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

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

Как говорит дядя Боб, «чистый код не пишется по набору правил. Вы не станете мастером программного обеспечения, изучив список эвристик. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину ».

«Нарисуйте дважды код один раз»