Entropi kavramı, kaynak kodunu faydalı bir şekilde analiz etmek için kullanılabilir mi?

Statik kaynak kodu analizi için göreli bir karmaşıklık değeri üretmek için kurallar içeren bir bağlam tanımlayabileceğimi düşünüyorum. Fiziksel anlamda böyle olmadığını biliyorum çünkü sos kodunda "Enerji" yok ama bahse girerim, en iyi akademik çalışmalarda, bir paralel çizmek için çabalar olmuştur. Herkes bu konuda herhangi bir bilgi var mı ve eğer öyleyse, hangi amaçla yararlı sonuçlar üretti?

Kod karmaşıklığı için zaten bir dizi önlem var:

• Cyclomatic karmaşıklık
• Sınıf uzunluğu
• Yöntem uzunluğu
• Alan sayısı
• Yöntem parametresi sayısı
• N-yolu karmaşıklığı
• Fan girişi ve fan çıkışı
• Veri akışı analizi (DU / DD zincirleri)

Bunları yoğunluk, bakım çabası ve kolay anlaşılırlığı saptamak için ilişkilendirilmiştir. Analizinizden ne öğrenmeye çalıştığınıza bağlı olarak bazıları diğerlerinden daha anlamlıdır. Fizik bilimlerindeki entropi kavramına aşina değilim, ama zaman içinde adlandırdıklarım gibi ölçümleri ve metrikleri izlemenin ve onları zamanla kusurlarla ilişkilendirmenin, aradığınıza benzer olup olmadığını merak ediyorum.

Ayrıca ilginizi çekebilir Ivar Jacobson yazılım entropi ve yazılım çürüklüğü tanımı . Bu konuların genel fikri, zaman içinde, kod ve yürütme ortamı değiştikçe yazılım sisteminin bozulmaya başlamasıdır. Yeniden düzenleme, entropiyi veya çürümeyi en aza indirmenin bir yöntemi olarak görülür ve en azından deneyimlerime göre, yukarıda bahsettiğim metrikler ve ölçümler, bir sistemde veya alt sistemde yeniden düzenlemenin gerekli olabileceğinin göstergeleri olacaktır.

Sanırım termodinamik entropi ve "karmaşıklık" arasında bir paralel çizmeye çalışıyorsunuz. Mesele şu ki, entropi karmaşıklığın değil düzensizliğin bir ölçüsüdür . İkisinin eşdeğer ve değiştirilebilir olduğuna inanmıyorum.

Termodinamik entropiye en yakın analog, rastgele bir değişkendeki bozukluk miktarını ölçen Shannon entropisidir . Bu kavram öncelikle bir mesajdaki "bilgi" miktarı ile ilgilidir.

Bu bağlamda, bir kod parçası çok fazla bilgiye (yüksek entropi) sahip olabilir, ancak çok düşük karmaşıklığa sahip olabilir. Çok uzun bir rastgele karakter dizisi basan bir program düşünün. Çok fazla bilgiye sahiptir, ancak karmaşıklığı düşüktür.

Entropi bir "düzensizlik ölçüsüdür" ya da tahmin edilemezliktir. Bilgideki daha geniş bir benzersiz desen aralığı (yani kabaca "daha fazla anlam") daha yüksek bir entropi derecesini gösterir.

Bilgisayar kaynak koduna uygulanan bu ilkenin faydalı olabileceğini düşünüyorum. Bununla birlikte, entropinin hesaplanacağı kaynak kodu için olasılıksal bir model tasarlamak gerekli olacaktır . (Kolayca akla gelen bir veri yapısı, farklı kenar türlerine sahip bir grafiktir: çağrı, sınıf mirası vb.)

Model tasarlandıktan ve daha sonra bir yazılım uygulamasının kaynak koduyla (yani düğümler / kenarlar için frekanslar) doldurulduktan sonra entropi hesaplanabilir.

Bu konuda herhangi bir araştırma bilmiyorum, ama sezgim düşük entropi derecesi kaynak kodu uygulama (yani KURU ) boyunca ortak kalıpları yeniden anlamına gelir . Tersine, yüksek derecede bir entropi, kaynak kodun karmaşıklığı yüksek olduğu ve iyi bir şekilde faktörleştirilmediği anlamına gelir.

Entropiyi düşünmenin bir yolu "elde edilecek ortalama bilgi" dir, bu yüzden modelleme bilgilerine geri dönmenin daha iyi olduğunu düşünüyorum. Matematiksel olarak modelleme bilgisine iki temel yaklaşım biliyorum. (Vikipedi referansları verdiğim için beni affet ama IMHO kötü değiller.)

