Olası Kopya:
“İyi kod” yazmak ne anlama geliyor?
Kodlama kalitesi ve onu nasıl tanımladığınız üzerine bir tartışmada, hedefe ulaşmak için bir kod parçası kullanarak iki değeri nasıl değiştireceklerini göstermelerini sağlayarak insanların kodlama yeteneğini test etme üzerine bir tartışmaya rastladım. İki anahtar çözüm üretildi:
Daha sonra aslında daha iyi bir çözüm olan bir argüman ortaya çıkardı (ikincisinin var olduğunun farkında olarak ilk seçeneğe doğru eğilirdim, ancak söz konusu değerlere bağlı olarak her zaman beklendiği gibi değerlendirilmeyebilir).
Gerçek Programcı Mel hikayesini göz önünde bulundurarak, kodu zarif ya da değil olarak nasıl değerlendirdiğinizi bilmekle ilgileniyorum ve özlü zarif kodun temel bir özelliği.
İyi kod temiz, basit ve her şeyden önce anlaşılması kolay olmalıdır. Daha basit ve daha temiz, hataların kayma şansı o kadar az. Saint-Exupery başladıkça, "Mükemmellik elde edilir, eklenecek başka bir şey olmadığında değil, alınacak bir şey kaldığında. "
Dahası, zarif kod genellikle sorunun dikkatle analiz edilmesinin ve kodu büyük ölçüde basitleştiren bir algoritma ve tasarım bulmanın sonucudur (ve genellikle hızlandırır) çok). Örneğin. Programlama İncileri analiz sırasında kazanılan bir kavrayışın tamamen farklı bir saldırı açısı sağlayarak çok basit, zarif ve kısa bir çözüm sağladığını gösteren birkaç örnek gösterir.
Yazarın ne kadar zeki olduğunu gösteren ancak bundan sonra gelir ;-) Performans mikro optimizasyonu (bahsettiğiniz bitsel işlemleri kullanmak gibi) yalnızca söz konusu kod parçasının darboğaz olduğunu kanıtlayabildiğinde (somut ölçümlerle) kullanılmalıdır. ve değişikliğin performansı gerçekten artırdığını (tam tersine örnekler gördüm).
Zarif kod aşağıdakilerin bir kombinasyonudur:
Tabii ki, çoğu zaman gerçek atasözü de var: "Her soruna basit, zarif ve yanlış bir çözüm var".
* Aşağıdaki yorumların gösterdiği gibi, daha kısa kodda biraz çekişme vardır. "Özlü", "olabildiğince az karakterde" anlamına gelmez, "Kısaca ve açıkça ifade edilir" anlamına gelir.
Basit kod , acemi programcıların bile kodun ne yaptığını (en azından genel olarak) çalıştırabilecekleri kadar okunabilir bir koddur. (Bkz .: Ruby ifade sözdizimi )
Etkileyici bir şekilde karmaşık kod , okunabilirliğe dikkat etmeden mümkün olduğunca az sayıda satırda mümkün olan koddur (Bkz: Perl )
Zarif kod diğer geliştiricilerin "Ah adamım, neden böyle düşünmedim?" İlk ikisi arasında, ebeveynlerin okuyabileceği kadar açık olmayabilir, ancak yorumlanması için bir kodeks gerektiren bazı gizli taramalar değil. İşi yapar, yapar iyi, ve kodlarını koruyan insanları başlarını çizerek bırakmaz.
Fred Brooks bir çözümün karmaşıklığını "temel karmaşıklık" ve "yanlışlıkla karmaşıklık" kategorilerine ayırır. Bana göre çok zarif bir kod hepsi "temel karmaşıklık" ve hayır "kazayla karmaşıklık". İşin püf noktası, farklı programcıların "karmaşık" olanla ilgili farklı fikirleri olacaktır, bu yüzden biraz kodun zarif olup olmadığı konusunda anlaşamayız.
Örneğin, LISP kodunun yapısının, C benzeri dillerde kod yapısından çok daha zarif olduğunu düşünüyorum. Öte yandan, LISP'nin önek notasyonu ve açık ayrıştırma ağacı yapısı, matematiksel ifadelerin nasıl görünmesi gerektiği konusundaki sezgilerimizi ihlal eder, bu da LISP kodunu okumayı insanlar için daha zor hale getirebilir. Sonuç olarak, birçok programcı LISP'deki tüm bu parantezlerin "zarif" olmadığını, aslında çirkin olduğunu düşünmektedir. Derleyicinin kodu nasıl yorumlayacağından endişe duyan biri için, LISP zarif görünebilir. İnsanların kodu nasıl yorumlayacağı konusunda daha fazla endişe duyan biri için, LISP çirkin görünebilir.
Özlük önemli bir bileşendir, ancak benim için zarif olarak adlandırılabilmesi için, kodun "Tabii ki bunu yapmanın açık yolu budur!" Paradoksal olarak bile ilk düşündüğünüz yol değil. Bu testi geçemezse, "akıllı" veya "verimli" olarak adlandırılabilir, ancak zarif olamaz.
Zarif bir dil olan şiire benzer.
Şairler, başkalarının sayfalarının ve sayfalarının ne söyleyeceğini ve söylememesini çok az kelimeyle söyleyebilirler. Zarif kodlayıcılar kodla aynı şeyi yapabilir.
Tipik bir örnek, C'deki hızlı bir hızlı sıralama uygulamasının Haskell'deki hızlı sıralama ile karşılaştırılmasıdır:
quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p)
(üç satırlı bir çözüm için daha az ve daha fazla satır içi kullanılabilir).
XOR takas oldukça iyi bilinir ve Dijkstra'nın en azından biraz alçakgönüllülüğüne sahip olan herkes size söyleyecektir, bir şeyler yapmanın yanlış yolu değil. Derleyiciler de akış analizinde ve kayıt tahsisinde ve her türlü şeyde göreceli olarak iyidirler. İyi bir derleyiciye sahip olduğunuzda, oluşturduğunuz her değişkenin aslında yığınta/kayıtta bulunacağını bekleyemezsiniz. Yapmanız gereken şeyleri açık bir şekilde ifade etmektir.Arama yoluyla referansı destekleyen bir dilde bu the gitmenin yolu:
swap(x, y);.
Bu en iyi çözüm (en azından sağladığınız alternatifler göz önüne alındığında bunu söylemeye cesaret ediyorum). Bu bir ifadesidir ve açıklayıcıdır. XOR takas yaptığı gibi voodoo kullanmaz. Geçici bir değişken ve 3 atama ifadesinin gürültüsünü tanıtmaz. Bu takas içinde olan bir şeydir. Bir işlev olduğu varsayılarak, iyi bir derleyici bu çağrıyı sıraya koyacaktır.Bir makro da yapabilirsiniz.
Kodu gerçekten zarif yapan şey fazlalık eksikliğidir, dikliktir, sadeliktir. Üst üste büyüyen sağlam sistemler sağlar. Bir takas istediğinizde her yerde tekrarlayan ifade gruplarına sahip olmak artıklık getirir, diklikten yoksundur ve basitliği bozar.
Zarif kodun ne yaptığını tespit etmek kolaydır. "Neden bunu düşünmedim?" belirli bir his. Bu, sorunun ve kullanılan dilin ne kadar karmaşık olduğuna göre.
Bu, en iyi veya en basit çözümün otomatik olarak zarif olduğu anlamına gelmez. Basit genellikle niteliklerinden biridir. Değişiklikler, genellikle daha kolay olsa da, her zaman zarafeti korumaz.
Burada kodu medya ile karşılaştırmak istiyorum.
Çok basitleştirilmiş makaleleri okurken nefret ettiğini biliyorsunuz. Aptalca. Birkaç gerçek, basit cümleler. Bu, yeni başlayanlara bağladığım koda çevirir: Önemsiz, naif, uygulama, hiçbir şey çok karmaşık değildir, ancak uzun ve gereksiz adımlarla doludur.
Öte yandan bu fildişi kule stilini biliyorsunuz. Tanınmış filozoflardan bir kitap okudunuz. Karmaşık bir konuda bir bilim makalesi okudunuz: Stil genellikle çok uzun görünüyor. Kelimeler yeniden kullanılmaz, bir düzine eşanlamlı bildiğinizi göstermek zorundasınız. Gerçek içerik saf, iyi, ilginç olsa da - yazma tarzı takip etmeyi zorlaştırır. Bu tarz orijinal düşünce çizgisini bulanıklaştırır. Bu zeki kodudur.
Zarif kod ortada bir yerde ve tercihler kadar öznel. Kötü vakaları kolayca tespit edebilir ve tanımlayabilirsiniz, ancak mükemmellik çoğumuz için farklıdır.
İyi, Bad'in olmamasıdır. Hayattaki her şey için geçerlidir ve kod bir istisna değildir. Böylece,
İyi kod, kokusu olmayan bir koddur! Bu nedenle, bir kod kokusunun ne olduğunu görmeniz ve anlamanız önemlidir. Şaka yapılmaz.
Bunu düşün. Sadece mutlu olmadığınızı veya üzüntünüzden kaçtığınız için mutlu olduğunuzu söylüyorsunuz. Aynı şekilde, kodda kötü bir şey görmediğinizde iyi bir kod olarak adlandırırsınız. Kodun her kalite yönüne (sürdürülebilirlik, okunabilirlik, vb.) Kod kokusundan kurtularak ulaşılabilir. Ve ister inanın ister inanmayın, bu ilk seferde olmaz - tekrar tekrar olur :)
Zarafet, karmaşıklığın en aza indirilmesidir. Kodu hızlı bir şekilde makul becerilere sahip başka bir programcıya verebiliyorsanız ve çalışmaya devam edebiliyorlarsa (ve umarım ilk standardına kadar yaşayabilirler), kod muhtemelen zariftir.
İyi yazılmış bir yazılım en az on yıl kalmalıdır. İlk zarafet daha sonraki saldırılardan korkabilir, ancak kodun hayatta kaldığı süre genellikle başlangıçta ne kadar iyi yazıldığının makul bir ölçüsüdür. Kötü yazılmış kod ya durgunlaşıyor (ve insanlar etrafı hackliyor) ya da yeniden çalışılıyor (pratikte insanların zarif kodları daha az çözümlerle değiştirdiklerini gördüm, çünkü dikkatlice bakamadılar).
Benim tanımım basittir maalesef kendiniz belirleyemezsiniz.
Zarif Kod aşağıdaki özelliklere sahiptir:
Zarif kod zarif tasarımla aynı değildir, ancak 2 arasında bir çaprazlama vardır.
Zarif bir tabloyu nasıl tanımlıyorsunuz? Bakmak güzel, mükemmel okunabilir, mükemmel mantıklı bir şekilde kolayca korunabilir ve sadece işi yapar.
Zarif tasarım zarif kodda yardımcı olur. İyi bir tasarıma sahip olmayan zarif bir koda sahip olamazsınız, ancak iyi bir tasarıma sahip çirkin bir koda sahip olabilirsiniz. Can_can_add_apples_to_my_basket (20) sonra yazmak çok daha iyi, sonra add_apples_to_basket (20) başka render_not_enough_room_to_add_apples (20) biterse, daha sonra ihtiyacınız olan her şey için ihtiyaç duyduğunuzda yeniden kullanılabilir olabilecek 2 tasarım koşulunu yazın (tasarım biti)
b.count + 20 <= b.max o zaman b + = 20 başka zam ("çok fazla elma") biterse sais kodu
Hala 2 yönteme (sayım ve maks.) Sahipsiniz, bu yüzden hala iyi bir tasarıma sahipsiniz, ancak kod çirkin ve anlamsız, sistem bilgisi olmadan bakımı zor ve tamamen belirsiz
Dürüst olmak gerekirse, iki değişkenin değerini değiştirmek için nadiren iyi bir neden vardır ve bunu nasıl yaparsanız yapın gerçekten "zarif" bir şey değildir.
Zarif kod kendi içinde kodla ilgili değil, gerçekten ne kod yapar ve nasıl yapar. Şahsen bunun "zarif kod" un ne olduğunu belirlemek için kötü bir örnek olduğunu düşünüyorum, çünkü yapılan şeyin kendisi zarif değil. Haskell kodunun genellikle zarif olduğunu düşünüyorum, çünkü (çoğunlukla) değişmez değerler ile ilgileniyor. Bununla birlikte, değişken durumu kullanan algoritmalar gerçekten de zarif bir şekilde yazılabilir (ve genellikle Haskell'de çok sıcak görünmez).
Çoğu geliştirici bunu ne kadar kolay okuyabilir? Değiştirmek ne kadar kolay?
Sonuç olarak, opton 1'in çok daha zarif olduğunu kesinlikle kabul ediyorum.
Seçenek 2 akıllıdır ve operatörler hakkında iyi bilgi verir. Ayrıca çok küçük bir bellek tasarrufu sağlar. Belki de istisnai durumlarda faydalıdır ve bir geliştiricinin yapmasına değer. Ama ortalama% 99 durumunuzda değil.
tutarlı olmalıydı. İçinde bir çeşit desen olmalıydı. Ve bu kalıbı kırmanız gerektiğinde, tutarlı bir şekilde kırın, böylece genel olarak hala bir çeşit kalıp vardır.
Birisi kodunuzu gösterir ve neden bu şekilde yapıyorsun soruysa ve cevabınız "Bilmiyorum, ben sadece bu şekilde yapıyorum çünkü ben böyle ' öğretildi/çünkü herkes böyle yapıyor " o zaman bu kod ya zarif olabilir ya da olmayabilir zarif . Ancak kodun neden bu şekilde olduğunu açıklayabilirseniz, neden bu şekilde kodlamayı seçtiniz, diğer alternatifler neden çekici değil, o zaman kodun zarif olduğundan emin olabilirsiniz .
En üstteki yorumumda yanmıştım, ama benim için zarif kod, duyularımı çok daha fazla etkileyen şey.
Kısa ve öz, basitlik ancak amaç ve güç, şık, simetrik ve yaklaşımda biraz 'kutunun dışında' olmakla birlikte hedeflere ulaşmada olumlu bir tepki üretir. Bir sürpriz unsuru doğurur. Yöntem ve algoritma, anlaşılmasını engelleyecek kadar karmaşık değildir (en azından yüzeysel olarak).
Zarif kod, parçalarının toplamından daha fazlasıdır. Bazen zarif kod, kaba kuvvet kullanmak veya verileri başka bir forma eşlemek yerine, neredeyse verilerle çalışmak, onlarla eğilmek gibi görünüyor. Benim için, zarafet genellikle kendi kendine yeten bir pakette gelir - ne çok uzun ne de çok kısa olan tek bir işlev, az veya hiç harici çağrı.
Örneğin, zarif diyeceğim sıralama yöntemlerini gördüm. Ve fraktalları alışılmadık ama yüksek verimli şekillerde çizmek için zarif kod/algoritmalar - görsel güzelliği birleştirmek ve kodlama zerafeti!
Zarif kod, çoğu insanın düşündüğünden daha az kodda bir şey başarmak için akıllılık kullanır, ancak okunabilir ve açık bir şekilde görünür ve kod golfüne benzemez.
Bu gerçekten kime sorduğunuza bağlı. Matematiksel bir arka plandan gelen biri, deneyimli bir programcının sorunlu bulabileceği kodu sık sık tercih edecektir. Bu çok öznel görünmesini sağlar.
Ayrıca, farklı dillerin aynı sorunu çözmenin farklı yolları olduğunu göreceksiniz. Örneğin Python'da iki değişkeni değiştirmek önemsizdir:
x, y = y, x
Uygulamada, çoğu programcı bazı ortak kriterler olduğu konusunda hemfikirdir:
Bu, zarafetin çok pragmatik bir görünümüdür. Kod "akıllı" olmamalı veya bu kriterleri geçememelidir. Ancak ayarlanması ve uzatılması bakımı kolay ve kolay olacaktır.
Bununla birlikte, bu listedeki kuralların çoğunda kesinlikle başarısız olmasına rağmen bir sanat eseri olabilecek kod var. "Akıllı" kod genellikle bu kategoriye girer. Çok yoğundur, genellikle altta yatan uygulamaların (örneğin bellek yönetimi veya derleyicinin tam olarak uygulanması) kapsamlı bir şekilde anlaşılmasına dayanır, ancak yine de yüce bir hayranlık uyandırır.
Yet Another Perl Hacker komut dosyalarında bulabileceğiniz zarafet ile aslında üretimde kullanmak istediğiniz kod arasında bir fark vardır. Onun büyük opus zarif diyebilirsin bile Mel asla takımında olmasını istememesinin nedeni budur.
Şahsen abartılacak zarif kod buluyorum. Ama performans kodunun kritik öneme sahip olduğu ve SQL kodu bağlamında (en azından tecrübelerime göre) "zarif" kodun kötü performans gösterdiği veritabanı dünyasında çalışıyorum. Zarif SQL kodu yazmak isteyen birini her duyduğumda küfrediyorum.
Yine de genel olarak, zarafet için çabalamanın saçma olduğunu düşünüyorum. İlk etapta hiç kimse onu uygun şekilde tanımlayamaz. İstediğiniz şey, düzgün çalışan, iyi performans gösteren, bakım yapılabilen ve daha sonra zarif, listeyi bile yaparsa çok uzak bir dördüncü koddur.
Zarif kodu anlamak bir bulmacayı çözmek gibi olmalıdır. İlk önce anlamak zor, sonra "anladım" sonra anlamak çok kolay olmalıdır.
Bir değiş tokuş var - onu anlamayan insanlar kafalarını kaşıyorlar, anlayan insanlar bunu geriye doğru bakarken açık buluyorlar.
Değişkenleri değiştirmeye gelince, ikisi de özellikle zarif olmayacaktır. Burada evcilleştirilecek bir karmaşıklık yoktur, bu yüzden "zarif" bir çözüm için bir alan yoktur.