Всегда структурируйте свой код.

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

Ваша задача – чтобы после вас код всегда становился чуточку лучше.

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

Если пишете код с нуля, то старайтесь сразу придерживаться правил хорошего кода. Не надейтесь потом вернуться и сделать получше код. Пишите сразу нормально! Не бывает такого кода, который потом не поддерживается (т.е. не меняется). В любом случае ваш код увидят коллеги и от его качества будет зависеть – будут ли они плеваться от вашего кода или с легкостью читать как увлекательную книгу.

Первое, что нужно делать – это следовать архитектуре своего приложения. Нельзя писать так как вы привыкли, если это противоречит архитектуре приложения. В наших проектах обычно выделяется слой доступа к данным (DAL) и уровень бизнес-логики (BLL).

Раньше мы не разделяли эти понятия, т.к. для более-менее простых приложений это действительно не имеет смысла. Это нужно делать, когда приложение содержит сложную бизнес-логику. DAL обычно содержит просто методы CRUD для сущностей системы. BLL содержит методы, которые используют различные методы DAL и при этом реализуют бизнес-логику приложения. Т.е. старайтесь не делать бизнес логику в самих страницах (View или Controller). Старайтесь все это по максимуму поместить в уровень BLL. Что это может быть:

  • Проверка прав доступа
  • Кеширование
  • Логирование операций
  • Выполнение несколько операций совместно
  • Отправка на почту или смс

Повторяемые функции

Следующий момент – все повторяемые функции выделяйте в библиотеки.

Если это компонент общего назначения, то оформите его как компонент, который можно будет потом легко перенести в другой проект (такие компоненты лучше делать в виде JS-компонентов, или в виде части общей библиотеки RDL). Если функциональность относится только к одному проекту – то помещайте ее в уровень BLL соответствующей подсистемы.

Самое главное – наращивайте свою кодовую базу.

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

В курсе Core мы описывали как сделать заготовку простого компонента JS. Используйте ее чтобы обернуть любую полезную функциональность, которая может пригодиться в будущем. Наша библиотеку as.js содержит кучу собранных полезных функций, которые вы можете уже использовать. От вас буду ждать предложений по включение дополнительных полезных модулей в эту библиотеку.

Данные и код – отдельно

Следующий важный принцип: данные – отдельно, код – отдельно.

Данные желательно хранить в каком-либо источнике, например, база данных. Если у вас есть какие-то строки или числа – вынесите их в настройки, которые можно редактировать в админке системы.

Не делайте в программе магических чисел (т.е. например, где-то в условии стоит просто число 14). Тоже выносите в настройку и дайте ей понятное лаконичное название. На худой конец можно вынести в Web.config в AppSetting.

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

Нотация

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

  • Методкласса GetProduct (string name, int catID)
  • Скрытая переменная класса _productID
  • Publiс поле класса ProductID
  • Название класса ProductManager
  • Константа MAX_PRODUCT_NUM
  • Статичная переменная класса GetProduct
  • Локальная переменная productID
  • CSS стиль as-cover
  • Таблица в базе ct_products
  • Поле в базе catID
  • Индексвбазе ind_ct_products_catID

Также важный момент – пишите однообразно код в плане отступов.

Следуйте тому стилю, который выбран в проекте. Это относится как к коду C#, JS так и к CSS. Например, CSS мы пишем сейчас обычно так:

body{ color:red; margin: 20px;}

а раньше писали так:

body{

color:red; margin: 20px;

}

Уберите все лишние комментарии. Комментарий – это всегда костыль.

Иногда костыль нужен. Но разве нужен костыль здоровой ноге? Если ваш код написан правильно, имеет понятные структуру и имена переменных и функций – не пишите лишние комментарии.

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

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

Последний момент – это типовая структура функций. У функции всегда есть 3 секции:

  • Инициализация
  • Вычисления
  • Результат

Пример для JS:

function getProduct(id){

       var res = {};

       //// calculate

       return res;

}

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

  • res – выходная переменная, результат функции
  • s, sb – суммирование строк (через массив или StringBuilder)
  • i, j – счетчики в массиве
  • cn, cmd, dr – ConnectionString, SQLCommand и DataReader используемые вNET.
  • id – идентификатор сущности
  • g, guid – уникальный 32 битный идентификатор сущности (Guid)
  • params – параметры ajax запроса.
  • data – выходной параметр в success функции (data.result и data.message – результат операции и выдаваемое сообщение соответственно).

Постепенно внедряйте все эти функции. Если хотите пойти дальше – то читайте С. Макконелла Совершенный код. Самое главное – применяйте все это на практике, чтобы ваш код было приятно читать.

Далее рассмотрим архитектуру и проектирование.