Sadelik her zaman Okunabilirliği arttırır mı?

Son zamanlarda şirketimiz için bir takım kodlama standartları geliştiriyordum. (Biz şirket için yeni bir dilde dallanan yeni bir ekibiz.)

İlk taslağımda, kodlama standartlarımızın amacını Okunabilirliği, Korunabilirliği, Güvenilirliği ve Performansı iyileştirme olarak belirledim. (Yazılabilirliği, taşınabilirliği, maliyeti, önceki standartlarla uyumluluğu vb. Dikkate almadım)

Bu belgeyi yazarken hedeflerimden biri, kod basitliği fikrini ilerletmekti. Buradaki fikir, hat başına yalnızca bir işlev çağrısı veya işlem olması gerektiğidir. Umudum bunun okunabilirliği arttırmasıydı. Önceki dilden aktardığım bir fikir.

Ancak, bu itişin arkasındaki varsayımı sorguladım:

Sadelik her zaman okunabilirliği arttırır mı?

Basit kod yazmanın okunabilirliği azalttığı bir durum var mı?

Açık olması gerekir, ancak "daha basit" derken, "yazmak daha kolay" anlamına gelmez, ancak satır başına daha az şeyler olur.

"Basit", çok kullanılmış bir kelimedir. “Okunabilir” karlı bir şekilde “anlaşılması basit” olarak tanımlanabilir, bu durumda tanımın sadeliğiyle artan (bu ölçüsü) okunabilirliği arttırır, ancak bunun ne demek istediğini sanmıyorum. Ben ettik yazılı hakkında bu başka bir yerde , ama genellikle bir şey ya (ki bu durumda daha az kavramlar daha olguları ifade edebilir) daha soyut kalarak ya da daha somut kalarak "daha basit" denebilir (bu durumda bir kavram çok arka plan olarak gerektirmez ilk etapta anlamak için bilgi). Bakış açısına bağlı olarak daha soyut bir kavramın daha somut bir kavramdan daha basit ya da tam tersi olarak adlandırılabileceğini savunuyorum . Bu, "soyut" ve "olsa bile"

Bir süre önce yazdığım bazı Haskell kodlarını örnek olarak kullanacağım. Ben stackoverflow bir soru sordum her basamak farklı bir üs niteliği de olan bir sayaç hesaplamak için Liste monad kullanma hakkında. Sondaki çözümüm (pek fazla Haskell bilmeden) şuna benziyordu:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Cevaplardan biri bunu azalttı:

count = mapM (enumFromTo 0)

Bunlardan hangisinin anlaşılması "basittir" (yani daha okunaklı) tamamen okuyucunun (soyut) monadik işlemlerle (ve bu konuda noktasuz kodlarla) ne kadar rahat hale geldiğine bağlıdır. Bu soyut kavramlarla çok rahat bir okur (kısa) daha soyut versiyonunu okumayı tercih ederken, bu işlemlerle rahat olmayan bir kişi (uzun) daha somut versiyonunu okumayı tercih edecektir. Hangi sürümün herkes için daha fazla okunabileceği hakkında bir cevap yok.

Kodlama standardınız "Okunabilirlik, Bakım Kolaylığı, Güvenilirlik ve Performans" ile ilgiliyse, bunu belirtin .

Her zaman bir karşı örnek olduğu durumlar olacağından, bu şeylere nasıl ulaşılacağına karar vermeyin.

Reçetelemeniz gereken, eğer uyulmazsa, kodun kırılmasına neden olacak şeylerdir. Stilistik özellikler kodu kırmayacak ve önerilerde bulunmalıdır (ekibin çoğu, Okunabilirlik olduğu konusunda hemfikir olduğu sürece, geliştirici tercihi olmalıdır (kod incelemesiyle birlikte, arkadaş baskısının diğer kişilerin kodu okuması gerektiğini hatırlatması)) .

Daha az "satır başına malzeme", basitlik ve okunabilirlik aynı şey değildir. Biri inanılmaz derecede karmaşık, gizli belgelenmemiş bir algoritma alabilir ve bunu 2 yerine satır başına 1 ifadeyle kodlayabilir ve bu daha okunaklı hale gelmez.

