Порядок чтения кода

Представьте, что вы читаете модуль и пытаетесь понять что он делает. Просмотрели его до конца и только там увидели, то что вам нужно. Тот конкретный метод, который помог вам понять все остальное содержание модуля.

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

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

При этом идеального порядка методов не существует: • иногда стоит сначала понять примитивы, а потом разбираться в их объединении • иногда лучше начать с понимания API, а затем переходить к подробностям реализации • иногда лучше добавить описание всего модуля в начало

Представьте себя на месте читателя и руководствуйтесь здравым смыслом и опытом. Какой порядок предпочли бы вы?

Пусть последовательность, которую вы выбрали, порадует следующего читателя.

Плохо:

Процедура РассчитатьИтог() КонецПроцедуры

Процедура ЗаполнитьДоговор() КонецПроцедуры

Процедура ПриИзмененииОтбораОрганизации() КонецПроцедуры

Процедура СоздатьДокумент() КонецПроцедуры

Лучше:

Процедура СоздатьДокумент() КонецПроцедуры

Процедура ЗаполнитьДоговор() КонецПроцедуры

Процедура РассчитатьИтог() КонецПроцедуры

Процедура ПриИзмененииОтбораОрганизации() КонецПроцедуры

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