Hangi noktada, kısalık artık bir erdem değildir?

Yakın zamanda yapılan bir hata düzeltmesi, diğer takım üyeleri tarafından yazılan kodu gözden geçirmemi istedi, bu da (C #):

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

Şimdi, tüm bu yayınlar için iyi bir neden var, bunu takip etmek hala çok zor görünüyor. Hesaplamada küçük bir hata vardı ve sorunu çözmek için açmam gerekiyordu.

Bu kişinin kodlama stilini kod incelemesinden biliyorum, yaklaşımı ise daha kısa olması neredeyse her zaman daha iyi. Ve elbette orada değer var: hepimiz gereksiz yere karmaşık birkaç iyi yerleştirilmiş operatörle bağdaştırılabilecek koşullu mantık zincirleri gördük. Ancak, takip eden operatör zincirleri tek bir ifadeye tıkılıp tıkandığında benden daha usta.

Bu, elbette, sonuçta bir stil meselesidir. Ancak, kodun kısalıklığı için çabalamanın yararlı olmayı kestiği ve anlama için bir engel teşkil ettiği noktasını tanımak için herhangi bir şey yazıldı mı ya da araştırıldı mı?

_{Vuruşların nedeni Varlık Çerçevesi. Db'nin bunları null tipinde saklaması gerekiyor. Ondalık? C # 'da Ondalık değerine eşdeğer değildir ve kullanılması gerekir.}

Mevcut araştırma hakkındaki sorunuzu cevaplamak için

Ancak, kodun kısalıklığı için çabalamanın yararlı olmayı kestiği ve anlama için bir engel teşkil ettiği noktasını tanımak için herhangi bir şey yazıldı mı ya da araştırıldı mı?

Evet, bu alanda iş var.

Bu şeyleri anlamak için, bir metriği hesaplamanın bir yolunu bulmanız gerekir, böylece karşılaştırmalar nicel olarak yapılabilir (diğer cevapların yaptığı gibi sadece zekâ ve sezgiye dayanan karşılaştırmayı yapmak yerine). Bakılan potansiyel bir ölçüm

Döngüsel Karmaşıklık ÷ Kodun Kaynak Hatları ( SLOC )

Kod örneğinizde, bu oran çok yüksektir, çünkü her şey bir satırda sıkıştırılmıştır.

SATC, en etkili değerlendirmenin boyut ve [Cyclomatic] karmaşıklığının bir kombinasyonu olduğunu buldu. Hem karmaşıklığı hem de büyüklüğü yüksek olan modüller en düşük güvenilirliğe sahip olma eğilimindedir. Düşük boyutu ve yüksek karmaşıklığı olan modüller de güvenilirlik riski taşır çünkü çok kısa bir kod olma eğilimindedir, bu da değiştirilmesi ya da değiştirilmesi zordur.

bağlantı

İlgileniyorsanız işte birkaç referans:

McCabe, T. ve A. Watson (1994), Yazılım Karmaşıklığı (CrossTalk: Savunma Yazılım Mühendisliği Dergisi).

Watson, AH ve McCabe, TJ (1996). Yapısal Test: Siklomatik Karmaşıklık Metriğini Kullanan Bir Test Metodolojisi (NIST Special Publication 500-235). McCabe Software web sitesinden 14 Mayıs 2011 tarihinde alındı: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg, L., Hammer, T., Shaw, J. (1998). Yazılım Ölçümleri ve Güvenilirliği (IEEE Uluslararası Yazılım Güvenilirliği Mühendisliği Sempozyumu Bildirileri). 14 Mayıs 2011 tarihinde, Penn State University web sitesinden alındı: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

Benim fikrim ve çözüm

Şahsen, ben asla okunaksızlığa değer vermedim , sadece okunabilirliği. Bazen kısalık okunabilirliğe yardımcı olur, bazen yapmaz. Daha önemlisi, Salt Okunur Kod (WOC) yerine Gerçekten Açık Kod'u (ROC) yazıyor olmanızdır .

Sadece eğlence için, işte nasıl yazarım ve ekibimin üyelerinden yazmalarını isteyin:

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

Ayrıca, çalışma değişkenlerinin tanıtılmasının tamsayı aritmetiği yerine sabit nokta aritmetiğini tetiklemenin mutlu yan etkisi olduğuna dikkat edin, bu nedenle tüm bu atmaların gerekliliği decimalortadan kalkar.

Kısalık önemli şeyler etrafında dağınıklığı azaltır zaman iyidir, ama olduğunda veciz , kolayca ardından ilgili veri dağınıklığı kendisi olur ve bir sorun var, takip etmek çok yoğun çok fazla alakalı verileri ambalaj.

Bu özel durumda, decimaltekrar tekrar yayınlanacak olan yayınlar ; genel olarak şöyle bir şeyi yeniden yazmak daha iyi olurdu:

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

Aniden mantığı içeren satır çok daha kısadır ve yatay bir satıra sığar, böylece kaydırma yapmak zorunda kalmadan her şeyi görebilirsiniz ve anlam çok daha belirgindir.

Konuyla ilgili herhangi bir araştırmaya değinmemekle birlikte, kodunuzdaki tüm yayınların Kendinizi Tekrar Etme ilkesini ihlal ettiğini öneririm. Ne kod yapmaya çalışıyor gibi görünüyor dönüştürmek olduğunu costInve costOutyazın Decimalve çekler geçerse o zaman bu dönüştürülen değerler üzerinde bu tür dönüşümlerin sonuçlarına bazı sağlık kontrolleri ve performans ek işlemleri gerçekleştirmek. Gerçekte, kodunuz akılsızlık denetimlerinden birini dönüştürülmemiş bir değer üzerinden gerçekleştirir, costOut öğesinin sıfırdan büyük, ancak boyutun yarısından az Decimaltemsil edebileceği en küçük sıfır değerinden daha düşük bir değere sahip olabileceği olasılığını yükseltir . Kod Decimal, dönüştürülen değerleri tutmak için tür değişkenleri tanımladıysa ve sonra bunlara göre hareket ettiğinde çok daha net olurdu .

Oranı daha fazla ilgi olacağını merak görünüyor Decimaltemsilleri costInve costOutfiili değerlerinin oranı daha costInve costOutkodu da bazı başka amaçla ondalık temsillerini kullanacak sürece,. Kod, bu gösterimleri daha fazla kullanacaksa, kod boyunca devam eden bir münferit dizisine sahip olmak yerine, bu gösterimleri tutmak için değişkenler oluşturmak için daha fazla argüman olacaktır.

Bu koda baktım ve "bir maliyet nasıl 0 (veya daha az) olabilir?" Diye soruyorum. Bu hangi özel durumu ifade eder? Kod olmalıdır

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

Buradaki isimleri tahmin ediyorum: değiştir BothCostsAreValidProductsve NO_PROFITuygun şekilde.

Kısalık, unutursak bir erdem olmayı , kendi başına bir erdemden ziyade bir sona erme anlamına gelir . Kısalıklardan hoşlanıyoruz, çünkü sadelikle ilişkilendiriliyor, sadeliği de seviyoruz çünkü daha basit kodların anlaşılması daha kolay ve değiştirilmesi ve daha az hata içerdiği için daha kolay. Sonunda kodun şu hedefe ulaşmasını istiyoruz:

1. İş gereksinimlerini en az miktarda işle yerine getirme

2. Böcek kaçının

3. Gelecekte 1 ve 2’yi yerine getirmeye devam eden değişiklikler yapmamıza izin verin

Bunlar hedefler. Herhangi bir tasarım ilkesi veya yöntemi (KISS, YAGNI, TDD, SOLID, provalar, tip sistemleri, dinamik metaprogramlama vb.), Yalnızca bu hedeflere ulaşmamıza yardımcı oldukları ölçüde erdemlidir.

Söz konusu hattın son hedefin görüşünü kaçırdığı görülüyor. Kısa olmasına rağmen basit değil. Aslında aynı döküm işlemini birkaç kez tekrarlayarak gereksiz fazlalık içeriyor. Kodu tekrarlamak, karmaşıklığı ve hata olasılığını artırır. Dökümün gerçek hesaplamayla karıştırılması da kodun takip edilmesini zorlaştırır.

Hattın üç endişesi var: Korumalar (özel muhafaza 0), tip döküm ve hesaplama. Her endişe, tecrit edildiğinde oldukça basittir, ancak hepsi aynı ifadede birbirine geçtiği için takip etmesi zorlaşır.

Neden CostOutilk kullanıldığında hile kullanılmadığı açık değildir CostIn. İyi bir sebep olabilir, ancak niyet açık değildir (en azından bağlamsız), bu nedenle bir bakıcı bu kodu değiştirmekten sakıncalıdır, çünkü bazı gizli varsayımlar olabilir. Ve bu da sürdürülebilirliğin bir doğasıdır.

Yana CostIn0'a karşılaştırarak önce döküm Ben bir kayan nokta değeri olduğunu varsayalım. (Eğer bir int olsaydı, oyuncu seçmek için hiçbir sebep olmazdı). Ancak CostOutbir kayan nokta ise , belirsiz bir sıfıra bölme hatası gizlenebilir, çünkü bir kayan nokta değeri küçük ancak sıfır olmayabilir, ancak bir ondalık basamağa alındığında sıfır olabilir (en azından bunun mümkün olacağına inanıyorum).

Bu yüzden sorun kısalık veya yoksunluk değildir, sorun yinelenen mantık ve sürdürülmesi zor kodlara yol açan kaygıların bir araya gelmesidir.

Döküm değerlerini tutmak için değişkenlerin tanıtılması büyük olasılıkla, tokes sayısında sayılan kod boyutunu artıracak, ancak karmaşıklığı azaltacak, endişeleri ayrıştıracak ve netliği artıracaktır;

Kısalık hiç bir erdem değildir. Okunabilirlik erdemdir.

Kısalık, erdemi başarmada bir araç olabilir veya örneğinizde olduğu gibi tam tersi bir şey elde etmenin bir aracı olabilir. Bu şekilde veya başka bir şey, kendi değerinin neredeyse hiçbir değerini taşımaz. Kodun "mümkün olduğu kadar kısa" olması gerektiği kuralı "mümkün olduğu kadar müstehcen" ile de değiştirilebilir - hepsi daha büyük bir amaca hizmet etmiyorlarsa eşit derecede anlamsız ve potansiyel olarak zarar verebilirler.

Ayrıca, gönderdiğiniz kod, kısaltma kurallarına bile uymuyor. Sabitleri M soneki ile bildirilebilir olsaydı, korkunç çoğu (decimal)derleyici kalan teşvik gibi atmalarını, önlenebileceği intiçin decimal. Tanımladığınız kişinin sadece kısalıkları bahane olarak kullandığına inanıyorum. Büyük olasılıkla kasten değil, ama yine de.

Yılların tecrübesine göre, nihai kısalıkların zamanın zamanının olduğuna inanmaya başladım . Bu, hem performans zamanını hem de bir programın iş yapması ne kadar sürdüğünü ve bakım süresini - özellikler eklemenin veya hataları düzeltmenin ne kadar sürdüğünü içerir. (Bu ikisini nasıl dengelemeniz, söz konusu kodun ne sıklıkta yapıldığına ve geliştirildiğine bağlı olarak değişir - erken optimizasyonun hala tüm kötülüklerin kaynağı olduğunu unutmayın .) kısa kod genellikle daha hızlı çalışır ve genellikle anlaşılması ve bu nedenle bakımı kolaydır. Ya da yapmazsa, net bir negatifdir.

Burada gösterilen durumda, metnin kısalıklarının okunabilirlik pahasına, bakım süresini artırabilen satır sayısının kısalması olarak yanlış yorumlandığını düşünüyorum. (Döküm işleminin nasıl yapıldığına bağlı olarak gerçekleştirmek daha uzun sürebilir, ancak yukarıdaki satır milyonlarca kez çalıştırılmadığı sürece, bu muhtemelen bir sorun değildir.) Bu durumda, tekrarlayan ondalık sayılar okunabilirlikten çıkar, çünkü En önemli hesaplamanın ne olduğunu görün. Aşağıdaki gibi yazacaktım:

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(Düzenleme: bu, diğer cevapla aynı koddur, o yüzden işte gidin.)

Üçlü operatörün hayranıyım ? :, o yüzden onu içeride tutardım .

Okunabilirliğin üzerindeki neredeyse tüm cevaplar gibi her zaman birincil hedefiniz olmalıdır. Bununla birlikte, biçimlendirme işleminin değişkenler ve yeni çizgiler oluşturmaktan daha etkili bir yol olabileceğini de düşünüyorum.

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

Çoğu durumda döngüsel karmaşıklık argümanına şiddetle katılıyorum, ancak işleviniz iyi bir test durumuyla daha iyi ele alınabilecek kadar küçük ve basit görünüyor. Meraktan neden ondalık basmak gerek?

Bana göre, burada okunabilirlikle ilgili büyük bir sorun, tam bir biçimlendirme eksikliğinde yatıyor.

Ben böyle yazardım:

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

Arasında olup olmadığı türüne bağlı CostInve CostOutbir kayan nokta türü veya ayrılmaz bir tip olup, atmalarını bazıları da gereksiz olabilir. Aksine floatve doubleintegral değerleri dolaylı olarak teşvik edilir decimal.

Kod aceleyle yazılabilir, ancak yukarıdaki kod benim dünyamda daha iyi değişken isimlerle yazılmalıdır.

Ve eğer kodu doğru okursam, o zaman bir brüt kar marjı hesabı yapmaya çalışıyor.

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

Ben Costin * CostOut tam sayılardır varsayıyorum
Ben böyle yazardım nasıl
desimaldir M (Para)

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

Kod insanlar tarafından anlaşılmak için yazılmıştır; Bu durumda kısalık çok fazla satın almaz ve koruyucu üzerindeki yükü arttırır. Bu kısaltma için, kodu daha çok kendi kendine belgeleme yaparak (daha iyi değişken adları) ya da neden bu şekilde çalıştığını açıklayan daha fazla yorum ekleyerek kesinlikle genişletmelisiniz .

Bugün bir sorunu çözmek için kod yazdığınızda, gereksinimler değiştiğinde bu kod yarın sorun olabilir. Bakım her zaman dikkate alınmalıdır ve kodun anlaşılabilirliğinin arttırılması esastır.

Kısalık artık ne zaman bir erdem değildir

• Sıfır için önceden kontrol etmeden Bölme var.
• Null için çek yoktur.
• Temizleme yok.
• TRY CATCH versus, hatanın ele alınabileceği yiyecek zincirini atar.
• Eşzamansız görevlerin tamamlanma sırası hakkında varsayımlarda bulunulur.
• Gelecekte yeniden planlamak yerine gecikmeyi kullanan görevler
• Gereksiz G / Ç kullanılır
• İyimser güncelleme kullanmamak

Bu validasyon birimi testlerini geçiyorsa, sorun olmazsa, yeni bir özellik eklendiyse, yeni bir test veya gelişmiş bir uygulama gerekliydi ve kodun tersini "çözmek" gerekiyordu. sorun ortaya çıkar.

Açıkçası, koddaki bir hata Q / A ile ilgili bir gözetim olan başka bir sorun olduğunu gösteriyor; bu nedenle yakalanmayan bir hatanın olması endişeye neden oluyor.

Kodun "okunabilirliği" gibi işlevsel olmayan gereksinimlerle ilgilenirken, geliştirme yöneticisi tarafından tanımlanmalı ve lider geliştirici tarafından yönetilmeli ve uygun uygulamaları sağlamak için geliştiriciler tarafından saygı gösterilmelidir.

"Okunabilirliği" ve "bakım kolaylığı" kolaylığını sağlamak için standart bir kod uygulaması (standartlar ve sözleşmeler) sağlamaya çalışın. Ancak, bu kalite özellikleri tanımlanmamış ve uygulanmazsa, yukarıdaki örnek gibi bir kodla karşılaşacaksınız.

Bu tür bir kodu görmek istemiyorsanız, ekibin uygulama standartları ve sözleşmeleriyle ilgili anlaşmaya varmasını sağlayın ve yazın ve rastgele kod incelemeleri yapın ya da sözleşmeyi onaylamak için yerinde kontroller yapın.