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

Для того чтобы код выглядел чистым (что по сути обеспечивает нормальную работу в команде), нужно следовать нескольким простым правилам, которыми никогда не нужно пренебрегать.

Пишем красивый и чистый программный код

1. Тщательно продумайте логику, перед тем как начать кодить

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

2. Чётко обозначьте для себя структуру вашей страницы

Работать с определёнными контейнерами очень удобно, но ещё более удобно работать с контейнерами, у которых есть определённые ID. Предположим, что мы имеем дело со следующим фрагментом кода:

Благодаря данной технике, разобраться в структуре данной страницы не составляет никакого труда, так как почти у каждого блока DIV есть свой идентификатор. В этом случае, не только проще добавлять код. Почти каждый без особого труда сможет понять и изменить структуру, если это будет необходимо. Однако данное правило нужно принимать во внимание в связке со следующим.

3. Используйте понятные идентификаторы

Для того чтобы пример рассмотренной вами структуры был понятен почти каждому после нескольких секунд, необходимо давать ясные имена идентификаторов. Также необходимо принимать во внимание форматирование, которое также играет важную роль в читабельности кода. Согласитесь, что это не очень сложно! Однако данные техники помогут вам, и не раз.

4. Пишите краткие и понятные комментарии

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

Многие разработчики не любят писать комментарии. Это вполне можно понять, однако часто это просто необходимо, потому что всё чаще и чаще масштабы и количество проектов увеличивается и всё поместиться в голове не может. Но тут есть и обратная сторона медали, но об этом в следующем пункте.

5. Используйте комментарии без фанатизма

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

• Написание комментариев для себя (пример: /* Закончу как-нибудь потом... */).
• Отвод глаз от себя (пример: /* это писал Johns.С него и спрос. */).
• Ни о чём не говорящие выражения (e.g. /* Это очередная математическая функция. */).
• Также иногда люди не уверены в какой-то функциональности и просто комментируют фрагмент кода.

Данные комментарии бессмыслены и могут ввести человека в заблуждение. У каждого комментария должен быть свой смысл. Никогда не забывайте об этом

Примеры хороших комментариев:

• Спецификация автора (пример: /* Автор John, 13 Ноября 2010 */).
• Какая-то детализация метода или процедуры (пример: /* Данный метод предназначен для валидации формы входа пользователя в систему */).
• Быстрые заметки или описание изменений в коде (e.g. /* Добавлена валидация e-mail */).

6. Не пишите слишком большие методы

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

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

7. Используйте стандарты именования переменных и функций

Когда вы начинаете писать функцию или создаёте новую переменную, её имя должно иметь описательный характер. Разработчик с первого взгляда должен понять, для чего она нужна.

Существует немало компаний, в которых узаконены свои собственные стандарты именования методов и переменных (пример: префикс 'int_' для всех переменных данного типа), но также наравне с ними существует масса компаний где вообще нет никаких стандартов. Из-за своей лени работники данных компаний часто делают одну и ту же работу вдвое дольше. Как вы думаете? Это нормально?

8. Осторожно производите все изменения

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

Так же необходимо учитывать следующее:

• Сохраняйте код читабельным (пример: если вы добавляете условный оператор IF, то обратите внимание на форматирование кода).
• Создавайте дополнительные комменты.
• Уважайте стандарты, согласно которым был написан данный метод.

9. Избегайте бурных смесей различных языков программирования

CSS встроенные в теги и небольшие фрагменты JavaScript в середине кода - это неверные примеры смешивания языков программирования, которые часто встречаются в реальной жизни. Многие люди часто используют атрибут STYLE, для того чтобы по-быстрому добавить какой-то стиль. Это на самом деле может привести к потери времени в будущем, когда необходимо будет произвести какие-то изменения.

10. Ограничивайте импорт файлов

Это конечно хорошо, когда функциональность разбита на несколько файлов, но тут всё тоже должно быть в меру. Если у вас есть несколько файлов с таблицами стилей их можно и даже нужно объединить в один.

Это сэкономит место и позволит сохранить порядок в проекте, к тому же уменьшит время загрузки страницы. Каждый импорт файла это отдельный HTTP запрос, который занимает определённое время загрузки вашего приложения.

Время действовать

Я согласен с тем, что выполнять все эти правила не всегда удобно, однако это может помочь вам в будущем. К тому же вы здорово сможете увеличить эффективность написания кода. К тому же, всё чаще и чаще люди убеждаются в том, что необходимо идти в ногу со стандартами, для того чтобы сохранить код читабельным. Учитывая, что не всегда один и тот же человек работает над одним и тем же фрагментом кода, эти правила очень важны. Всё это - залог успеха работы в команде.