Don't Reinvent Wheel — Не переизобретайте колесо
Не переизобретайте колесо — если подобное колесо уже существует, просто адаптируйте его для своих нужд. Вероятно, для решения данной проблемы уже существует стандартный модуль в дистрибутиве Perl, или модуль из CPAN, или модуль, разработанный другими людьми внутри организации.
Do not Repeat Youself — не повторяй самого себя
Подумайте о повторном использовании кода. Зачем тратить впустую усилия мысли на одноразовые программы, если в будущем вам может потребоваться что-то подобное снова? Подумайте над обобщением вашего кода. Подумайте над написанием модуля или класса. Позаботьтесь о том, чтоб ваш код выполнялся без предупреждений с "use strict" и "use warnings" (или -w). Подумайте, не предложить ли Ваш код другим.
KISS — Keep It Simple, Stupid
Всегда и везде стОит придерживаться максимально простых решений, как в области архитектуры, так и в области непосредственно кодирования.
Не делайте лишних движений и лишних разработок до тех пор, пока Вам реально не понадобится подобная функциональность. Возможно, ситуация / требования изменятся и то, что Вы делаете, не понадобится никогда.
Не живите с «разбитыми окнами»
Не оставляйте «разбитые окна» (неудачные конструкции, неверные решения или некачественный текст программы) без внимания. Как только Вы их обнаружите — чините сразу. Часто безошибочные, функциональные системы быстро портились, как только окна начали разбиваться. Не давайте энтропии победить себя.
Выкладывайте все модули общего назначения в общий доступ
Если создаваемый Вами модуль или группа модулей жёстко не привязаны к разрабатываемой системе, а являются модулями «общего назначения», которые могут быть интересны другим разработчикам, лучше выделять такие модули в отдельные дистрибутивы и выкладывать на CPAN, в корпоративный репозиторий opensource-разработок или хотя бы на собственные домашние странички.
Зачем?
- Система и основной репозиторий «не захламляются» тем самым модулями общего назначения. В результате в основной системе легче ориентироваться
- Подготовка модулей к выкладке в общий доступ неизбежно повышает их качество (как минимум надо создавать документацию и тесты, «выпрямлять» код)
- Получаем все преимущества OpenSource (другие люди присылают багрепорты и патчи, способствуя улучшению модулей)
- Мы должны не только брать, но и отдавать что-то OpenSource-сообществу, возвращая тем самым свой долг
- Приятно раскручивать своё имя в CPAN ;)
Не исправляйте чужой код без причин
Нельзя исправлять чужой код, если на это нет вообще никаких причин (кроме личных представлений исправляющего, не зафиксированных в coding standards).
В том числе не нужно исправлять пробелы и выравнивания, если код и так нормально смотрится (субъективно) и не нарушают coding standards (объективно). Не нужно исправлять код если и до и после исправления он работает абсолютно одинаково и исправление не улучшило ничего - ни архитектуру/API, ни реализацию (исправление багов, уместная оптимизация, удаление ненужного кода), ни соответствие стандартам.
Исключение составляют ситуации, когда Вы вносите большие исправления в этот участок кода в рамках какой-либо вашей задачи.
Использование exists и defined (defined-or)
В булевом контексте не стоит использовать функции exists и defined (и аналогичные конструкции с оператором defined-or: "//", "//="), если можно обойтись без них.
- Если элемент хэша по логике может либо отсутствовать, либо быть булевым TRUE, то не стоит применять к нему функции defined и exists.
- Если элемент хэша по логике может либо отсутствовать, либо быть TRUE, либо быть FALSE, то не применять к нему функцию exists.
Цель - не стоит "делить" элементы на "not exists", "defined", "FALSE", "TRUE", когда можно обойтись только "TRUE" и "FALSE".
Не используйте экспериментальные возможности Perl
Не используйте given, when, smartmatch (~~) и другие экспериментальные возможности, по крайней мере до тех пор пока их судьба в последующих версиях Perl остаётся неясной.