Daha az "satır başına malzeme" de, kod bloklarının artık daha dikey olarak dağıldığını görmek için geliştiricilere büyük büyük boy monitörleri tedarik etmeyi gerektirebilir. Veya daha küçük fontları okumak için göz yorgunluğuna neden olabilirsiniz.

Okunabilirlik, çok daha kolay ölçülebilen diğer ölçümler arasında bir uzlaşma gerektiren çok kendi ölçüsüdür. Diğer tüm ölçümleri önceden sınırlandırın ve uzlaşma artık mümkün olmaz ve böylece daha az okunabilir kod elde edilir.

Her zaman? - YOK HAYIR

İronik olarak, doğru basitlik seviyesine ulaşmak karmaşık bir girişim olabilir. Anahtarın ölçülü olduğunu düşünüyorum. Sadelik, aynı zamanda bakanın gözünde de olabilir, bu yüzden eğer kendinizi fazla düşünürseniz bulursunuz - sadece rahat bırakın veya daha sonra tekrar gelin.

Şahsen, geri dönüp yazdığım bir şeyi basitleştirmeye çalıştığımda, fikrimi değiştirdiğim veya istediğim şeyi elde etmek için birkaç şey denediğim alanlara odaklanıyorum. Bu alanlar genellikle düzeltilebilir. Daha sonra, kod ayıklama işleminde daha fazla okunabilir hale getirmek için bir kaç geçiş yapın, bir hata ayıklamada neler olup bittiğini anlamak için her yere sıçradığınız gibi.

Basitlik için gidersem, şöyle bir kod yazabilirim:

10000000000000000000000000000000000000000000

Ancak okunabilirliğe gidersem, bunu tercih ederim:

1e43

Öte yandan, her zaman bilimsel gösterimde sayılarla çalışmadığınızdan 1000çok daha okunaklı ve basittir 1e3.

Bu, hemen hemen her yerde bulabileceğiniz çok daha genel bir desene ait dejenere bir örnektir - çok basit bloklardan bir şey inşa etmek, birçok farklı yoldan hızla okunamayan / yetersiz / kötü hale gelebilir. Öte yandan, genelleme ve yeniden kullanma ilk başta daha zordur ("wtf?! eYazmak istiyorlar mıydı 1343?" Diyebilir), ancak uzun vadede çok yardımcı olabilir.

Şart değil. Eğer karmaşık bir operasyonunuz varsa, bu karmaşıklık bir yere gitmek zorunda. Tek bir satıra giden "malzeme" sayısının azaltılması, sadece rutininizin bir ekrana sığmayacak kadar "uzun" olmasını sağlaması durumunda kod okunabilirliğine gerçekten zararlı olabileceği anlamına gelir.

Netlik + Standartlar + Kod Yeniden Kullanım + İyi Yorumlar + İyi Tasarım okunabilirliği artırabilir .

Sadelik her zaman geliştiricinin elinde değildir, çünkü algoritmaların doğası ve bugünlerde uygulama yapısının karmaşıklığı.

Basit görevleri gerçekleştiren basit web sayfalarını alın. Bir sıralama rutini göz önüne alındığında, mantığı basitleştirmek mümkün değildir, ancak anlamlı değişken adları kullanarak, yapılandırılmış bir şekilde yazmasını vb. Kullanarak yorumlarla daha net hale getirebilirsiniz.

Sadelik her zaman okunabilirliği arttırır mı?

Hayır. Bir satırda çok daha basit şeyler yapmanın birden çok satıra sahip olmaktan daha az karmaşık olduğu birçok durum gördüm.

Daha az kod ve daha basit kod arasında bir denge var.

Genel olarak, daha az satırda daha iyi olduğundan emin değilseniz, daha basit bir kod için gitmenizi tavsiye ederim. Çok "çok karmaşık" bir kod üzerinde "çok ayrıntılı" bir kod olurdu.

