Всегда структурируйте свой код.
Есть такое понятие как «загнивание» кода. Вы написали какой-то код, потом в него вносятся правки по пожеланию заказчика, исправляются ошибки, дописываются отдельные случаи. Код обрастает вторичной логикой и становится менее стройным – именно это подразумевается под загниванием кода.
Ваша задача – чтобы после вас код всегда становился чуточку лучше.
Этого можно достичь с помощью рефакторинга (переименование функций и переменных, выделение функций).
Если пишете код с нуля, то старайтесь сразу придерживаться правил хорошего кода. Не надейтесь потом вернуться и сделать получше код. Пишите сразу нормально! Не бывает такого кода, который потом не поддерживается (т.е. не меняется). В любом случае ваш код увидят коллеги и от его качества будет зависеть – будут ли они плеваться от вашего кода или с легкостью читать как увлекательную книгу.
Первое, что нужно делать – это следовать архитектуре своего приложения. Нельзя писать так как вы привыкли, если это противоречит архитектуре приложения. В наших проектах обычно выделяется слой доступа к данным (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 – результат операции и выдаваемое сообщение соответственно).
Постепенно внедряйте все эти функции. Если хотите пойти дальше – то читайте С. Макконелла Совершенный код. Самое главное – применяйте все это на практике, чтобы ваш код было приятно читать.
Далее рассмотрим архитектуру и проектирование.