Kodun ne kadar verimli olduğu ile kod okunabilirliğinden ödün vermeli misiniz?
örneğin. 1 satırda 3 satır kod.
Ben Kod Craft Pete Goodliffe tarafından okunabilirlik önemli olduğunu okudum.
Senin düşüncelerin?
"Daha az satır" her zaman "daha verimli" ile aynı şey değildir. "Bir program okunabilirlik pahasına kısaltılmalı mı?".
Programların insanların okuyabilmesi ve sadece makinelerin çalışması için yazılması gerekir.
- Abelson & Sussman, Bilgisayar Programlarının Yapısı ve Yorumlanması
Genel olarak, bir programın kısa olması yerine kolayca anlaşılabilmesinin daha önemli olduğunu düşünüyorum. Yine de, bir programı daha kısa yapmak daha da okunabilir hale getirir (kodunuzun hat gürültüsü gibi görünmeye başladığında elde ettiğiniz bariz eşik var, ancak o noktaya kadar, daha özlü bir şekilde ifade etmek daha net görünüyor).
Hiç kimsenin sürdürmesi gerekmeyecek ve yalnızca okumanız gereken özel istisnalar vardır (kişisel Shell komut dosyalarınız veya bir veri ayıklama kodu gibi). Bu durumda, yine de anlayabildiğiniz sürece, uygunluk için bazı okunabilirlikten ödün vermeniz yerinde olur.
Bazen, evet.
Okunabilirlik için çabalamak iyi bir şeydir. Tipik iş kolu uygulamaları için yazılan kodların çoğu yeterince performans gösterir ve okunabilirliğe odaklanmak önemlidir. Daha fazla performans gerektiren alanlarda (video oyunu programlama veya ağır hesaplama gibi), okunamayan ve inanılmaz derecede performans gösteren belirli bir dil özelliğini kullanmak için okunabilirlikten vazgeçmek önemli olabilir.
İkincisinin bir örneği için Wikipedia'daki Hızlı Ters Kare Kök makalesine bakın.
Genellikle ilk önce okunabilir bir şey yapmanın ve sonra performans hakkında endişelenmenin daha iyi olduğunu düşünüyorum, O(n)) üzerinde bir O (n ^ 2) algoritması seçmemek gibi sağduyu önlemleri alındığında. sadece kısalık uğruna okunabilirlik, bence yanlış yönlendirilmiş.
Okunabilirliği feda edebileceğim tek zaman, kodun bir performans darboğazı olduğu gösterildi ve bir yeniden yazma bunu düzeltirdi. Bu durumda, kodun niyeti iyi bir şekilde belgelenmelidir, böylece bir hata varsa daha kolay izlenebilir.
Bu, yeniden yazmanın elbette okunamaz olması gerektiği anlamına gelmez.
Kodun ne kadar verimli olduğu konusunda kod okunabilirliğinden ödün vermeli misiniz?
Kod açısından, kendini belgelemek her zaman güzeldir. Ama bazen bu olamaz. Bazen optimize etmeniz gerekir ve bazen bu kod kendi içinde çok okunabilir olmayabilir.
Yorumlar bunun için icat edildi. Onları kullan. Meclisin bile yorumları var. Çok sayıda kod yazdıysanız ve görüşte bir yorum yoksa, endişeliyim. Yorumlar, çalışma süresi performansını etkilemez, ancak neler olduğuna dair birkaç not her zaman yardımcı olur.
Zihnimde, birkaç temel yoruma sahip olmamak için hiçbir mazeret yoktur. Açıkça
if ( x == 0 ) /* check if x is 0 */ tamamen işe yaramaz; kodlara gereksiz gürültü eklememelisiniz, ancak bunun gibi bir şey yapmalısınız:
; 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 ne kadar verimli olduğu konusunda kod okunabilirliğinden ödün vermeli misiniz?
Verimlilik mevcut hedefinizse (optimizasyon aşamasında olduğu gibi) ve bilirsiniz - ölçümleriniz var, değil mi? - bu kod satırları mevcut darboğazdır, o zaman evet.
Aksi takdirde, hayır: okunabilirlik, sizin (veya başka bir kodun) daha kolay anlaşılması için bu kodu daha verimli hale getirmek için daha sonra değiştirmenize izin vermez.
Hiç kimse Code Golf'ü kazanmaz
örneğin. 1 satıra 3 satır kod
Özellikle korkunç bir fikir.
Kod golf oynamak için maliyet - çok yüksek.
Okunamayan programları sürdürme maliyeti - astronomik.
Bu tür minimize edilmiş kodun değeri - sıfır. Hala çalışıyor, ama daha iyi değil.
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 algoritmanın ve veri yapısının değeri - yüksek. Kaynak kullanımı düşük.
Aptalca ("mikro optimizasyon") Verimlilik
Mikro optimizasyonda oynama maliyeti - yüksek.
Okunamayan, mikro optimize edilmiş kodu koruma 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 basar.
"Performans üzerinden okunabilirlik" argümanını kabul etmiyorum. Size farklı bir dönüşle cevap vereyim.
Bazı bilgiler: Beni neyin hasta ettiğini biliyor musun? Bilgisayarım'a çift tıkladığımda ve aslında doldurulmasını beklemek zorunda kaldığımda. Bu 5 saniyeden uzun sürerse, gerçekten sinirli olurum. Aptalca bir şey ve sadece bunun için Microsoft'u suçlamayın, bazı durumlarda bu kadar uzun sürmesinin nedeni, hangi simgenin gösterileceği konusunda bir karar verilmesi gerektiğidir! Doğru. 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ı beklemek zorundayım (sürücüde bir CD olduğu varsayılarak).
TAMAM. Sadece bir saniye için bilgisayarımın üzerine çift tıklayarak aramdaki tüm katmanları hayal edin ve aslında sürücüler aracılığıyla CD-ROM'a konuşuyor. Şimdi her katmanın daha hızlı olduğunu düşünün ...
Görüyorsunuz, tüm bunların arkasında 1000'ler mutlu programcılar var çünkü kodları "daha okunabilir". Bu harika. Senin adına sevindim. Ancak kullanıcının bakış açısından sadece berbat (teknik terim). Ve böylece geceleri ses uyurken, kodun daha okunabilir ve daha yavaş olduğundan emin olarak doğru şeyi yaptığınızı söylüyorsunuz. Olabileceğinden biraz daha yavaş. Ve böylece 1000'lerce geliştirici bunu yapıyor ve sonunda sizler için bilgisayarlarımızı bekliyoruz. Bence layık değilsiniz. İlk satırlarınızın en iyisi olması gerektiğini söylemiyorum.
İşte yaklaşımım: Önce, daha sonra çalışmasını sağlayın, sonra daha hızlı yapın.Her zaman etkin kod yazmayı hedefleyin ve okunabilirliği feda etmeniz gerekiyorsa, yorumlarla tamamlayın. Bazı vasat programcıların bunu sürdürebilmesi için verimliliği feda etmeyeceğim. Ancak kodumu açıklayacağım, ama bu yeterli değilse, üzgünüm, burada çalışmak için sadece yetersiz. Çünkü burada hızlı ve okunabilir kod yazıyoruz ve bir denge olmasına rağmen okunabilir kod açıklanabilirken verimsizlik kabul edilemez.
Kodun ne kadar hızlı yürütüldüğünden ya da geliştiricinin kodu ne kadar hızlı yazabileceğinden verimlilikten söz edip etmememize bağlıdır. Kodu çok hızlı yazabilmek için kodun okunabilirliğini feda ediyorsanız, hata ayıklama açısından kendinizi yoldan geri ödeyerek zaman ayırdığınızı düşünebilirsiniz.
Bununla birlikte, kodun ne kadar hızlı yürütüldüğüne göre kod okunabilirliğinden ödün vermekten bahsediyorsak, kodun verimli bir şekilde oluşturulması gerektiği sürece kabul edilebilir bir değiş tokuş olabilir. Mümkün olduğu kadar hızlı çalışan bir şey yazmak, neredeyse performansın anahtar olduğu hızlı ters kare kök gibi bir nedenden dolayı iyi değildir. İşin püf noktası, kodun dengelenmesi ile kaynağın okunması zor olsa da, ne yaptığını açıklayan yorumların neler olduğunu açıklamaktan emin olmak olacaktır.
Bu soru, görüşmeler ofiste tartışıldığında sık sık aklıma geldi. Yıllar önce mezun olarak bana "Kodun kendini belgelediğini mi düşünüyorsun?" Şimdi, bu soruyu bir programcı olarak cevaplayacaktım ve görüşmeci ile ilgili olarak, bu siyah ve beyaz bir soruydu, bu yüzden orta bir zemin yoktu. Süreç, insanlar gelip gittiklerinden daha fazla geleceğinden ve mümkün olan en kısa sürede yeni başlangıçlara hazırlanmak istediğinizden ve bireysel olarak daha kolay bir şekilde okunmalıdır ve kod ne kadar kolay okunursa, neler olduğunu daha hızlı kavramaktır.
Bir süre önce Domain Driven Development adlı oldukça iyi bir kitap okudum: Etki Alanına Dayalı Tasarım: Yazılımın Kalbinde Karmaşıklıkla Mücadele Kuşkusuz, başlangıçta biraz kuru bir okuma ama malzeme iyi sunuldu. Bu, kendilerini iyi belgeleyen sistemlere yol açan iyi bir yaklaşım göstermektedir. Dil, çözümünüzü iletmek için kullanılan ortamdır, bu nedenle çözüm ne kadar net ifade edilirse, performans sitical 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.
Kodları daha hızlı hale getirmesi beklenen, ancak kodu daha az okunabilir hale getirme eğiliminde olan birçok hile artık gerekli değildir, çünkü derleyiciler çok zeki (çoğu geliştiriciden daha akıllı) = veya makineler gülünç hale geldi .
Kodun okunabilirlik pahasına daha hızlı çalışmasını sağlamadaki yatırım getirisi buna değecektir. Modern bilgisayarlar o kadar hızlı çalışır ki, bunu isteyeceğiniz bir senaryo olacağından şüpheliyim. Bir bilgisayar kodu çalıştırıyorsa, bu kodun korunması gerekir.
Bu amaçla okunabilirliği çok önemli buluyorum. Tabii ki, birçok kez belirtildiği gibi, kodun okunabilir olması gerekli olmadığı anlamına gelir.
İyi bir örnek değişken adıdır:
$a
Nedir
$a ?? Bu bağlam dışıdır, bu yüzden cevap veremezsiniz, ancak bunu gerçek kodda hiç çalıştırdınız mı? Şimdi birisinin
$file_handle - şimdi bu nedir? Bağlam dışında bile net. Değişken adının uzunluğu bilgisayar için önemsiz bir fark yaratır.
Bence burada sağduyu var.
Bazı uygulamalar, herkesin anlayamayacağı bir bit-shift kısa yolunu garanti edebilir, ancak bir noktada geri dönüşlerin azaldığını ve bir senaryo bulmanın nadir olduğunu düşünüyorum *.
* Bu endüstriye ve benzeri şeylere bağlıdır. Buna iş yazılımı geliştiricisi (Business Information Systems) açısından bakıyorum.
Buna başka bir perspektiften bakmak için (ama çarpışma değil), SAAS yapan bir şirkette çalışıyorum. Bir site çöktüğünde, siteyi gerçekten çok hızlı bir şekilde düzeltmemiz gerekir; genellikle bir başkası başka bir geliştiricinin kodunu düzeltmektedir.
Ben çok yerine birisi çok verimli ama "hızlı" yapmak daha okunabilir bir şey yapmak. Web sunucularımız Edge'i kesiyor ve bir isteğin saniyenin milyonda birinde sunulmasına gerek yok. Yük sorunumuz yok.
Yani, pratikte kendinize veya başkalarına zarar verme olasılığınızın daha yüksek olduğunu düşünüyorum ... (haftasonumu geri almayı tercih ederim.)
Çoğu durumda, cevap "derleyicinizin işini yapmasına güvenin" ve okunabilir kod yazmaktır. Bu, kodun mantıksal olarak yapılandırılmış (yani spagetti yok) ve kendi kendini belgelendirdiğini (yani, değişkenlerin, işlevlerin adlarının yeterince açık olduğunu) belirtir. Anlamlı yorumlarla kendi kendini belgelemeyen ek kod. Yorum yapmak için yorum yapma, yani,
x++; // Add one to x
Aksine, okuyucuya, 6 ay veya 12 ay veya yeterince uzun bir süre içinde yorum yapın. Bir kodlama standardı benimseyin ve uygulayın.
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ığını ve kodu temel amacına kadar yeniden düzenlediğini gösterir.
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 ille de ilişkili olmayabilir. Neden böyle olduğunu anlamak için derleyicileri okuyun.
Grafik gibi performansa dayalı bir şey üzerinde çalışırken, küçük optimizasyonların önemli bir etkisi olabileceği en derin iç içe algoritmalar üzerinde çalışırken görüntü işleme gibi şeyler yaparken bazen okunabilirliği/sürdürülebilirliği feda edeceğim. Ve o zaman bile sadece değişiklikleri sağlamak için profillemeden sonra bunu yapıyorum aslında işleri hızlandırın. Ben sadece derleyici el tipi kodu optimize yolu nedeniyle uygulamayı yavaşlattı bulmak için el kodlu 'optimizasyon' kaç kez denedim söyleyemem.