Brian Kernighan'ın 'iyi tat' tavsiyesi, okunabilir kodun zaman kazandırdığını, hataları azalttığını ve gerçek ekiplerin zekâsal hilelerden daha hızlı hareket etmesini sağladığını gösterir.
Brian Kernighan’ın adı, birçok geliştiricinin üzerinde düşünmeden kullandığı yerlerde çıkıyor: klasik Unix araçları, C ekosistemi ve programları açıkça anlatmayı öğreten onlarca yıllık yazılar. The C Programming Language (Dennis Ritchie ile), The Unix Programming Environment veya makaleleri ve konuşmaları hatırlansın, ortak tema basit fikirlerin temizce ifade edilmesi.
Kernighan’ın en iyi tavsiyesi C sözdizimine veya Unix geleneklerine bağlı değil. İnsanların nasıl okuduğuyla ilgili: yapıyı tararız, isimlendirmeye dayanırız, niyeti çıkarırız ve kod hilelerin arkasına gizlendiğinde kafamız karışır. Bu yüzden okunabilirlikteki “zevk” TypeScript, Python, Go, Java veya Rust yazarken de önemlidir.
Diller değişir. Araçlar gelişir. Ekipler hâlâ zaman baskısı altında özellik çıkarır ve çoğu kod orijinal yazardan farklı biri tarafından (çoğunlukla gelecekteki siz) korunur. Açıklık, tüm bunları yaşanabilir kılan çarpan niteliğindedir.
Bu bir 'kahraman kodlama' övgüsü ya da eski usul kuralları ezberleme çağrısı değil. Günlük kodu çalışması daha kolay hale getiren alışkanlıklara pratik bir rehber:
Kernighan’ın etkisi önemlidir çünkü basit, takım-dostu bir hedefe işaret eder: iletişim kuran kod yazmak. Kod net bir açıklama gibi okunduğunda, onu çözmeye harcadığınız zaman azalır ve geliştirmeye ayırabileceğiniz zaman artar.
Okunabilir kodda 'iyi zevk', kişisel stil, süslü desenler veya çözümü en az satıra sıkıştırmakla ilgili değil. Niyeti güvenilir şekilde ileten en basit ve açık seçeneği tercih etme alışkanlığıdır.
İyi zevkiye sahip bir çözüm, sonraki okuyucu için temel bir soruyu yanıtlar: Bu kod ne yapmaya çalışıyor ve neden böyle yapıyor? Eğer bu cevap zihinsel jimnastik, gizli varsayımlar veya hileleri çözmeyi gerektiriyorsa, kod takım için zaman kaybettirir.
Çoğu kod yazılmasından çok daha sık okunur. 'İyi zevk' okumayı birincil etkinlik sayar:
Bu yüzden okunabilirlik sadece estetik değildir (girintileme, satır genişliği veya snake_case tercihiniz). Bunlar yardımcıdır, ama 'iyi zevk' esas olarak muhakemeyi kolaylaştırmakla ilgilidir: net isimler, belirgin akış ve öngörülebilir yapı.
Yaygın bir hata, açıklık yerine kısalığı optimize etmektir. Bazen en açık kod biraz daha uzundur çünkü adımları açık eder.
Örneğin, şu iki yaklaşımı karşılaştırın:
İkinci versiyon satır ekleyebilir, ama doğruluğu doğrulamak için gereken bilişsel yükü azaltır. Hataları izole etmeyi ve değişiklikleri daha güvenli uygulamayı kolaylaştırır.
İyi zevk, bir çözümü 'zekileştirerek' geliştirmeyi ne zaman bırakıp niyeti açık etmeyi bileceğinizi bilmektir. Bir takım arkadaşı kodu sizden tur istemeden anlayabiliyorsa, doğru seçimi yapmışsınızdır.
Zeki kod anlık olarak bir kazanç gibi gelebilir: daha az satır, şık bir hile, diff'te "vay" etkisi. Gerçek bir ekipte o zeka tekrarlayan bir fatura haline gelir—onboarding süresi, inceleme süresi ve kod tekrar elle uğraşılacaksa tereddüt şeklinde ödenir.
Onboarding yavaşlar. Yeni takım arkadaşları sadece ürünü öğrenmekle kalmaz; ayrıca sizin özel kısaltma dilinizi de öğrenmek zorunda kalır. Bir fonksiyonu anlamak gizli operatörlerin veya örtük kuralların çözümünü gerektiriyorsa, insanlar onu değiştirmekten kaçınır ya da korkuyla değiştirir.
İncelemeler uzar ve daha az güvenilir olur. İnceleyenler, hilenin doğru olduğunu kanıtlamaya enerji harcarlar; davranışın niyete uyup uymadığını değerlendirmeye değil. Daha kötü: zeki kod zihinsel olarak simüle etmesi zor olduğundan, incelemeler basit versiyonda yakalanabilecek kenar durumları kaçırır.
Zekilik şu durumlarda çoğalır:
Bazı tekrar eden suçlular:
17, 0.618, -1) kuralları kodun içine gömer.&& / || kısayolları) okuyucunun ince değerlendirme kurallarını bilmesini gerektirir.Kernighan'ın 'zevk' üzerine vurgusu burada kendini gösterir: açıklık daha fazla yazmak değil, niyeti bariz kılmaktır. Eğer 'akıllı' bir versiyon bugün 20 saniye kazandırıyor ama gelecekteki her okuyucu için 20 dakika maliyeti varsa, bu akıllıca değil—masraflıdır.
Kernighan'ın 'zevki' çoğunlukla küçük, tekrarlanabilir kararlarda görünür. Kodu daha yaşanabilir kılmak için büyük bir yeniden yazıma gerek yok—küçük açıklık kazanımları bir dosyayı tararken, bir davranışı ararken veya zaman baskısı altında bir hatayı düzeltirken her seferinde toplanır.
İyi bir isim yorum gereksinimini azaltır ve hataları saklamayı zorlaştırır.
Amaç niyetini belli eden isimleri hedefleyin; takımınızın konuştuğu dille eşleşsin:
sum yerine invoiceTotalCents tercih edin.Bir isim sizi çözmeye zorluyorsa, işini yapmıyor demektir.
Okumanın çoğu taramadır. Tutarlı boşluk ve yapı gözün önemli noktaları bulmasına yardım eder: fonksiyon sınırları, koşullar ve 'mutlu yol'.
Birkaç pratik alışkanlık:
Mantık karıştığında, kararları açık hale getirmek genellikle okunabilirliği artırır.
Şu iki stili karşılaştırın:
// Harder to scan
if (user && user.active && !user.isBanned && (role === 'admin' || role === 'owner')) {
allow();
}
// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' && role !== 'owner') return deny('insufficient role');
allow();
İkinci versiyon daha uzundur, ama bir kontrol listesi gibi okunur—ve genişletmesi daha kolaydır. Bu 'küçük' seçimler günlük sürdürülebilir kod işidir: doğru kalan isimler, okuyucuyu yönlendiren biçimlendirme ve zihinsel jimnastik yaptırmayan kontrol akışı.
Kernighan'ın açıklık tarzı en çok işleri fonksiyon ve modüllere nasıl böldüğünüzde görülür. Okuyucu yapıyı tarayabilmeli, her parçanın ne yaptığını tahmin edebilmeli ve detayları okumadan önce büyük ölçüde haklı olmalıdır.
Her fonksiyonun tek bir işi, tek bir 'zoom seviyesi' olmasına çalışın. Bir fonksiyon doğrulama, iş kuralları, biçimlendirme ve I/O'yu karıştırdığında okuyucunun birden çok ipucunu aynı anda takip etmesi gerekir.
Hızlı bir test: bir fonksiyon içinde "// şimdi X yap" gibi yorumlar yazıyorsanız, X genellikle açık bir adı olan ayrı bir fonksiyon için iyi bir adaydır.
Uzun parametre listeleri gizli bir karmaşıklık vergisidir: her çağrı yeri mini bir yapılandırma dosyası haline gelir.
Birden fazla parametre her zaman birlikte gidiyorsa, onları düşünceli şekilde gruplayın. Seçenek nesneleri (veya küçük veri yapıları) çağrı yerlerini kendiliğinden açıklayıcı yapabilir—tabii grubu tutarlı tutarsanız ve her şeyi 'misc' çantasına atmazsanız.
Ayrıca, ilke olarak domain kavramlarını ilkel tipler yerine geçirmek iyi bir tercihdir. UserId string'den, DateRange (start, end)'den daha açıktırsa tercih edin.
Modüller birer vaat gibidir: 'Bu kavram için ihtiyacınız olan her şey burada, geri kalanı başka yerde.' Modülleri kafanızda tutabileceğiniz kadar küçük tutun ve yan etkileri en aza indirecek sınırlar tasarlayın.
Yardımcı pratikler:
Paylaşılan durum gerektiğinde, ona dürüstçe isim verin ve invariant'ları belgeleyin. Açıklık karmaşıklıktan kaçınmak değil—karmaşıklığı okuyucunun beklediği yere koymaktır. Değişiklikler sırasında bu sınırları korumaya dair daha fazlası için bkz. /blog/refactoring-as-a-habit.
Kernighan'ın 'zevki' yorum yapma biçiminizde de görünür: amaç her satırı not etmek değil, gelecekteki kafa karışıklığını önlemektir. En iyi yorum, kod doğru ama şaşırtıcı olduğunda yanlış varsayımları önleyen bilgidir.
Kodu tekrar eden bir yorum ('i'yi artır) sadece karışıklık katar ve yorumların göz ardı edilmesine yol açar. Faydalı yorumlar niyeti, tavizleri veya sözdiziminden açık olmayan kısıtları açıklar.
# Bad: says what the code already says
retry_count += 1
# Good: explains why the retry is bounded
retry_count += 1 # Avoids throttling bans on repeated failures
Eğer 'ne' yorumlama isteği hissediyorsanız, bu genellikle kodun daha net olması gerektiğinin işaretidir (daha iyi isimler, daha küçük fonksiyon, daha basit akış). Gerçekleri koda bırakın; gerekçeleri yorumlara yazın.
Yanlış bir yorum güveni en hızlı şekilde zedeler. Bir yorum isteğe bağlıysa zamanla kayma eğilimindedir; yanlışsa aktif bir hata kaynağı olur.
Pratik bir alışkanlık: yorum güncellemelerini değişikliğin bir parçası sayın. İncelemelerde şu soruyu sormak makuldür: 'Bu yorum hâlâ davranışla uyuşuyor mu?' Uymuyorsa güncelleyin veya kaldırın. 'Yorum yok' yanlış yorumdan iyidir.
Satır içi yorumlar yerel sürprizler içindir. Daha geniş rehberlik docstring'lerde, README'lerde veya geliştirici notlarında olmalıdır—özellikle:
İyi bir docstring birine fonksiyonun nasıl doğru kullanılacağını ve hangi hataların beklenebileceğini söyler; uygulamayı anlatmaz. Kısa bir /docs veya /README notu 'neden böyle yaptık' hikâyesini yakalayabilir ve refaktörler sırasında hayatta kalır. Böylece daha az yorum olur ama her biri yerini hak eder.
Çoğu kod mutlu yol üzerinde 'tamam' görünür. Tadın gerçek testi, girdiler eksik olduğunda, servisler zaman aşımına uğradığında veya kullanıcı beklenmedik bir şey yaptığında ortaya çıkar. Baskı altında zeki kod gerçeği gizleme eğilimindedir. Açık kod hatayı görünür ve kurtarılabilir kılar.
Hata mesajları ürününüzün ve hata ayıklama iş akışınızın bir parçasıdır. Mesajları, onları okuyacak kişinin yorgun ve nöbette olduğunu varsayar gibi yazın.
Şunları içermeli:
Eğer loglama varsa, requestId, userId veya invoiceId gibi yapılandırılmış bağlam ekleyin ki mesaj eyleme geçirilebilir olsun.
Her şeyi tek bir hileyle veya genel bir catch-all ile çözme cazibesi vardır. İyi zevk, önemli birkaç kenar durumunu seçmek ve onları görünür kılmaktır.
Örneğin, 'boş giriş' veya 'bulunamadı' için açık bir dal genellikle dönüş zinciri içinde bir yerde örtük olarak null üreten bir dizi dönüşten daha iyi okunur. Özel durum önemliyse adını koyun ve öne alın.
Geri dönüş biçimlerini karıştırmak (bazen obje, bazen string, bazen false) okuyucuyu zihinsel bir karar ağacı tutmaya zorlar. Tutarlılığı tercih edin:
Açık hata işleme sürprizi azaltır—ve sürprizler hataların ve gece aramalarının kaynağıdır.
Açıklık yalnızca sizin ne demek istediğinizle ilgili değildir. Aynı dosyayı 16:55'te açan birinin ne görmeyi beklediğiyle ilgilidir. Tutarlılık kod okumayı örüntü tanımaya çevirir—daha az sürpriz, daha az yanlış anlama, daha az tekrar eden tartışma.
İyi bir takım stil rehberi kısa, spesifik ve pragmatiktir. Her tercihi kodlamaz; tekrar eden soruları çözer: isimlendirme, dosya yapısı, hata işleme desenleri ve testler için 'bitti' tanımı.
Gerçek değer sosyal olandır: aynı tartışmanın her yeni pull request'te yeniden başlamasını önler. Yazılı olduğunda, incelemeler 'ben X tercih ederim' yerine 'biz X üzerinde anlaştık (ve nedeni bu)' olur. Rehberi yaşayan tutun ve kodun yanına yerleştirin—örneğin /docs/style-guide.md.
Ölçülebilir ve sıkıcı kurallar için formatter'lar ve linter'lar kullanın:
Bu, insanların anlam üzerine odaklanmasını sağlar: isimlendirme, API şekli, kenar durumlar ve kodun niyete uyup uymadığı gibi.
Manuel kurallar tasarım seçimlerini tanımladığında hâlâ önemlidir—ör. 'İç içeliği azaltmak için erken dönüşleri tercih et' veya 'modül başına tek bir genel giriş noktası.' Araçlar bunları tam olarak değerlendiremez.
Bazen karmaşıklık haklıdır: sıkı performans gereksinimleri, gömülü kısıtlar, zor eşzamanlılık veya platforma özgü davranış. Anlaşma şu olmalı: istisnalara izin verilir, ama açık olmalıdır.
Basit bir standart yardımcı olur: takas kararını kısa bir yorumla belgeleyin, performans iddiası varsa mikro-ölçüm veya karşılaştırma ekleyin ve karmaşık kodu temiz bir arayüzün arkasına izole edin ki kod tabanının çoğu okunaklı kalsın.
İyi bir kod incelemesi denetim yerine kısa, odaklı bir 'iyi zevk' dersine benzemeli. Kernighan’ın noktası zekice kodun kötü olduğu değil—zekânın maliyetli olduğu zamanlarda takımın onunla yaşamak zorunda kalmasıdır. İncelemeler bu takası görünür kılar ve kasıtlı olarak açıklığı seçmeye yardımcı olur.
Şunu sorun: 'Bir takım arkadaşı bunu bir kerede anlayabilir mi?' Bu genellikle isimlendirme, yapı, testler ve davranışa bakmak demektir; mikro-optimizasyonlara dalmadan önce bunları kontrol edin.
Kod doğruysa ama okunması zorsa, okunabilirliği gerçek bir kusur olarak ele alın. Değişken isimlerini niyeti yansıtacak şekilde yeniden adlandırmayı, uzun fonksiyonları bölmeyi, kontrol akışını basitleştirmeyi veya beklenen davranışı gösteren küçük bir test eklemeyi önerin. 'Çalışıyor ama nedenini anlayamıyorum' diyen bir inceleme haftalarca sürebilecek karışıklıkları önler.
Uygulanan yararlı bir sıralama:
Geri bildirim puan kazanma şeklinde sunulduğunda incelemeler tersine döner. 'Bunu neden yaptın?' yerine deneyin:
Sorular işbirliğini davet eder ve genellikle sizin bilmediğiniz kısıtları ortaya çıkarır. Öneriler ise yön gösterir ama yoksayma hissi vermez. Bu ton 'zevkin' ekip içinde yayılmasını sağlar.
Tutarlı okunabilirlik istiyorsanız inceleyici moduna bağlı kalmayın. İnceleme şablonunuza ve 'done' tanımınıza birkaç 'açıklık kontrolü' ekleyin. Kısa ve spesifik tutun:
Zamanla bu, incelemeleri stil polisliği olmaktan çıkarıp yargı öğretimine dönüştürür—Kernighan'ın günlük disiplin çağrısına denk bir yaklaşım.
LLM araçları çalışan kodu hızlı üretebilir, ama Kernighan'ın işaret ettiği çıta 'çalışıyor' değil; 'iletişim kuruyor' olmalıdır. Eğer takımınız sohbetle üretim odaklı bir iş akışı kullanıyorsa (ör. chat üzerinden özellik oluşturup üretilen kodu yineleyerek), okunabilirliği birinci sınıf kabul kriteri olarak ele alın.
Koder.ai gibi platformlarda React frontend, Go backend ve Flutter mobil uygulamaları sohbet isteminden üretebiliyorsanız, aynı zevki gerektiren alışkanlıklar geçerlidir:
Hız, çıktının insanlar tarafından incelenebilir, sürdürülebilir ve genişletilebilir olması halinde en değerlidir.
Açıklık bir kez elde edilip bırakılacak bir şey değildir. Gereksinimler değiştikçe kodu açık konuşmaya geri itmek gerekir. Kernighan’ın yaklaşımı burada devreye girer: kahramanca yeniden yazılar veya bugünkü izlenim yaratan 'zeki' tek satırlar yerine, anlaşılır iyileştirmeleri tercih edin.
En güvenli refaktör sıkıcı olandır: davranışı aynı tutan küçük değişiklikler. Her adımda testleri çalıştırın. Test yoksa, dokunuğunuz alan etrafına birkaç odaklanmış kontrol ekleyin—bunları geçici gardiyanlar gibi düşünün ki yapıyı korkmadan iyileştirebilesiniz.
Pratik bir ritim:
Küçük commit'ler incelemeyi kolaylaştırır: takım arkadaşları niyeti değerlendirebilir, yan etkileri aramaya gerek kalmaz.
Her 'zeki' yapıyı tek seferde temizlemek zorunda değilsiniz. Özellikle bir alana özellik veya hata düzeltme için dokunduğunuzda, kestirme çözümleri daha anlaşılır eşdeğerlerle değiştirin:
İşte gerçek ekiplerde açıklığın kazanması: çalışılan sıcak noktalarda yapılan her iyileştirme.
Her temizlik acil değildir. Kullanışlı bir kural: kod aktif olarak değişiyorsa, sıkça yanlış anlaşılıyorsa veya hata yaratma olasılığı yüksekse şimdi refaktör edin. Stabil ve izoleyse sonraya planlayın.
Refaktör borcunu görünür kılın: kısa bir TODO bırakın ve bağlam verin veya sorunu tarif eden bir ticket ekleyin ('yeni ödeme yöntemleri eklemeyi zorlaştırıyor; fonksiyon 5 iş yapıyor' gibi). Böylece kafa karışıklığı sessizce kalıcı bir vergiye dönüşmek yerine kasıtlı bir karara bağlanır.
'İyi zevkin' tutarlı görünmesini istiyorsanız, uygulanması kolay hale getirin. İşte planlama, kodlama ve incelemede tekrar kullanılabilecek hafif bir kontrol listesi—hatırlaması kolay, uygulaması somut.
Önce: process(data) doğrulama, parsing, kaydetme ve loglama yapıyor.
Sonra: validateInput, parseOrder, saveOrder, logResult olarak bölün. Ana fonksiyon okunabilir bir taslak haline gelir.
Önce: if not valid then return false beş yerde tekrar ediyor.
Sonra: Öndeki bir koruma bölümü (veya bir doğrulama fonksiyonu) tek bir açık sorun listesi döndürüyor.
Önce: x, tmp, flag2, doThing() gibi isimler.
Sonra: retryCount, draftInvoice, isEligibleForRefund, sendReminderEmail() gibi niyeti açıklayan isimler.
Önce: Döngü içinde üç özel durum ortada gizlenmiş.
Sonra: Özel durumları önce ele alın (veya yardımcılar çıkarın), sonra düz döngüyü çalıştırın.
Bu hafta benimsenmesi için bir iyileştirme seçin: "yeni kısaltma yok", "önce mutlu yol", "her PR'da bir yardımcı çıkarın" veya "her hata mesajı bir sonraki adımı içerir." Yedi gün boyunca takip edin, sonra okumayı gerçekten kolaylaştıranı koruyun.
Kernighan'ın etkisi C'den ziyade kalıcı bir ilkeye dayanır: kod iletişim aracıdır.
Diller ve çerçeveler değişir, ama ekiplerin kodu taraması, üzerinde mantık kurması, incelemesi ve hata ayıklaması hâlâ gereklidir—özellikle aylar sonra veya baskı altında çalışırken.
“İyi tat” niyeti iletişimsel olarak açık kılan en basit çözümü sürekli seçmek demektir.
Kullanışlı bir test: Bir takım arkadaşınız 'bu ne yapıyor ve neden böyle yapıldı' sorusuna, hileleri çözmeye gerek kalmadan cevap verebiliyor mu?
Çünkü çoğu kod yazılmaktan daha sık okunur.
Okuyucuları önceliklendirmek onboarding süresini, inceleme sürtüşmesini ve yanlış değişiklik riskini azaltır—özellikle bakım yapan 'gelecekteki siz' daha az bağlama sahipse.
“Zekâ vergisi” şu şekilde görünür:
Eğer zeki versiyon bugün saniyeler kazandırıyor ama her dokunuşta dakikalar kaybettiriyorsa, bu net zarar olur.
Sık rastlanan zarar vericiler:
Bu kalıplar ara durumları saklama eğilimindedir ve incelemede kenar durumların kaçmasına yol açar.
Zihinsel yükü azalttığında.
Adımları adlandırılmış değişkenlerle (ör. doğrula → normalleştir → hesapla) açık hale getirmek, doğruluğu doğrulamayı, hata ayıklamayı ve gelecekteki değişiklikleri güvenli hale getirmeyi kolaylaştırır—birkaç satır eklese bile.
Şunları hedefleyin:
Bir ismi çözmeniz gerekiyorsa, o isim işini yapmıyor demektir; isim ekstra yorum ihtiyacını azaltmalı.
Basit, açık dallanmayı tercih edin ve 'mutlu yolu' görünür tutun.
Yardımcı taktikler:
Niyeti açıklayın, kodun ne yaptığını tekrarlamayın.
İyi yorumlar niyet, alınan tavizler veya gözlemlenmeyen sabitleri açıklar. Barışık yorumlar zamanla bozulur; yorum güncellemelerini değişikliğin bir parçası olarak ele alın—yanlış yorum sıfır yorumdan daha kötüdür.
Mekanik kurallar için araçları (formatter, linter) kullanın; anlam için insan incelemesini saklayın.
Kısa, pratik bir stil rehberi devam eden kararları (isimlendirme, dosya yapısı, hata işleme) sabitleyerek tartışmaları tekrar tekrar yaşamaktan kurtarır. Performans veya kısıtlar için yapılan istisnalar belgelenmeli ve karmaşıklık temiz bir arayüzün arkasına izole edilmelidir.