Kod okunabilirliğini ne kadar etkili kod ile feda etmelisiniz? [kapalı]

Kod okunabilirliğini ne kadar etkili kod ile feda etmelisiniz?

Örneğin, 1 satıra 3 satır kod.

Ben okuduğum Kod Craft okunabilirliği önemli olduğunu Pete Goodliffe tarafından.

Senin düşüncelerin?

"Daha az satır" her zaman "daha verimli" ile aynı şey değildir. "Bir programın okunabilirlik pahasına kısaltılması gerekiyor" anlamına geldiğini farz ediyorum.

İnsanların okuması için programlar yazılmalı ve yalnızca makinelerin çalışması için bu arada yazılmalıdır.

-Abelson & Sussman, Bilgisayar Programlarının Yapısı ve Yorumlanması

Genel olarak, bir programın kısa olması gerektiğinden daha kolay anlaşılmasının daha önemli olduğunu düşünüyorum. Yine de şunu söylemeliyim ki, bir programı daha da kısaltmak da onu daha okunaklı kılıyor (kodunuz hat gürültüsü gibi görünmeye başladığında elde edeceğiniz açık bir eşik var, ancak bu noktaya kadar, daha net bir şekilde ifade etmek daha net hale geliyor gibi görünüyor).

Hiç kimsenin sürdürmesi gerekmeyecek ve yalnızca sizin okumaya ihtiyacınız olacak özel istisnalar (kişisel kabuk komut dosyalarınız veya veri aktarma kodlarından biri gibi) vardır. Bu durumda, hala anlayabildiğiniz sürece, çare için okunabilirliği feda etmek muhtemelen mümkündür.

Bazen evet.

Okunabilme çabası için iyi bir şeydir. Tipik iş kolu uygulamaları için yazılan çoğu kod yeterince performans gösterecek ve okunabilirliğe odaklanmak önemlidir. Daha fazla performans gerektiren alanlarda (video oyunu programlama veya yoğun hesaplama gibi), okunaksızlığı bırakmak, korkunç bir şekilde okunamayan ve yine de inanılmaz derecede performans gösteren belirli bir dil özelliğini kullanmaktan vazgeçmek önemli olabilir.

İkincisinin bir örneği için Wikipedia'daki Hızlı Ters Karekökü makalesine bakın.

Genel olarak, önce okunabilir bir şey yapmanın daha iyi olacağını düşünüyorum ve sonrasında O (n) üzerinde bir O (n ^ 2) algoritması seçmeme gibi sağduyulu önlemler alındıktan sonra performans konusunda endişe duyuyorum. Sadece kısalık uğruna okunabilirliği feda etmek bence yanlış yönlendirilmiş.

Okunabilirliği feda edeceğim tek zaman, kodun bir performans darboğazı olduğu ve yeniden yazmanın bunu düzelteceği zaman olacaktı. Bu durumda, kodun amacı iyi belgelenmelidir ki böylelikle bir hata varsa daha kolay takip edilebilir.

Bu, tekrar yazmanın elbette okunamaz olması gerektiği anlamına gelmez.

Daha önce alıntı yaptım ve tekrar alıntı yapacağım:

Doğru yapın,
temizleyin,
kısa olun,
hızlı olun.

Bu sırayla.

Wes Dyer

Kodun okunabilirliğini ne kadar etkili kod ile feda etmeniz gerekir?

Kod açısından, kendi kendini belgelemek her zaman güzeldir. Ama bazen bu olamaz. Bazen optimize etmeniz gerekir ve bazen bu kod kendi içinde okunamaz değildir.

Yorumlar bunun için icat edildi . Onları kullan. Meclisin bile yorumları var. Bir kod kütlesi yazdıysanız ve görünürde bir yorum yoksa, endişeleniyorum. Yorumlar çalışma zamanı performansını etkilemez, ancak neler olup bittiğine dair birkaç not her zaman yardımcı olur.

Aklımda, birkaç temel yorum yapmamak için kesinlikle hiçbir bahane yok. Açıkçası if ( x == 0 ) /* check if x is 0 */tamamen işe yaramaz; Gereksiz gürültüleri koda eklememelisin ama bunun gibi bir şey:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Oldukça yardımcı olur.

Kodun okunabilirliğini ne kadar etkili kod ile feda etmeniz gerekir?

Verimlilik şu andaki amacınızsa (optimizasyon aşamasında olduğu gibi) ve bildiğiniz gibi - ölçütleriniz var değil mi? - kodun bu satırları mevcut tıkanıklık, o zaman evet.

