Siklomatik Karmaşıklık Aralıkları [kapalı]

Kapalı . Bu soru görüşe dayalı . Şu anda cevapları kabul etmiyor.

Bu soruyu geliştirmek ister misiniz? Soruyu güncelleyin, böylece bu yayını düzenleyerek gerçekleri ve alıntıları yanıtlayabileceksiniz .

5 yıl önce kapandı .

Döngüsel karmaşıklığın kategorileri nelerdir? Örneğin:

1-5: bakımı kolay
6-10: zor
11-15: çok zor
20+: imkansız yaklaşmak

Şimdilik, 10'un limit olduğu varsayımıyla gittim. Ve bunun ötesinde bir şey kötü. Bir çözümü analiz ediyorum ve kodun kalitesini belirlemeye çalışıyorum. Kesinlikle döngüsel karmaşıklık tek ölçüm değil, ancak yardımcı olabilir. 200 + 'nın döngüsel karmaşıklığına sahip yöntemler var. Bunun korkunç olduğunu biliyorum, ancak yukarıdaki örneğindeki gibi alt aralıklar hakkında bilgi sahibi olmayı merak ediyorum.

Bulduğum bu :

Carnegie Mellon'dan yukarıda bahsedilen referans değerleri, siklomatik karmaşıklık değerleri için dört kaba aralık tanımlar:

1 ile 10 arasındaki yöntemler basit ve anlaşılması kolay kabul edilir

10 ile 20 arasındaki değerler, hala anlaşılabilir olan daha karmaşık kodları gösterir; Ancak, kodun alabileceği daha fazla sayıda dal olması nedeniyle testler zorlaşır.

20 ve üzeri değerler, çok sayıda potansiyel çalıştırma yoluna sahip kod için tipiktir ve yalnızca tam olarak kavranabilir ve büyük zorluk ve eforla test edilebilir

daha da yükseğe çıkan yöntemler, örneğin> 50, kesinlikle elde edilemez

Bir çözüm için kod metriklerini çalıştırırken, sonuçlar 25'in altındaki herhangi bir şey için yeşil renk gösterir. Buna katılmıyorum, ancak başka girdiler almayı umuyordum.

Döngüsel karmaşıklık için genel kabul görmüş bir liste var mı?

design programming-practices metrics

— Bob Horn
kaynak

Yazılım mühendisliğinde lider olarak kabul edilen bir kuruluş olan Software Engineering Institute'ten veri bulmuşsunuz. Sorunuzun ne olduğunu anlamıyorum - konjonktürel karmaşıklık için bir dizi listesi buldun. Başka ne arıyorsun

— Thomas Owens

Çeşitli aralıklar gördüm; bu sadece bir örnekti. Olsaydı Ve, 25 yaş altındaki her şey için MS gösterileri "yeşil" merak ediyorum bir kabul edilen aralık listesi. Belki o zaman buldum.

— Bob Horn

@ThomasOwens ile aynı fikirdeyim, ama bu soruyu sorduğuna sevindim. Bunu hem soru hem de cevap olarak değiştirdim.

— Evorlor

Steve McConnell's Code Complete'in 2. baskısında, 0'dan 5'e kadar olan bir siklomatik karmaşıklığın normalde iyi olduğunu, ancak karmaşıklığın 6 ila 10 aralığında olmaya başladığının farkında olmalısınız. Ayrıca, karmaşıklığı 10 olan her şeyin kodunuzu yeniden düzenlemeyi şiddetle düşünmeniz gerektiğini açıklar.

— GibboK

Yanıtlar:

Sanırım bunun programlama personelinizin yeteneklerine bağlı olduğunu ve hiçbir şekilde yönetici olarak hassasiyetlerinize bağlı olmadığını.

Bazı programcılar TDD'nin savunucularıdır ve önce birim testi yazmadan herhangi bir kod yazmazlar. Diğer programcılar, tek bir ünite testi yazmadan kusursuz ve hatasız programlar oluşturabilirler. Her grubun tolere edebileceği siklomatik karmaşıklık seviyesi neredeyse kesinlikle büyük ölçüde değişecektir.

Bu öznel bir ölçümdür; Code Metrics çözümünüzün ayarını değerlendirin ve size mantıklı sonuçlar veren rahat hissettiğiniz tatlı bir noktaya ayarlayın.

— Robert Harvey
kaynak

Kabul edildi, ayrıca karmaşıklığın sebebinin ne olduğuna bağlı. Durum makinesinin bir parçası veya benzeri bir şey olarak, diğer işlevleri çağıran büyük bir geçiş ifadesi, muhtemelen anlaşılması neredeyse önemsiz olmasına rağmen, çok yüksek bir karmaşıklığa sahip olabilir.