• Sembol kümelerine, bunlardaki olasılık dağılımlarına, sembol kümeleri arasında bilgi aktarabilecek kodlara ve bu kodların uzunluklarına bakan Shannon Bilgileri . Kod verimliliği, gürültü, hata tespiti ve fazlalık yoluyla düzeltme vb. Genel kavramları Shannon bilgi teorisi açısından göz önünde bulundurulmuştur. Bilgileri ifade etmenin bir yolu, bir sembolü temsil edebilecek en kısa ikili kodun uzunluğu olduğunu söylemektir. Bu, bir gözlemci tarafından bir sembol veya olaya atanan sayısal bir değer olan olasılığı temel alır.

• Solomonoff (veya Kolmogorov ) bilgileri. İşte başka bir açıklama. Bu formülasyonda, bir sembol veya olayın bilgi içeriği, onu hesaplayabilen en kısa programın uzunluğu ile temsil edilir. Burada yine, olasılık atayan bir gözlemciye değil, programı çalıştırabilen evrensel bir makineye görecelidir. Her evrensel makine evrensel bir Turing makinesi tarafından simüle edilebildiğinden, bir anlamda sembol veya olayın bilgi içeriğinin göreceli değil, mutlak olduğu anlamına gelir.

Bunun ne demek istediğimi bir kitap yazdığım günlük terimlerle söyleme özgürlüğünü alabilirsem, bir programın karmaşıklığı, işlevsel özellik ve dil gibi şeyler sabit tutulduğunda, uzunluğudur. yorum ve isim uzunlukları için ödenekler. Ancak bununla ilgili bir sorun var - özlülüğün anlaşılmazlığa eşit olduğu "APL tarpit".

Programın işlevsel spesifikasyonunun sadece gerçek değil, aynı zamanda verimli bir şekilde kodlanmış, yani gereksinimler hakkındaki fikrini değiştirecek kadar küçük bir fazlalık ile zihinsel bir modelden oluştuğunu (AI çalışırken yaptığım gibi) çok daha iyi. dahili olarak tutarsız hale getirme tehlikesi olmadan yapılabilir - yani bir "böcek". Daha sonra programlama süreci, zihinsel modeli girdi olarak alan bir bilgi kanalıdır ve çıktısı, çalışma kaynak kodudur. Daha sonra zihinsel modelde bir değişiklik yapıldığında, bu deltanın programlama süreci boyunca beslenmesi ve kaynak kodunda ilgili bir deltaya dönüştürülmesi gerekir. Bu delta kolayca ölçülür. Bu deltayı uygulamadan önce ve uyguladıktan sonra (tamamen, tüm hatalar çalışmış olarak) kaynağı ayırın, ve eklenen, silinen ve değiştirilen kod bloklarının sayısını sayın. Kaynak kod dili ne kadar küçük olursa, zihinsel modelin temsil edildiği dili o kadar iyi temsil eder (isimler, fiiller ve yapı açısından). Bu önlemin olası fonksiyonel değişikliklerin alanı üzerinden bir şekilde ortalaması alınırsa, bu kaynak dilin entropisi kavramıdır ve daha azı daha iyidir. Bunun için bir terim var -Etki Alanına Özel Dil (DSL)

Kaynaklar zayıf / kişisel ise özür dilerim, ama bu genel sorunun çok önemli olduğunu düşünüyorum.

Jon Jagger ve Olve Maudal , 2011 Accu konferans oturumu Kod Entropisi ve Yazılım Fiziği'nde görülebileceği gibi, Kod Entropi konusunda biraz farklı bir görüşe sahiptir .

Kodun gelecekteki geliştiricilerin / sürdürücülerin bu kodu değiştirip değiştirmeyeceği ile ilgili olmanın istikrarından bahsediyorlar .

Bunu göstermek için, birkaç kod parçacığıyla bir anket yaptılar ve sonuçlar oldukça ilginçti.

• Tek gerçek parantez stiline karşı güçlü bir önyargı var gibi görünüyordu .
• Ama eğer tek bir ifadeyi kucaklamak için güçlü bir önyargı .
• Geçici değişkenlerin kullanılmasına karşı güçlü bir önyargı vardı.
• Operatör önceliğini belirginleştirmek için parantez eklemek için güçlü bir önyargı vardı.

artı 16 kişi daha.

Genel eğilim, kodun daha kolay anlaşılmasını ve yanlış anlaşılmasını zorlaştırmak gibi görünüyordu.

Ayrıca yıllar boyunca büyük bir kod tabanında yapılan bazı değişikliklere de bakarlar.

Kendi başlarına slaytlar oturumun transkripti olmamasına rağmen, orada hala bazı ilginç noktalar var.

Ben altında incelenen profesörü programlarının karmaşıklığı bir ölçüsü olarak entropi kullanılan (bizim ders kitabı eski bir baskısı oldu bu bir , onun pub bazılarıdır burada ). FAU'da bunun büyük önlemlerden biri olduğu bir dizi tez vardı, ancak okulun web sitesi son baktığımdan beri değişti ve öğrenci tezinin / tezlerinin nerede bulunduğunu bulamıyorum.

