Оформление кода в Navision: венгерская нотация и проч.

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

У Navision есть свои, официально принятые стандарты написания и оформления кода, однако я хочу поделиться небольшими дополнениями на сей счет. Связаны они с улучшением читаемости кода и помогают отделить стандартный функционал от доработок.

Использование венгерской нотации

Все, кто хотя был несколько месяцев занимался разработкой (не обязательно Navision) приходят к венгерской нотации. Ее принципы очень просты: все переменные имеют осмысленные названия, приставку, которая обозначает тип данных и отделяют глобальные переменные от локальных. Приставки обычно делают в 2-4 символа:

int Integer,
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("Sell-to Customer No.",SalesLine."Sell-to Customer No.");
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");

или

WITH SalesShptLine DO BEGIN
  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
{
НЕНУЖНЫЙ КОД
//IS FIN-015 < 15.01.07 }

Вряд ли я открыл что-то новое для опытных разработчиков, но людям с небольшим опытом, думаю, это будет полезно :)

Автор:

В области Navision - с 2003 года. Профессиональные интересы: NAV, MS SQL, .NET, BPMN, IT-менеджмент. Предметная область: логистика, финансы, склады, 3PL.

Количество статей, опубликованных автором: 86.

Комментарии (3 комментария)

  1. […] абсолютно не нравится венгерская нотация.  Я встречал куски кода, соотвествующим им и […]

  2. NataIDM

    Венгерская нотация, описанная в статье, неудобна в Navision. Поскольку переменные в отладчике и в C/AL Symbol Menu ищутся только по первой букве, то использование префиксов, указывающих на тип переменных, существенно усложняет поиск. Я предпочитаю именовать так же как в стандартом NAV. Если без указания типа никак не можете обойтись, используйте лучше суффиксы.

  3. Роман

    Венгерская нотация не удобна, как правило, малоопытным программистам, или, наоборот, слишком опытным разработчикам.
    Когда разрабатываешь какой-либо Add-On или функциональность, сопоставимую по объему с 12/22 кодеюнитом, то очень удобно использовать именно такую нотацию.

    Автор первого коммента, использует свою нотацию,фактически построенную на основе венгерской.

Добавить комментарий