Интересное мнение про ООП - страница 9

[fxsaber]

Igor Makanu:

с 99% уверенностью, считаю, что на уровне процессора эти коды будут выполняться с одинаковой скоростью до такта - в процессоре еще оптимизация, распараллеливание и хз что еще на уровне микрокоманд работает

Не получается ли здесь негативный эффект, когда пишется любого качества код из расчета "компилятор причешет до оптимального"?

При одном стиле написания знаешь точно, компилятор сделает, как надо. При другом - только уповать, что компилятор умнее.

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

[Igor Makanu]

fxsaber:

Не получается ли здесь негативный эффект, когда пишется любого качества код из расчета "компилятор причешет до оптимального"?

мои примеры - ну как бы вряд ли любого качества, это типовые конструкции - я давно на гитхабе исходники сравниваю, что tst1 , что tst2 пример , оба активно используются программистами

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

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

fxsaber:

При одном стиле написания знаешь точно, компилятор сделает, как надо. При другом - только уповать, что компилятор умнее.

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

... а остальное, имхо, от лукавого )))

ЗЫ: есть еще оптимизация кода на уровне компилятора, мало читал - все на уровне догадок, по железу ПК периодически читаю, давно читаю, свое мнение написал

fxsaber:

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

тогда вариантов, как бы нет - если кратко: "я художник - я так вижу"  )))  , надеюсь не задел

[Valeriy Yastremskiy]

У меня правило, через лет 5 код должен быть понятен кодеру, если не понятен, плохой код.

А если понятен и другим, очень хороший.

[fxsaber]

Valeriy Yastremskiy:

У меня правило, через лет 5 код должен быть понятен кодеру, если не понятен, плохой код.

А если понятен и другим, очень хороший.

Вот здесь ( и тут) очень хороший код. Но я его не понимаю. Соображалка давно прекратила расти.

[Valeriy Yastremskiy]

fxsaber:

Вот здесь ( и тут) очень хороший код. Но я его не понимаю. Соображалка давно прекратила расти.

темы сложные. их не каждый поймет,) не то что код.

[Georgiy Merts]

Ох, какая тема... И без меня... Непорядок... Надо высказаться.

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

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

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

Как мне кажется, вся недетерминированность состоит в том, что автор ожидает от кода совсем не того, для чего код предназначен. 

Ну и второй момент - это читаемость кода.  Считаю операцию "вопросик" крайне вредной и сложной в понимании. Замена "вопросика" условным оператором дает исполнимый код с абсолютно той же эффективностью. При этом исходный текст становится заметно объемнее, но и настолько же понятнее. Что, я считаю, большим плюсом. 

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

[Maxim Kuznetsov]

а тут царство ёлко-ориентированного программирования :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }

[Georgiy Merts]

Maxim Kuznetsov:

а тут царство ёлко-ориентированного программирования :-)

Если в условиях будут короткие выражения - то вполне разумно. Хотя, можно и разнести по функциям. 

Ну и в обратных скобках в таких вот случаях я всегда ставлю комментарием заголовок открывающей скобки, чтобы было понятно.

[Andrey Khatimlianskii]

fxsaber:

При одном стиле написания знаешь точно, компилятор сделает, как надо. При другом - только уповать, что компилятор умнее.

Не будет ни какой разницы в выполнении этого:

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  

и этого:

return( a() || b() );

Я — за легко читаемый и отлаживаемый код.

[Vitaly Muzichenko]

Andrey Khatimlianskii:

Не будет ни какой разницы в выполнении этого:

и этого:

Я — за легко читаемый и отлаживаемый код.

Мне эта конструкция совершенно не нравится в плане читаемости и нагромождённости 

if ( a() ) return(true);
if ( b() ) return(true);
return(false);