Хороший критерий качества кода, а заодно и ориентир, как программировать писать - это удобство устроения пасхальных яиц и дорвеев. То есть, если мы пишем какую-то часть программы, полезно представить картинку, как этот кусок используется нами хитрым скрытным способом в корыстных целях. Как наши вредно-полезные действия вызывается всего одной маленькой незаметной строчкой из другой части программы. Например, делаем мы классик для форматирования диска. Хорошо сделать его так, чтобы если вдруг вам захочется при нажатии мышкой трижды в определенном месте окна запускать форматирование диска С, вы бы могли это сделать. Причем так, что если ваши коллеги будут просматривать ваш код, они ничего бы не заметили. А если бы и заметили, то чтобы можно было сказать - "это случайный баг". То есть, плохо, если такой вызов потребует объявления класса Formater и инициализацию всевозможных структур с опциями, и всё это внутри метода on_click. Слишком палево. Надо переписать класс Formater так, чтобы его можно было использовать без параметров, или хотя бы с минимумом. Сделать ему удобный и лаконичный фасад. Подумать, как можно сделать опосредованный вызов - через другие классы, где форматирование к месту и не вызывает подозрений. Сделать этим классам удобный интерфейс. Далее, надо сделать так, чтобы отлов троекратного нажатия не требовал кучи кода, вызывающего у коллег вопросы, на которые будет сложно ответить. Для этого следует сделать какой-то диспетчер событий и механизм сообщений с привязанными обработчиками. Перевести на него внутреннюю кухню вашего продукта. Сделать диспетчеру удобный и лаконичный интерфейс, чтобы можно было подусунуть в него новое событие и новый обработчик из неожиданного места одной незаметной строкой. Стремиться делать интерфейсы классов простыми, ясными и гибкими - чтобы ничего не помешало вашей диверсии.
Подготовка к устройству незаметного дорвея ценна сама по себе - это метод взглянуть на свой код по-новому и реалистично оценить его качество. Оставлять же дорвей в релизе не стоит. Это плохо для карьеры.