Оформление кода в Navision: венгерская нотация и проч.
То, что писалось с трудом, должно пониматься с трудом.
Использование венгерской нотации
Все, кто хотя был несколько месяцев занимался разработкой (не обязательно Navision) приходят к венгерской нотации. Ее принципы очень просты: все переменные имеют осмысленные названия, приставку, которая обозначает тип данных и отделяют глобальные переменные от локальных. Приставки обычно делают в 2-4 символа:
dec Decimal,
txt Text,
bln Boolean,
rec Record,
frm Form,
cu, unit Codeunit,
date Date,
time Time,
dtm DateTime,
obj Automation-объекты,
xl Excel Automation-объекты
...
В стандарте Navision переменные типа Record надо писать как имя таблицы – ItemLedgerEntry, CustLedgEntry, в предлагаемом мной варианте их можно сократить, лишь бы сохранился смысл: recItemLE, recCustLE. То же самое касается и форм: из CustomerCardForm получается frmCustCard.
Конструкция WITH … END
Использование этой конструкции улучшает читаемость кода. Сравните сами:
SalesShptLine.TESTFIELD(Type,SalesLine.Type);
SalesShptLine.TESTFIELD("No.",SalesLine."No.");
SalesShptLine.TESTFIELD("Gen. Bus. Posting Group",SalesLine."Gen. Bus. Posting Group");
SalesShptLine.TESTFIELD("Gen. Prod. Posting Group",SalesLine."Gen. Prod. Posting Group");
SalesShptLine.TESTFIELD("Job No.",SalesLine."Job No.");
SalesShptLine.TESTFIELD("Unit of Measure Code",SalesLine."Unit of Measure Code");
SalesShptLine.TESTFIELD("Variant Code",SalesLine."Variant Code");
или
TESTFIELD("Sell-to Customer No.", recSL."Sell-to Customer No.");
TESTFIELD(Type, recSL.Type);
TESTFIELD("No.", recSL."No.");
TESTFIELD("Gen. Bus. Posting Group", recSL."Gen. Bus. Posting Group");
TESTFIELD("Gen. Prod. Posting Group", recSL."Gen. Prod. Posting Group");
TESTFIELD("Job No.", recSL."Job No.");
TESTFIELD("Unit of Measure Code", recSL."Unit of Measure Code");
TESTFIELD("Variant Code", recSL."Variant Code");
END;
Привычка использовать WITH … END есть у всех, кто писал на VB или .NET.
Подробнее о венгерской нотации (которая, кстати, является внутренним стандартом Microsoft) можно почитать в Википедии, MSDN или на CodeNet.
Комментируйте код
Оно полезно всегда, даже если проект ведет всего один человек :) Обычно свои вкрапления в стандартный код выделяют так:
Сам код
.
.
//КОДРАЗРАБОТЧИКА КОДДОРАБОТКИ < ДАТА }
Например:
//IS FIN-015 > 15.01.07 - Протягиваем по фин.учету код машины {
Кроме того, необходимо в начале каждой функции писать краткую аннотацию — для чего она используется. При изменениях в стандартном функционале все изменения полезно прописывать в секции Documentation.
Зачем нужны фигурные скобки? Обычно, если надо протестировать код с/без доработки, можно просто перенести скобку на следующую строку, и все написанное будет закомментировано:
{
НЕНУЖНЫЙ КОД
//IS FIN-015 < 15.01.07 }
Вряд ли я открыл что-то новое для опытных разработчиков, но людям с небольшим опытом, думаю, это будет полезно :)
Автор: Андрей Стрельников
В области Navision - с 2003 года. Профессиональные интересы: NAV, MS SQL, .NET, BPMN, IT-менеджмент. Предметная область: логистика, финансы, склады, 3PL.
Количество статей, опубликованных автором: 86.
[…] абсолютно не нравится венгерская нотация. Я встречал куски кода, соотвествующим им и […]
Венгерская нотация, описанная в статье, неудобна в Navision. Поскольку переменные в отладчике и в C/AL Symbol Menu ищутся только по первой букве, то использование префиксов, указывающих на тип переменных, существенно усложняет поиск. Я предпочитаю именовать так же как в стандартом NAV. Если без указания типа никак не можете обойтись, используйте лучше суффиксы.
Венгерская нотация не удобна, как правило, малоопытным программистам, или, наоборот, слишком опытным разработчикам.
Когда разрабатываешь какой-либо Add-On или функциональность, сопоставимую по объему с 12/22 кодеюнитом, то очень удобно использовать именно такую нотацию.
Автор первого коммента, использует свою нотацию,фактически построенную на основе венгерской.