if (a == true)

[kashperuk]

Интересная дискуссия.
Best practice такого конкретно нет, насколько мне известно, но этому и не препятствуют, так как, как уже многие написали, абсолютно легальная операция и многие предпочитают именно такой стиль написания.

Личное мне это тоже всегда бросается в глаза, но чаще в других случаях, когда используются таблицы, и вместо if (inventTable) используется что-нить типа if (inventTable.ItemId != "")
Но тому тоже есть теоретически верные аргументы, поэтому такие структуры я вижу в коде все чаще.

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

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


А про общее снижение кода... Да, я тоже считаю, что это так. Особенно учитывая сколько кода мы купили у партнеров.

[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 пишутся не для реальных проектов, а для разработки сферического коня в кубе...

[Napalm]

Цитата:

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

Работал у нас парень один из Польши, который до этого писал много на С, и там это повсеместная практика, так как защищает от непроизвольных описок в таких логических условиях (уже забыл конкретные примеры, которые он приводил, когда я первый раз его об этом спросил)

Вот именно, работал на C - пишет на X++, используя best practices из С. Работал на FoxPro - пишет на X++, используя best practices из FoxPro, и т.п.

А надо писать на X++, используя best practices и naming conventions из X++.