"Mümkün olduğunca basit, ama daha basit bir şey yapmayın" - Albert Einstein’ın sıkça bir ifadesi

Sadelik her şeyi geliştirir . Tabii ki, basitliğin farklı değerleri için. Daha az kod satırı mı? Olabilir. Daha küçük bir çalıştırılabilir mi? Muhtemelen. Takımınızın üzerinde mutabık kalması gereken bir şey mi? Kesinlikle .

Sadelik her zaman okunabilirliği arttırır mı? Evet. Satır başına bir ifade her zaman daha mı basit? Hayır. Oldukça az sayıda dilde, kavradığında bir kez daha anlaşılması kolay olan ve eşdeğer if / else atamalarından daha kolay olan bir üçlü operatör vardır.

Birden fazla değişkenin bir satırda ayarlanmasına izin veren dillerde, bunu yapmak eşdeğerin ne olduğundan daha kolay ve anlaşılması kolaydır.

Başka bir örnek: düzenli ifadeler, genellikle sadece bir satırda çok şey yapar ve regex içermeyen eşdeğeri okumak genellikle daha zordur. / \ d {3} [-] \ d {3} - \ d {4} /, bir fonksiyon çağrısının en az birkaç yorumu olan eşdeğeridir ve anlaşılması, ilgili fonksiyon gövdesinden daha kolaydır.

Okunabilirlik ve basitlik, kişiye ve içeriğe bağlı olarak, genellikle ancak her zaman bir arada gitmeyen öznel terimlerdir.

Daha nesnel bir terim özlüktür - prensipte yapabileceğiniz bir şey, karakterleri sayarak saymaktır, bununla ilgili bazı kusurlar vardır. Sünnetlilik basitlik ve okunabilirlik anlamına gelir, ancak (en azından benim görüşüme göre) istisnalar vardır.

Daha uzun (ve tartışmalı olarak daha karmaşık) bir kod parçası, amacı daha iyi ifade ederse daha kolay okunabilir. Sadelik tanımınızın niyetle ilgilenip ilgilenmediği bir başka öznel şeydir - karmaşıklığı, örneğin niyetlere atıfta bulunmadan sözdizimsel yapı ve bilgi teorisi entropisi olarak tanımlayabilirsiniz.

Yani, iyi seçilmiş, uzun değişken bir isim olabilir ...

• Niyeti daha iyi ifade ederek okunabilirliği artırın
• Netliği azaltın - sonuçta daha uzun
• Sözdizimsel basitlik üzerinde hiçbir etkisi yoktur - kodun sözdizimsel yapısı değişmez

Benzer şekilde yazabilirim if (some_boolean == true). Eşdeğer alternatif ile karşılaştırıldığında if (some_boolean), bu ...

• Özlülüğü azaltır
• Sözdizimsel sadeliği azaltır, ancak
• Niyeti daha iyi ifade ederek okunabilirliği artırabilir.

Elbette bu, kitlesel bir protestoyu tetikleyecek - birçok insan için bu da okunabilirliğe her zaman zarar verir. Bana göre, boole kaynağına çok bağlıdır - örneğin değişken ismi (veya yöntem ismi veya her neyse) değerin "gerçek değer" olduğunu açıkça ifade etmeyebilir. Elbette, ifsize bir şey söylüyor, ama yine de kokuyor. Fakat birçok insan bana buna inandığım için aptal diyecek.

Tabii ki, genel öznelliğin bir başka kanıtı.

Hepiniz bazı temel tanımları kaçırıyorsunuz . Basit, kök simpleksinden bir kat anlamına gelir . Basit, bir şeyi yapmak demektir . Kolay, kök kolaylığından , yakınlarda yatmak demektir . Kolay , elinizin altında olduğu anlamına gelir . Diğer cevaplarda verilen basit kod örnekleri tam olarak göründüğü gibi değildir.

Al rotsor en çok büyük bir değere görüntülenmesini. Bunun basit olduğunu söylüyor . Benim düşünceme göre basit değil. Bu kolay. Gerekli 0'ların sayısını girmek için elinizin altında.

