if (a == true)

[Link]

Цитата:

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

Сравнивать логическую переменную с константой - бессмысленно.

Я так пишу. Не вижу криминала. Считаю это более очевидным, сразу видно, что это булевая переменная.

    boolean                         b;
    Str                             s;
    NoYesId                         n;
;
    if (    b == true
        &&  n == NoYes::Yes
        &&  s != '')
    {

    }
    
    if (    b
        &&  n
        &&  s)
    {
    
    }

[Link]

Цитата:

Сообщение от Владимир Максимов

Честно говоря, не вижу особых проблем. Ну, сравнивают с логической константой и что? Для меня, например, так нагляднее, чем использование восклицательного знака, да еще без пробела. Попробуй еще разгляди его! А так, никакой неоднозначности и не надо "с лупой" искать этот восклицательный знак.

А этот момент есть в бестпрактисе, про логическое отрицание. Рекомендуется его избегать.

[Maxim Gorbunov]

Цитата:

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

Сравнивать две логических переменных можно, но стилистически не красиво.

А что здесь некрасивого? По сути, сравнение двух логических переменных - это XOR (исключающее "или").

[Maxim Gorbunov]

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

* это исключительно моё личное мнение

[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 разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

[Murlin]

Цитата:

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

Вот я и пытаюсь понять - это типа теперь такой best practice ?

зато очень просто читать вот такое например
select count(RecId) from vendTrans where !ventTrans.SettleAmount
убейтя я такое прочитать не могу!!!

[Napalm]

Цитата:

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

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

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

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

[Napalm]

Цитата:

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

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

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

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

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

[S.Kuskov]

AX2012 проверяет сколько полей используется из курсора и если используется 1 поле предлагает заменить select tableBuffer на select FieldList from tableBuffer

[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.

[ice]

Цитата:

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

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

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

а что мешает нанять таких спецов? просто в вакансии требования из "плюсов" перенесите в обязательные

[kashperuk]

Дык не идут к нам...
А те, кто идут, не справляются многие с техническими задачами на интервью.

Более того, ERP программирование - это чуть специфическая область, а нанимаем мы обычно "for Micorosft", то есть человек этот должен иметь потенциал для продолжения работы в Майкрософт в другой команде, к примеру.

[Napalm]

Цитата:

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

а что мешает нанять таких спецов? просто в вакансии требования из "плюсов" перенесите в обязательные

Ага, наймут спецов - а разработку продолжат аутсорсить в Индию.

[fed]

Цитата:

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

Дык не идут к нам...
А те, кто идут, не справляются многие с техническими задачами на интервью.

Более того, ERP программирование - это чуть специфическая область, а нанимаем мы обычно "for Micorosft", то есть человек этот должен иметь потенциал для продолжения работы в Майкрософт в другой команде, к примеру.

Кроме того - с таким менеджментом - вменяемый народ к вам вряд ли пойдет. Вот тебе хорошо, ты полезным делом занимаешься - SCM тестишь. А представляешь - взяли к вам опытного разработчика, 7 лет работы, 10 успешных (или более или менее успешных) проектов. А его на следующий день взяли и посадили ну например интеграцию с киннект писать. Или в очередной 100500ый раз реализовывать новый, еще более революционный интерфейс, формы inventTable. Вопрос - долго ли он у вас после этого проработает ?
Просто счас (как мне знакомые из бундеса говорят) у них там некоторый бум аксаптовский: в консультанты берут просто пользователей Аксапты с опытом (но без понимания системы в целом), в программисты просто C#овцев средней руки. Вот и вопрос - кто же это к вам пойдет на средние заработки, под заведомо невменяемый менеджмент и с достаточно мутными перспективами карьеры ? Только соискатели разрешений на работу...