Aksi takdirde, hayır: okunabilirlik sizin (veya başka bir kodun) daha sonra daha verimli hale getirmek için bu kodu daha sonra değiştirebilmenizi sağlar, çünkü anlaşılması daha kolaydır.

Kimse Code Golf'u kazanamaz

Örneğin, 1 satıra 3 satır kod

Özellikle korkunç bir fikir.

Kod golf oynama maliyeti - çok yüksek.

Okunamayan programları koruma maliyeti - astronomik.

Bu tür simge durumuna küçültülmüş kodun değeri - sıfır. Hala çalışıyor, ancak “daha ​​iyi” de çalışmıyor.

Akıllıca Seçilmiş Verimlilik

Doğru algoritmayı ve veri yapısını seçme maliyeti - orta.

Doğru algoritmayı ve veri yapısını koruma maliyeti - düşük.

Doğru algoritma ve veri yapısının değeri - yüksek. Kaynak kullanımı düşük.

Aptal ("mikro-optimizasyon") Verimlilik

Mikro optimizasyonda oynama maliyeti - yüksek.

Okunamayan, mikro için optimize edilmiş kodu sürdürme maliyeti - çok yüksek.

Mikro optimizasyonun değeri - değişir. Burada sıfır olmayan bir değer olduğunda, maliyetler yine de ağır basmaktadır.

Kodun ne kadar hızlı yürüdüğü konusunda verimlilikten mi, geliştiricinin kodu ne kadar hızlı yazabildiğine bağlı olarak mı bağlıyız. Kodun okunabilirliğini çok hızlı bir şekilde yazabilmeniz lehine feda ediyorsanız, kendinizi hata ayıklama açısından yoldan aşağıya doğru geçen zamanı ödeyeceksiniz.

Bununla birlikte, kodun ne kadar hızlı yürüdüğü konusunda kod okunabilirliğinden fedakarlık etmekten bahsediyorsak, kodun verimli bir şekilde önceden oluşturulması gerektiği sürece muhtemelen kabul edilebilir bir işlemdir. Olabildiğince hızlı çalışan bir şeyler yazmak, çünkü performansın anahtar olduğu hızlı ters kare kök gibi bir şey olduğu için bir nedenden neredeyse iyi olamaz . İşin püf noktası, kodu dengelemekle kaynağın okunması zor olsa da, neler olduğunu açıklayan yorumların yapılmasını sağlamak arasında olacak.

Kodu daha hızlı hale getirmesi gereken, ancak kodu daha az okunabilir hale getirme eğiliminde olan birçok püf noktası artık gerekli değildir, çünkü ya derleyiciler çok zekice (çoğu geliştiriciden daha zeki) veya makineler çok saçmadır.

"Performans üzerinden okunabilirlik" argümanını kabul etmiyorum. Size farklı bir dönüş ile bir cevap vereyim.

Bazı geçmiş: Beni hasta eden ne biliyor musunuz? Bilgisayarım'ı çift tıkladığımda ve doldurmak için beklemem gerekiyor. Bu 5 saniyeden uzun sürerse, gerçekten sinirleniyorum. Aptalca şey, ve bunun için sadece Microsoft'u suçlamak değil, bazı durumlarda bu kadar uzun sürmesinin nedeni, hangi simgenin gösterileceğine karar verilmesi gerektiğidir! Doğru. Bu yüzden burada oturuyorum, sadece C: sürücüme gitmekle ilgileniyorum ve sürücünün CD-ROM'uma erişmesini ve oradan simgeyi okumasını beklemeliyim (sürücüde bir CD olduğunu varsayarak).

TAMAM. Bu yüzden sadece bir saniye için, Bilgisayarım üzerine çift tıkladığımda aradaki tüm katmanları hayal edin ve aslında sürücüler aracılığıyla CD-ROM'a aktarıyor. Şimdi her katmanın daha hızlı olduğunu hayal edin ...

Tüm bunların arkasında 1000'lerin mutlu programcıları var, çünkü kodları daha okunaklı. Bu harika. Senin adına sevindim. Ancak kullanıcının bakış açısından sadece berbat (teknik terim). Ve böylece geceleri sesini uyuyarak kendinize kodun daha okunaklı ve daha yavaş olduğundan emin olarak doğru olanı yaptığınızı söyleyin. Olabileceğinden biraz daha yavaş. Ve böylece 1000 geliştirici bunu yapıyor ve sizler için bilgisayarlarımızı bekliyoruz. Bence sen layık değilsin. İlk satırlarınızın en iyisi olması gerektiğini söylemiyorum.

