if (a == true)

[fed]

Цитата:

Сообщение от kashperuk

По теме, в Inventory коде добавились еще конструкции вида

if (0 != inventTable.RecId) или if (true == isProductMaster), когда константа идет первой в условии.
Работал у нас парень один из Польши, который до этого писал много на С, и там это повсеместная практика, так как защищает от непроизвольных описок в таких логических условиях (уже забыл конкретные примеры, которые он приводил, когда я первый раз его об этом спросил)

Ну я тоже когда-то много программировал на C. Там всегда есть опасность вместо if(var==1) написать if(var=1). Второй вариант конструкции вполне синтаксически легален, но вместо сравнения, присвоит значение в var, потом результат операции (1) закастует в логическое значение и потом выполнит оператор, поскольку в if() стоит истинное логическое условие. В такой ситуации можно писать условие в вывернутом формате типа if (1==var). Тут уж если нечаянно один знак равенства поставил - компилятор ошибку выдаст.
Но во первых даже в C есть более простое и изящное решение - просто включить варнинги компилятора. Все известные мне компиляторы C, (даже gcc по моему), могут выдавать варнинг при попытке использования оператора присвоения внутри if.
Во вторых - а какое это вообще имеет отношение к Аксапте ? Уж там то нечаянно оператор присвоения в if() не засунешь...

[kashperuk]

Цитата:

Сообщение от fed

Ну я тоже когда-то много программировал на C. Там всегда есть опасность вместо if(var==1) написать if(var=1). Второй вариант конструкции вполне синтаксически легален, но вместо сравнения, присвоит значение в var, потом результат операции (1) закастует в логическое значение и потом выполнит оператор, поскольку в if() стоит истинное логическое условие. В такой ситуации можно писать условие в вывернутом формате типа if (1==var). Тут уж если нечаянно один знак равенства поставил - компилятор ошибку выдаст.
Но во первых даже в C есть более простое и изящное решение - просто включить варнинги компилятора. Все известные мне компиляторы C, (даже gcc по моему), могут выдавать варнинг при попытке использования оператора присвоения внутри if.
Во вторых - а какое это вообще имеет отношение к Аксапте ? Уж там то нечаянно оператор присвоения в if() не засунешь...

Да, точно, именно из-за присвоения и равенства он это делал.
А отношение имеет прямое - просто показывает, что у нас нету жестких рекомендаций написания кода, поэтому все пишут "как хотят".

[Vadik]

Цитата:

Сообщение от kashperuk

А отношение имеет прямое - просто показывает, что у нас нету жестких рекомендаций написания кода, поэтому все пишут "как хотят".

А вот это напрасно - хотя бы из уважения к людям которым потом эти письма дяди Федора разбирать и фиксить стоило бы этим озаботиться

[fed]

Цитата:

Сообщение от Vadik

А вот это напрасно - хотя бы из уважения к людям которым потом эти письма дяди Федора разбирать и фиксить стоило бы этим озаботиться

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

[Napalm]

Цитата:

Сообщение от fed

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

Меня вообще бесит использование списка полей. Например некоторые "оптимизируют" свой код так:

select forupdate BankAccount from custTable
    where custTable.AccountNum == "Account";
    
custTable.BankAccount = "BankAccount";
custTable.update();

[mayk]

Цитата:

Сообщение от fed

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

Это вообще-то является BP

Цитата:

If a select statement is local to a method, use a field list to increase performance. If you use
a select or a while select statement and the size of the fields that are used total less than 50
percent of the total record size, a warning appears if you do not use a field list.

и существенно ускоряеет выполнение запросов, так как в сеть не пихается туча данных, из которых не используется и половина.

Другое дело, что подобная оптимизация порождает трудно отлавливаемые баги если кто-нибудь вдруг догадается добавить вызов display метода не проверив, какие поля он использует.

Что самое противное

    select Arrived from inventSum;
    print inventSum.AvailOrdered;

проходит проверку BP в 2009. Если честно, я бы предпочел чтобы аксапта хранила список полей которые были инициализированы и сразу вываливала инфолог при обращении к не инициализированному полю вместо того говорить что там пусто.

[fed]

Цитата:

Сообщение от mayk

Это вообще-то является BP
If a select statement is local to a method, use a field list to increase performance. If you use
a select or a while select statement and the size of the fields that are used total less than 50
percent of the total record size, a warning appears if you do not use a field list.

и существенно ускоряеет выполнение запросов, так как в сеть не пихается туча данных, из которых не используется и половина.

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

1. Есть покрывающий индекс состоящий из полей в списке выбора и условия where. (Надо помнить что все индексы неявным образом включают поля кластерного индекса. Так что некластерный индекс может покрывать больше полей чем вы ожидали.)
2. Если в таблице есть мемо-поля (контейнеры или строковые поля с длинной (Memo)). И те и другие долго подгружать и пересылать
3. Если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь ?
4. Ну и я бы пожалуй добавил случай экстремальной оптимизации. Скажем если мы засунули новый запрос в какое-то ключевое место нагруженных алгоритмов - типа закрытия склада,рассчета покрытия или ресурсного планирования, то экономия 3% на перекачку данных, в запросе, который исполняется миллионы раз, может оказаться выгодной

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

Этот пример еще раз подтверждает мою мысль что Аксаптовские Development Best Practice пишутся не для реальных проектов, а для разработки сферического коня в кубе...

[kashperuk]

Цитата:

Сообщение от fed

Этот пример еще раз подтверждает мою мысль что Аксаптовские Development Best Practice пишутся не для реальных проектов, а для разработки сферического коня в кубе...

Для того, чтобы они писались с учетом опыта реальных проектов, надо чтобы этот опыт у людей был Это, к моему большому сожалению, не так в большинстве случаев.

Так что милости просим к нам на работу, кто хочет изменить положение вещей и привнести реальный опыт внедрения АХ в код на SYS layer.

[gl00mie]

Цитата:

Сообщение от fed

С точки зрения производительности, выгодно указывать список полей если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь?

Любые шапки/строки журналов/заказов/документов (которые надо иметь возможность перепечатывать постфактум в исходном виде несмотря на изменения в справочниках), сами справочники (клиенты, поставщики, номенклатура, сотрудники, ОСы, etc) обычно даже в стандартном приложении содержат число полей, близкое или намного превышающее указанный предел, а уж с учетом кастомизаций - и подавно.

Цитата:

Сообщение от fed

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

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