Böyle bir tez Bilgi Kuramı ve Yazılım Ölçümüdür .

Entropinin olduğu gibi "mathy" olan bir tanım istiyorsanız, karmaşıklığı bir şeyin yapılabileceği minimum kod miktarıyla ölçen Kolmogorov karmaşıklığına bakmak isteyebilirsiniz. Ancak, bu kod karmaşıklığı değil, ancak kodla ne yapmaya çalıştığınıza. Ancak konuyla ilgili olduğunu düşünebilirsiniz, çünkü teorik olarak belirli bir kod parçasını minimal kodla karşılaştırabilirsiniz. Bununla birlikte, bu şu anda gerçek dünya kodunun karmaşıklığını ölçmek için yararlı bir teknik değildir.

Bunun uygun olmadığını düşünüyorum, iyi yazılmış bir kod tabanının daha yüksek entropi (bozukluk) olması gerektiğini iddia edebiliriz. Kod pasajının tekrar tekrar tekrarlandığı bir kod tabanını düşünün, yinelenen kısım (daha düşük entropi / dosya boyutu) nedeniyle yüksek sıkıştırma oranı ile sıkıştırılabilir, ancak kodu ayrı bir işleve taşırsanız sıkıştırma oranı daha düşük olacaktır (daha yüksek entropi / dosya boyutu).

Yani biri düşünebilir, o zaman kod kalitesini ölçmek için sıkıştırma oranı katsayısı kullanarak Entropy / CodeLines gibi bir şey hesaplayabilirsiniz, ancak bu toplam rastgele giriş belli ki dünyadaki en iyi kod gibi görünecek sorun var.

Gerçekten de sıkıştırma oranı kod entropisini ölçmek için iyi bir ölçüm cihazıdır, ancak her ikisi de kod kalitesi için iyi ölçüm cihazları değildir.

Entropi terimi sadece termodinamik ve bilgi teorisinde değil, aynı zamanda veri sıkıştırma gerçek dünyasında da görülür. Bu bağlamda, kompresörün gördüğü entropi ürettiği bit sayısına eşittir. ("Kompresörün gördüğü entropi" dedim , çünkü entropi olarak kabul edilen şey, kompresörün giriş verilerini tanımlamak için kullandığı modele bağlıdır. Farklı kompresörlerin farklı boyutlarda dosyalar üretmesinin nedeni budur: biri diğerine sömürülebilir yapıdır.)

Bu, prensip olarak, kaynak kodu karmaşıklığına güzelce uygulanabilir: "Sadece" sadece tamamen standart uyumlu kaynak kodunda çalışan ve onu bir derleyici gibi ayrıştıran bir kompresör yazarak karşılık gelen sözdizimi ağacını üretir. Daha sonra bu sözdizimi ağacını yürütebilir ve her düğümde her noktada hangi düğümlerin mümkün olabileceğine karar verebilir ve bu düğümü bu bilgi ile kodlayabilir.

Örneğin, dil, varolan bir tanımlayıcıya veya parantez içine alınmış bir şeye veya belirli bir noktadaki bir ürüne izin veriyorsa, kompresör, tür bilgilerini dikkate alarak olası mevcut tanımlayıcıları sayar (bu tür 3 tanımlayıcınız olduğunu varsayalım) ) ekleyin ve 5 olasılık vererek iki olası alt ifade için 2 ekleyin. Böylece düğüm lb 5 = 2.32bitlerle kodlanır . İki olası alt ifade durumunda, içeriklerini kodlamak için daha fazla bit gerekli olacaktır.

Bu gerçekten de kodun karmaşıklığı için olduğu gibi çok doğru bir ölçüm sağlayacaktır. Ancak, bu önlem hala işe yaramaz! Tüm kod karmaşıklığı ölçümlerinin işe yaramaz olmasının aynı nedeni işe yaramaz: Başarısız olan, ölçülen kod karmaşıklığı (ne olursa olsun) ve kodun çözdüğü sorunun karmaşıklığı arasındaki bağlantıyı çizmez. Sen edebilirsiniz hep LOC sayımları ile işvereniniz etkilemek için programlama problemlerine gülünç karmaşık çözümler bulmak, ancak hiçbir kod karmaşıklık ölçüsü görev çaba bir kısmını ile çözülmüş olabilirdi söyleyecektir.

Kod tam olarak π sayısı kadar entropiye sahiptir.

Kod bakımı ve değişikliği entropiye neden olabilir (çünkü olası bir devlet değişikliği söz konusudur).

Ancak kod sadece büyük bir sayıdır. İkili gösterim ile.