İşte benim yaklaşımım: Öncelikle çalışmasını sağlayın, ardından daha hızlı hale getirin. Her zaman etkili kod yazmayı hedefleyin ve okunabilirliği feda etmek zorunda kalırsanız, yorumları yorumlarla destekleyin. Verimlilikten ödün vermeyeceğim, böylece vasat bir programcının koruyabilmesi için. Ancak kodumu açıklayacağım, ancak bu yeterli değilse, üzgünüm, burada çalışmak için yeterince beceriksizsiniz. Çünkü burada, hızlı ve okunabilir kodlar yazıyoruz ve bir denge olmasına rağmen, okunaksız kodlar verimsizliğin kabul edilemez olduğu halde açıklanabilir.

Ofiste görüşmeler tartışılırken bu soru sıklıkla aklıma geldi. Yıllar önce mezun olarak, “Kodun kendi kendini belgeleme olduğunu mu düşünüyorsunuz?” Sorusu soruldu. Şimdi, bu soruyu bir programcı olarak yanıtlayacaktım ve görüşmeci ilgilendiği sürece siyah beyaz bir soruydu, bu yüzden ortada bir zemin yoktu. Süreç, bireyleri canlı olarak gelip gitmekten daha fazla alacağı ve bireysel olarak en kısa zamanda yeni başlangıçlar hazırlayacağınız için, bireyi geçmeli ve kodun okunması ne kadar kolaysa, neler olduğunu anlamak o kadar hızlı olur.

Bir süre önce oldukça iyi bir kitap okudum, Alan Tahrikli Gelişim: Alan Tahrikli Tasarım: Yazılımın Kalitesinde Karmaşıklık Mücadelesi Kuşkusuz, başlangıçta biraz kuru bir okuma, ancak materyal iyi sunuldu. Bu, kendilerini iyi belgeleyen sistemlere götüren iyi bir yaklaşımı göstermektedir. Dil, çözümünüzü iletme aracıdır, bu nedenle çözüm ne kadar net ifade edilirse, performans sitik bir faktör haline gelirse uyum sağlamak o kadar kolay olur. Bu benim inancım ve benim için iyi çalıştı gibi görünüyor.

Nadiren okunabilirlik pahasına kodun daha hızlı çalışmasını sağlayan ROI buna değer. Modern bilgisayarlar o kadar hızlı çalışıyorlar ki, bunu istediğiniz bir senaryo olacağından şüpheliyim. Bir bilgisayar kodu çalıştırıyorsa, o kodun korunması gerekir.

Bu amaçla, okunabilirliği çok önemli buluyorum. Tabii ki, birçok kez belirtildiği gibi, sadece kodun okunabilir olması zorunlu değil, bunun daha yavaş olduğu anlamına gelmez.

İyi bir örnek değişken adıdır: $a

Nedir $a?? Bu bağlam dışı olduğu için cevaplayamazsınız ama bunu gerçek kodda yaptınız mı? Şimdi birisinin yazdığını varsayın $file_handle- şimdi bu ne? Bağlam dışı bile olduğu açık. Değişken adının uzunluğu, bilgisayar için önemsiz bir fark yaratıyor.

Burada olmamızın sağduyu olduğunu düşünüyorum.

Bazı uygulamalar, herkesin anlayamayacağı bir bit-kayma kestirme emri çıkartabilir, ancak bir noktada azalan getirilerin olduğunu ve bir senaryo bulmanın nadir olduğunu düşünüyorum *.

* Bu endüstri ve diğer şeylere bağlıdır. Buna işletme yazılımı geliştiricisi (İşletme Bilgi Sistemleri) perspektifinden bakıyorum.

Buna başka bir perspektiften bakmak için (ama karmakarışık değil), SAAS yapan bir şirkette çalışıyorum. Bir site kapandığında, onu gerçekten, gerçekten hızlı bir şekilde düzeltmek zorundayız - genellikle başka bir geliştirici kodunu düzeltiyor.

Ben istiyorum çok ziyade birisi çok verimsiz bir şey yapmak ama fantezi ve "hızlı" yapmak için daha okunabilir. Web sunucularımız son teknolojidir ve bir talebin saniyenin milyonda birinde teslim edilmesi gerekmez. Yük sorunumuz yok.