10000000000000000000000000000000000000000000

Okunabilir versiyonu basittir. Bir şey yapıyor. Bu fonksiyon için oluşturulmuş bir gösterim amacında boyutunu tanımlayarak numarayı ifade eder.

1e43

Aidan'ın "basit" kod pasajını tek bir şey olarak tanımlayabilir misiniz ? 10 satır kod içerir (yorumları saymaz) ve en az 7 satır (bunları sayardım). Yorumları izlerseniz en az 4 şey yaptığını görürsünüz!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Ancak, bu kodu yeniden yazmak için önerilerden biri de bir ifadeydi. Aidan, bir okuyucunun monadik ifadelere, işaretçi serbest koduna vb. Aşina olması veya aşina olması gerektiğini belirtir. Bu kavramlar tekil ve öğrenmekten bağımsızdır.

count = mapM (enumFromTo 0)

Gerçekten basit kodun kolay koddan daha okunabilir olduğunu göreceksiniz , çünkü yalnızca bir şey yapar. Basit kodu anlamak için hemen gidip "bir şey" öğrenmeniz gerekebilir . Ancak her zaman daha okunaklı olmalı.

Sadelik her zaman okunabilirliği arttırır mı?

Belki biraz tartışmalı olabilir, kesinlikle olmaz derdim .

Genel arayüzünde 200 üye işlevli bir sınıfı bana verebilirsiniz, ve orada insanca okunabilen en genel arayüz olabilir. Bu kod ve dokümantasyonunu sadece rasgele okuyan bir sevinç olabilir. Bununla birlikte, "basit" olarak adlandırmazdım, çünkü okunabilirliğe rağmen, tüm bu işlevlerin birbiriyle nasıl etkileşimde bulunduğuyla ilgilenmek zorunda kalacak ve kötüye kullanımdan kaynaklanan zor durumlara dikkat etmem gerekecek.

200'e kadar okunması kolay olmayan 20 üye işlevine sahip bir sınıfı tercih ederdim, çünkü “okunabilirlik” insan hatasını önlemek ve kodun korunabilirliğini geliştirmek açısından benim için en önemli öncelik değil (ki değiştirebiliriz, yani).

Ancak, bu bizim kişisel "basitlik" tanımımıza dayanacaktır. "Okunabilirlik" tipik değişmez olduğu birisi bize ölümlüler kalanını unutmak örneğin çok "okunabilir" olarak regex düşünün o kadar çok uzmanlık ve akıcılık satın aldı sürece aramızda çılgınca.

Basitlik

Uzun zaman önce, "basitliğin" "mümkün olduğunca kolay okunması" anlamına geldiğini düşündüğüm bir zaman vardı. Bu yüzden, C kodunu bir çok kolaylık işleviyle yazıp, sözdizimini geliştirmeye ve her şeyi olabildiğince kolay okuyup yazmaya çalışırdım.

Sonuç olarak çok büyük, zengin, üst düzey kütüphaneler tasarladım, sonuçta her doğal insan düşüncesi için bir işlev modellemeye çalıştım: her biri müşteri kodunu daha okunaklı bir sözdizimine biçimlendirmek için yardımcılara yardım edenlere yardımcı oldu. O zaman yazdığım kod en "okunabilir" olabilirdi, ama aynı zamanda en "sürdürülemez" ve "karmaşık" idi.

yanlış telaffuz

Ancak 90'ların ortalarında (geç kalan) LISP ile kısa bir tutkum vardı. Tüm "basitlik" fikrimi değiştirdi.

LISP olduğunu değil en okunabilir dili. İnşallah kimse, CDR'leri ve CAR'ları çıkarırken, bir tekne dolusu parantez içerisindeki özyinelemeli bir işlevi çağırırken çok "okunabilir" olduğunu düşünmez.

Yine de, beynimi dilin garip sözdizimine sarmak ve işlerimi tamamen özyinelemeli yollarla sarmak için uğraştıktan sonra, basitlik fikrimi kalıcı olarak değiştirdi.

