OOP'a ilginç bir bakış - sayfa 9

Yeni yorum
 
Igor Makanu :

% 99 kesinlikle, işlemci düzeyinde bu kodların döngüye kadar aynı hızda yürütüleceğini düşünüyorum - işlemcide hala optimizasyon, paralelleştirme ve xs mikro komut düzeyinde başka ne çalışıyor

"Derleyici onu en iyi şekilde tarayacak" temelinde herhangi bir kalitede kod yazıldığında burada olumsuz bir etki olmuyor mu?


Tek bir yazım stiliyle, derleyicinin doğru olanı yapacağından emin olabilirsiniz. Diğeriyle - sadece derleyicinin daha akıllı olduğunu umalım.

Platformlar arası, farklı derleyiciler vb. hesaba katarak, kodda ne yaptığınızın farkındalığını seçiyorum.
 
fxsaber :

"Derleyici onu en iyi şekilde tarayacak" temelinde herhangi bir kalitede kod yazıldığında burada olumsuz bir etki olmuyor mu?

örneklerim - pek kaliteli değil, bunlar tipik yapılar - uzun zamandır github'daki kaynakları karşılaştırıyorum, tst1 nedir, tst2 örneği nedir, ikisi de programcılar tarafından aktif olarak kullanılıyor

bu nedenle, derleyici geliştiricilerinin uzun süredir tipik kod yapılarını incelediklerini ve bunun derleyiciler için bir sorun olmadığını düşünüyorum.


olumsuz etki - burada, @TheXpert'in yukarıda yazdığı gibi, kodun tasarımı için şirketlerin gereksinimleri vardır, ancak gereksinimler genellikle aynıdır - kod, sadece sahip olanlar da dahil olmak üzere, ekip üyelerinin geri kalanı tarafından anlaşılabilir olmalıdır. geldi ....


fxsaber :

Tek bir yazım stiliyle, derleyicinin doğru olanı yapacağından emin olabilirsiniz. Diğeriyle - sadece derleyicinin daha akıllı olduğunu umalım.

evet, şimdi daha akıllı olan derleyici değil, işlemcinin kendisi, IMHO, hala yüksek performanslı koddan bahsediyorsak, ana performans maliyetleri işlev çağrılarında değil, bellek okumada (bellek erişimi) - eğer verileri / değişken depolamayı küçük hesaplanmış değerlerle değiştirebilirsiniz, (işlemci mikro talimatlarının optimizasyonu düzeyinde) küçük bir kazanç elde edersiniz

... ve geri kalanı, IMHO, kötü olandan)))


Not: Derleyici düzeyinde de kod optimizasyonu var, az okuyorum - her şey varsayım düzeyinde, periyodik olarak PC donanımı hakkında okuyorum, uzun zamandır okuyorum, fikrimi yazdım




fxsaber :

Platformlar arası, farklı derleyiciler vb. hesaba katarak, kodda ne yaptığınızın farkındalığını seçiyorum.

o zaman seçenek yok - kısacası: "Ben bir sanatçıyım - öyle görüyorum")), umarım canımı yakmamışımdır

 

5 yıl sonra kodun kodlayıcı tarafından anlaşılabilir olması, anlaşılmazsa kötü kod olması gerektiğine dair bir kuralım var.

Ve eğer başkalarına açıksa, çok iyi.

 
Valeriy Yastremskiy :

5 yıl sonra kodun kodlayıcı tarafından anlaşılabilir olması, anlaşılmazsa kötü kod olması gerektiğine dair bir kuralım var.

Ve eğer başkalarına açıksa, çok iyi.

Burada (ve burada ) çok iyi bir koddur. Ama onu anlamıyorum. Zeka uzun zaman önce büyümeyi durdurdu.

 
fxsaber :

Burada (ve burada ) çok iyi bir koddur. Ama onu anlamıyorum. Zeka uzun zaman önce büyümeyi durdurdu.

konular karmaşıktır. herkes onları anlamayacak,) kodu beğenmedim.

 

Ah, ne konu... Ve bensiz... Bozukluk... Sesimizi çıkarmalıyız.

Başlıktaki makale ile ilgili olarak - doğru öncül (kod mümkün olduğu kadar belirleyici olmalıdır) tamamen aptalca bir şekilde kullanılmış, örnek olarak toplama işleminin ve biriktirme işleminin bir karşılaştırması verilmiştir. Ve toplama işleminin deterministik olduğu, her zaman bir sonuç döndürdüğü, ancak sonuç her zaman farklı olduğu için birikimin vermediği sonucuna varılmıştır.

Ama izin verin... bunlar farklı işlemler ve her iki durumda da sonuçlar kesinlikle doğru ve tam olarak sırasıyla toplama ve birikimden beklenenler!

Bunun rasgele bileşenli bir işlem olduğunu düşünürsek, rasgele sayı üreteci örneği bile "belirleyici olmayan" olarak adlandırılamaz.

Bana öyle geliyor ki, tüm determinizm, yazarın koddan, kodun amaçladığından tamamen farklı bir şey beklediği gerçeğinde yatmaktadır.


İkinci nokta, kodun okunabilirliğidir. "Soru" işlemini son derece zararlı ve anlaşılması zor buluyorum. "Soru sorusunu" koşullu bir operatörle değiştirmek, tam olarak aynı verimlilikte yürütülebilir kod verir. Aynı zamanda, kaynak metin gözle görülür şekilde daha hacimli ve aynı zamanda daha net hale gelir. Ki bence bu büyük bir artı.

Her zaman sayısız mantıksal ifadeyi , ara sonuçlarla bir dizi ayrı işleme bölmeye çalışırım. Böyle bir kod daha az verimli çalıştırılabilir kod üretse bile, daha iyi anlamanın kazancı bence çok daha önemlidir.

 

ve işte ağaç yönelimli programlama alanı :-)

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

ve işte ağaç yönelimli programlama alanı :-)

Koşullarda kısa ifadeler varsa, oldukça makul. Bununla birlikte, işlevlere ayrılabilir.

Pekala, böyle durumlarda arka parantez içinde, her zaman açıklığa kavuşturmak için açılış parantezinin başlığını bir yorum olarak koyarım.

 
fxsaber :

Tek bir yazım stiliyle, derleyicinin doğru olanı yapacağından emin olabilirsiniz. Diğeriyle - sadece derleyicinin daha akıllı olmasını umalım.

Bunu yapmanın hiçbir farkı olmayacak:

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

ve bu:

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

ben kolay için   okunabilir ve hata ayıklanabilir kod.

 
Andrey Khatimlianskii :

Bunu yapmanın hiçbir farkı olmayacak:

ve bu:

ben kolay için   okunabilir ve hata ayıklanabilir kod.

Okunabilirlik ve dağınıklık açısından bu tasarımı hiç sevmiyorum.

 if ( a() ) return ( true );
if ( b() ) return ( true );
return ( false );  
12345678910111213
Yeni yorum