Bu yüzden pratikte, kendinize veya başkalarına zarar verme ihtimalinizin daha yüksek olduğunu düşünüyorum ... (hafta sonumu geri almayı tercih ederim.)

Her durumda, cevabı "Derleyicinize işini yapma konusunda güven" ve okunabilir bir kod yaz. Bu, kodun mantıksal olarak yapılandırılmış (yani, spagetti yok) ve kendi kendini belgeleme (yani, değişkenlerin, fonksiyonların, vb. Adlarının yeterince net bir şekilde belirtildiği) anlamına gelir. Anlamlı yorumlarla kendi kendine belgelenmeyen ek kod. Yorum yapmak uğruna yorum yapma, yani,

x++; // Add one to x

Aksine, okuyucuya, 6 ay veya 12 ay veya yeterince uzun bir süre içerisinde yorum yapın. Bir kodlama standardı kabul edin ve izleyin.

Temiz kod hızlı koddur. Açıkça yazılmış, bakımı kolay kod daha hızlı olma eğilimindedir, çünkü programcının eldeki görevi anladığı ve kodu asıl amacına göre yeniden düzenlediği bir göstergedir.

Ayrıca, modern derleyiciler talimatları çok etkili bir şekilde optimize eder. Bir şeyi yapmak için kaç satır kod yazdığınız ve derleyicinin talimatlar açısından ne oluşturduğu mutlaka ilgili değildir. Neden böyle olduğunu anlamak için derleyicileri okuyun.

Grafik gibi bir performans üzerine çalışırken, küçük optimizasyonların en büyük etkiye sahip olabileceği en derin iç içe algoritmalar üzerinde çalışırken görüntü işleme gibi şeyler yaparken bazen okunabilirliği / bakımları feda edeceğim. Ve o zaman bile, değişikliklerin aslında işleri hızlandırmasını sağlamak için sadece profillemeden sonra yapıyorum . Size kaç kez el ile kodlanmış 'optimizasyonlar' dendiğimi söyleyemem, yalnızca derleyicinin elle yazılan kodu optimize etmesi nedeniyle uygulamayı gerçekten yavaşlattığını bulmak için.

Okunabilirlik, yetersiz ve tembel programcılar için bir bahanedir (aslında aynı şey, berbat bir algoritmayı / tasarımı savunmak için kullanılan bir argüman olarak kullanıldığında "basitlik" için de geçerlidir)!

Verilen her problem için en uygun çözüm için çaba göstermelisiniz! Günümüzde bilgisayarların hızlı olması, CPU çevrimlerini boşa harcamak için bahane değildir. Tek kısıtlama "teslim etme zamanı" olmalı. Buradaki "en uygun çözüm" ün SİZE gelebileceği anlamına gelir (hepimiz en iyi çözümü bulamayız; ya da bunları uygulayacak bilgi / beceriye sahibiz).

Bir başkasının belirttiği gibi, bir çözümün "anlaşılması zor" yanları varsa, yorumlar bunun içindir. Bir başkasının bahsettiği "doğru, okunabilir, hızlı" (veya buna benzer bir şey) emri sadece zaman kaybı.

Orada programcıların olduğuna inanmak için gerçekten zor bir zamanım var, bu da bir sorunla karşılaştığında, satırlarında düşündükleri "... bu şekilde yapılmalı ama daha az verimli fakat daha okunaklı olacak şekilde yapacağım / bakılabilir ve diğer saçmalıklar ... ". Bunun yanlışlığı, bir sonraki geliştiricinin (verimsizlikleri görmek) büyük olasılıkla kodu değiştirmesi ve bir sonraki işlemin aynısı ve benzerleri yapmasıdır ... Sonuç, birkaç versiyondan sonra kodun orjinali haline gelmesidir. geliştirici 1. sırada yazmalıydı. Orijinal geliştiricinin tek bahanesi a. düşünmedi (yeterince adil) ve (daha önce de belirtildiği gibi) b. zaman ve kaynak kısıtlamaları.

Okunabilirliğin azaltılması kod performansına / optimizasyonuna yardımcı olursa ( swfobject ve diğer js kütüphanelerinde olduğu gibi), sadece iyi biçimlendirilmiş ve açıkça okunabilir bir kod yazmaya devam etmek ve onu "derleme" / sürüm sürecinin bir parçası olarak okunamaz / optimize edilmiş hale dönüştürmek için bir nedendir.