LISP’de yazdığım kodla bulduğum şey, artık bu şekilde düşünmemenin hilesi daha bariz hatalar yapmamı sağlasa da (ama bunların farkına varmak ve düzeltmek kolaydır). Bir fonksiyonun ne yaptığını ve incelikli, beklenmedik bir yan etkiyi kaçırdığını yanlış anlamadım. Genelde değişiklik yapmak ve doğru programları yazmakta daha kolay zaman geçiriyordum.

LISP'den sonra bana basitlik , sonsuz çeşitlilikte bir araya gelen minimalizm, simetri, esneklik, daha az yan etki, daha az ama daha esnek fonksiyonlar oldu.

Zihniyetin en güvenilir kodunun var olmayan kod olduğunu anlamaya başladım. Sadece ham bir metrik olmasına rağmen, miktarına bağlı olarak kodun güvenilmezliği potansiyelini görmeye meyilliyim. En üst sözdizimsel rahatlığı ve okunabilirliği aramak, bu miktarı büyük bir faktörle artırma eğilimindedir.

Minimalizm

İçimdeki LISP zihniyetiyle minimalist API'leri tercih etmeye geldim. Daha az kullanışlı, esnek fonksiyonlara sahip, daha az kullanışlı ve okuması daha zor, "uygun" yardımcılar sunan ve kodun "okunmasını kolay" ancak potansiyel olarak açılmasını kolaylaştırabilecek olanlardan daha zor olan bir kütüphaneyi tercih ederim. Güvenilmezlik ve sürprizlerle ilgili daha fazla sorun, bu binlerce işlevin ne yaptığını yanlış anlamadan kaynaklanıyor.

Emniyet

LISP ile ilgili diğer bir şey güvenlikti. Minimal yan etkiler ve saf işlevler sağladı ve bu dilde okuma ve yazma zorluğu 10 saniye sonra farkedebildiğim kadar bariz hatalar artmasına rağmen artık kendimi ince hatalar yaparken görmedim.

Saf fonksiyonlar ve değişmez durumlar, ne zaman sözdizimi olsa bile, karşılayabileceğim her durumda benim için tercih edildi.

sword = sharpen(sword)

... insan düşüncesinden biraz daha az basit ve kopuktur:

sharpen(sword)

Okunabilirlik VS. Basitlik

Yine, LISP en "okunabilir" dil değil. Küçük bir kod bölümüne (büyük olasılıkla her satırda birden fazla insan düşüncesi) çok fazla mantık toplayabilir. İdeal olarak satır başına bir insan düşüncesini "okunabilirlik" olarak tercih etme eğilimindeyim, ancak zorunlu olarak "sadelik" için degil.

Bu tür bir "basit" tanımı ile, bazen "basit" aslında "okunabilir" ile rekabet edebilir. Bu, bir arayüz tasarımı açısından daha fazla şey düşünüyor.

Basit bir arayüz, onu kullanmak için daha az şey öğrenmeniz gerektiği ve minimalizminin sonucu olarak potansiyel olarak daha yüksek güvenilirlik ve daha az getiri elde edeceğiniz anlamına gelir. Konuyla ilgili kapsamlı bir belge, çok sayıda kitap yerine bir kitapçığa sığabilir. Bununla birlikte, biraz daha sağlam çalışma gerektirebilir ve daha az okunabilir kod verebilir.

Bana göre "basit", sistemimizdeki işlevselliği geniş bir seviyede anlama yeteneğimizi geliştirir. Bana "Okunabilir", her küçük kod satırını doğal dile ve düşünceye bağlama yeteneğimizi geliştirir ve özellikle de dilde akıcı değilse, bir kod satırının ne yaptığını anlamamızı hızlandırabilir.

Regex "son derece basit" olarak düşündüklerimin bir örneği. Kişisel zevkime göre "çok basit ve okunamaz". Bu aşırı uçlar arasında benim için bir dengeleyici hareket var, ancak regex benim tanımladığım gibi LISP benzeri sadelik kalitesine sahip: minimalizm, simetri, inanılmaz esneklik, güvenilirlik, vb. akıcı olacağımı sanmadığım noktaya o kadar okunaksız hale geldi (beynim sadece bu şekilde çalışmıyor ve regex kodunu akıcı bir şekilde yazabilen insanları kıskanıyorum).