— whatsisname,

Büyük anahtar ifadeler tipik olarak polimorfizm gibi OOP ilkelerinin bulunmadığının bir göstergesi değil midir? Devlet makineleri, OOP veya tasarım modelleriyle zarif şekillerde uygulanabilir. Yok hayır?

— Bob Horn,

'Eleganetin' yararlı olduğu bazı problemlerde, diğerleri için ise işleri daha kafa karıştırıcı hale getirir. Gümüş mermi yok.

— whatsisname

-1 "Diğer programcılar tek bir birim testi yazmadan mükemmel derecede iyi, hatasız programlar oluşturabilirler." Test etmediyseniz, hatasız olduğunu bilemezsiniz.

— Sebastien

@Sebastien: Birim testlerinin yokluğu test edilmediği anlamına gelmez. Ve evet, eğer yeterince iyiyseniz, hiçbir test veya basit bir duman testi olmadan hatasız kod yazmak kesinlikle mümkündür. Kuşkusuz, bu insanlar nadir bir cins.

— Robert Harvey

Önceden tanımlanmış kategoriler yoktur ve birkaç nedenden dolayı kategorizasyon mümkün değildir:

Bazı üstlenmeden teknikleri sadece (değil başka bir noktadan itibaren karmaşıklığı taşımak için kod çerçevesi veya iyi test edilmiş dış kütüphaneye, ama bir yerden kod temeli diğerine). Döngüsel karmaşıklığın azaltılmasına yardımcı olur ve patronunuzu (veya sürekli artan grafiklerle sunumları seven herhangi bir kişiyi) zamanınızı harika bir şeyler yapmak için harcadığınıza ikna etmeye yardım eder , ancak kod daha önce olduğu kadar kötü kalır.
Tersine, bazen, bazı tasarım ve programlama modellerini uygulayarak bir projeyi yeniden yapılandırdığınızda, döngüsel karmaşıklık daha da kötüleşebilir, yeniden yapılandırılmış kodun açık olması beklenirken: geliştiriciler programlama kalıplarını bilir (en azından bunları bilmeleri beklenir), bu yüzden onlar için kodu basitleştirir, ancak döngüsel karmaşıklık bunu hesaba katmaz.
Diğer bazı yeniden düzenleme yapmayan teknikler, siklomatik karmaşıklığı hiç etkilemezken, geliştiriciler için bir kodun karmaşıklığını ciddi şekilde azaltır. Örnekler: alakalı yorumlar veya belgeler eklemek. Sözdizimsel şekeri kullanarak kodu "modernleştirmek".
Basitçe, siklomatik karmaşıklığın alakasız olduğu durumlar vardır. Yorumunda whatsisname tarafından verilen örneği beğendim : bazı büyük switchifadeler son derece net olabilir ve bunları daha fazla OOPy biçiminde yeniden yazmak çok yararlı olmaz (ve yeni başlayanlar tarafından kodun anlaşılmasını zorlaştırır). Aynı zamanda, bu ifadeler felaket, döngüsel karmaşıklık açısından.
Robert Harvey'in dediği gibi , takımın kendisine bağlı.

Uygulamada, iyi bir döngüsel karmaşıklığa sahip, ancak korkunç olan kaynak kodunu gördüm. Aynı zamanda, yüksek döngüsel karmaşıklığı olan bir kod gördüm, ancak bunu anlamak için çok fazla acı çekmedim.

Sadece, verilen bir kod parçasının ne kadar iyi ya da kötü olduğunu ya da bakımı ne kadar kolay olduğunu belirten hiçbir araç olmadığı ve olamayacağıdır . Belirli bir resmin bir şaheser olduğunu ve başka bir şeyin atılması gerektiğini söyleyen bir uygulamayı programlayamazsınız çünkü sanatsal bir değeri yoktur.

Tasarıma göre kırılmış metrikler (LOC veya dosya başına yorum sayısı gibi) ve bazı ham ipuçları verebilecek metrikler (böcek sayısı veya döngüsel karmaşıklık gibi) vardır. Her durumda, bunlar sadece birer püf noktasıdır ve dikkatli kullanılmalıdır.

— Arseni Mourzenko
kaynak

+1 Her şeyin söylediğine katılıyorum. Döngüsel karmaşıklık veya LOC sadece statik kod analizi ile size verilen metriklerdir. Statik analizörler harika araçlardır, ancak sağduyulu değillerdir. Bu metriklerin, tercihen deneyimli bir programlayıcıya ait olan bir insan beyni tarafından işlenmesi gerekir. Ancak o zaman, belirli bir yazılımın gereksiz yere karmaşık olup olmadığını anlayabilirsiniz.