Отправляет email-рассылки с помощью сервиса Sendsay

Navision - советы и секреты

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Идеи бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Февраль 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Автор
Neubitiy

Статистика

0 подписчиков
0 за неделю
←   Все выпуски   →

Navision - советы и секреты


Дружим-3. Время по Гринвичу.

Добрый день!

Очередной нюанс работы с сиквелом касается типа данных DateTime. На первый взгляд - точная копия сиквеловского datetime, НО - одно важное Но: в базе навижновское поле хранится в формате UTC (бывший GMT - Greenwich Mean Time). Если не знать этого факта (я до определенного времени не знал :) - то можно сильно удивиться, сделав в Query Analizer’е SELECT из таблички с этим полем, сравнить время и увидеть - оно отстает на 3 часа (для Москвы).

Вывод - при работе с полями DateTime вместо функции GETDATE() надо использовать GETUTCDATE().

Вывод номер два - при построении сложных распределенных систем надо учитывать фактор смены часовых поясов - и - о чудо! - тут нам тоже придет на помощь тип данных DateTime :)

Хочу заметить, что для отдельных типов Date и Time это правило не работает (логично). Более того, функции TODAY() и TIME() возвращают значения, установленные в операционной системе.

А теперь немного оторвемся от темы сиквела…

Оформление кода в Navision.

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

1) Венгерская нотация.

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

int - Integer,
dec - Decimal,
txt - Text,
bln - Boolean,
rec - Record,
frm - Form,
cu - Codeunit,
date - Date,
time - Time,
dtm - DateTime,
obj - Automation-объекты,
xl - Excel Automation-объекты и т.д.

В стандарте Navision переменные типа Record надо писать как имя таблицы - ItemLedgerEntry, CustLedgEntry, в предлагаемом мной варианте их можно сократить, лишь бы сохранился смысл: recItemLE, recCustLE. То же самое касается и форм: из CustomerCardForm получается frmCustCard.

2) 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.

3) комментирование.

Оно полезно всегда, даже если проект ведет всего один человек :) Обычно свои вкрапления в стандартный код выделяют так:

//КОДРАЗРАБОТЧИКА КОДДОРАБОТКИ > ДАТА - Зачем нужен этот код {

Сам код
 .
 .
 .
//КОДРАЗРАБОТЧИКА КОДДОРАБОТКИ < ДАТА }

Например: //IS FIN-015 > 15.01.07 - Протягиваем по фин.учету код машины {

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

Зачем нужны фигурные скобки? Обычно, если надо протестировать код с/без доработки, можно просто перенести скобку на следующую строку, и все написанное будет закомментировано:

//IS FIN-015 > 15.01.07
{
НЕНУЖНЫЙ КОД
//IS FIN-015 < 15.01.07 }

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

На сегодня всё. Всех защитников - с Праздником!

P.S.Хотите поделиться своими знаниями? Всегда Welcome! Любые статьи, Q & A, FAQ, советы - все опубликуем, обязательно укажем автора и дадим линк на сайт :-)

С наилучшими пожеланиями,
Андрей Стрельников.

Группа «Technologies like Art».
Разработки в сфере Navision. Скоростные и суперскоростные оптимизации, системная интеграция.
e-mail: likeart@mail.ru.

Технологии как искусство.
Что такое главное?
В избранное