Her neyse, bu benim "basitlik" tanımımdır ve "okunabilirlikten" tamamen bağımsızdır ve bazen daha "sözdizimsel olarak uygun" ve okunabilir ancak daha büyük bir kütüphane ya da "sözdizimsel olarak" daha büyük bir kütüphane ya da "dengeleyici bir harekete yol açabilir uygunsuz ", daha az okunabilir, ancak daha küçük kütüphane. Ben her zaman gerçek “anlama rahatlığı” ve gerçek “sürdürülebilirlik” önceliklerini, ikincisi ile uyumlu hale getirme önceliklerini buldum, hatta bir miktar maliyetle okunabilirlik ve daha doğal insan sözdizimi için (ancak regex için değil) minimalizm yönündeki güçlü tercihle . YMMV.

Her zaman? - EVET

Doğru basitlik seviyesine ulaşmak, karmaşık ve zor bir iştir. Ancak her zaman okunabilirliği geliştirdiği için her zaman değerlidir. Anahtarın derin anlayış olduğunu düşünüyorum. Sadelik, kodun her parçası için "yeni kavramlar" ile ölçülen mutlak bir değerdir. Birkaç yeni kavram daha basit demektir.

Yoğun bir küme kavramının olduğu alanlara odaklanın ve "yığın" veya "özet" veya "özet" yollarını bulun. Daha basit ve daha okunaklı olması için kodda birkaç geçiş yapın.

İyi bir soyutlama altın ağırlığına değiyor. İyi bir soyutlama bu işi daha basit ve sonuçta daha okunaklı hale getirir.

Sorular bana Yığın Taşması ile ilgili bu cevabı , özellikle de şu alıntıyı hatırlatıyor (kaliteyi sadelikle değiştiriyor):

Kalite - ne olduğunu biliyorsunuz, henüz ne olduğunu bilmiyorsunuz. Ama bu kendi kendine çelişkili. Ancak bazı şeyler diğerlerinden daha iyidir, yani daha kalitelidirler. Ancak kalitenin ne olduğunu söylemeye çalıştığınızda, sahip olanların yanı sıra her şey yolunda gider! Konuşacak bir şey yok. Ancak, Kalitenin ne olduğunu söyleyemiyorsanız, ne olduğunu nasıl bildiniz, ya da var olduğunu bile nereden biliyorsunuz? Hiç kimse bunun ne olduğunu bilmiyorsa, o zaman tüm pratik amaçlar için hiç mevcut değildir. Ancak tüm pratik amaçlar için gerçekten var. Notlar başka nelerden kaynaklanıyor? Neden insanlar bazı şeyler için servet ödüyorlar ve başkalarını çöp yığınına atıyorlar? Açıkçası, bazı şeyler diğerlerinden daha iyidir - fakat “nezaket” nedir? - O yüzden yuvarlak ve yuvarlak gidiyorsun. Dönen zihinsel tekerlekler ve hiçbir yerde çekiş için herhangi bir yer bulma. Kalite nedir? Bu ne?

Tüm faydaları için kodlanmış bir kodlama standardının iyi programcıları kötü programlardan çıkarmayacağını aklınızda tutmanızın önemli olduğunu düşünüyorum. 'Basit' gibi bir kelime farklı insanlar tarafından farklı şekilde yorumlanabilir (bakınız Aidan Cully'nin cevabı), ancak bu çok kötü bir şey olmayabilir. Genç programcıların kodlarını kıdemli programcılar tarafından gözden geçirmeleri ve kıdemli programcıların 'basit' yorumlamalarının neden kendilerinden daha iyi olduğunu öğrenmeleri gerekir.

Hat başına bir işlev çağrısı basittir? Bir örnek deneyelim!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Ne düşünüyorsun? Hat başına bir çağrı gerçekten daha mı basit?