Kodunuzu Daha Okunabilir ve Bakımı Kolay Hale Getirmenin 5 Temel İlkesi ✨

Kodunuzu Daha Okunabilir ve Bakımı Kolay Hale Getirmenin 5 Temel İlkesi

Selam dostlar! Bugün, kod yazarken hepimizin zaman zaman göz ardı ettiği ama aslında en kritik konulardan birine değineceğiz: kod okunabilirliği ve bakım kolaylığı.

Şunu kabul edelim: Yazdığımız kodun ilk ve en önemli okuyucusu, 6 ay sonraki biziz. O "biz", o kodu hatırlamıyor olacak. Ya da daha kötüsü, o kodu okuyan bir meslektaşımız olacak. İşte bu noktada, sadece çalışan değil, aynı zamanda anlaşılır ve değiştirilebilir kod yazmak, bir lüks değil, bir zorunluluk haline geliyor.

Hadi gelin, projelerinizi geleceğe taşıyacak 5 temel ilkeyi birlikte inceleyelim.

1. Anlamlı İsimlendirme: Değişken ve Fonksiyonlarınıza İsim Koyun, Etiket Değil!

Kodun ilk izlenimi isimlerden gelir. `a`, `b`, `temp` gibi isimler, kodun amacını anlamak için bir bilmeceye dönüşür.

• Ne yapıyorsa onu söylesin: `d` yerine `elapsedDays`, `fn` yerine `calculateDiscount` kullanın.
• Kısaltmalardan kaçının: `custAddr` yerine `customerAddress` çok daha nettir.
• Boolean değişkenler soru sorar gibi olsun: `flag` yerine `isActive`, `hasPermission` gibi.

2. Fonksiyonlar Tek Bir İş Yapsın (Single Responsibility Principle)

Bir fonksiyonun yapması gereken bir ve sadece bir şey olmalı. Karmaşık, "her şeyi yapan" fonksiyonlar hata ayıklamayı ve test etmeyi kabusa çevirir.

Örneğin, bir "kullanıcı kaydet" fonksiyonu şunları yapmamalı:

• Veritabanı bağlantısı kurmak
• E-posta göndermek
• Log dosyası yazmak

Bunun yerine, bu işleri küçük, tek sorumluluklu fonksiyonlara bölün ve ana fonksiyonunuz onları yönetsin.

3. Yorum Satırları "Neden"i Açıklasın, "Ne"yi Değil

Kötü kod yorumla düzeltilmez. Zaten kendini açıklayan kod yazmaya çalışın. Yorum satırları, kodun *neden* o şekilde yazıldığını açıklamalı.


4. Kodunuzu Düzenleyin: Girintileme ve Boşluklar

Gözünüzün kodda rahat gezinebilmesi için boşlukları ve girintileri doğru kullanın. İlgili kod bloklarını bir arada tutun, farklı işlevleri olan bloklar arasında bir satır boşluk bırakın. Bu, sayfayı taramayı inanılmaz kolaylaştırır.

5. Büyük Dosyalardan ve Uzun Fonksiyonlardan Korkun!

Ekranı aşan, kaydırma çubuğuyla gezilen bir fonksiyon veya binlerce satırlık bir dosya, genellikle bir "koku"dur (code smell). Eğer bir fonksiyon veya sınıf çok büyüyorsa, muhtemelen birden fazla sorumluluğu vardır ve parçalanmayı hak ediyordur.

• Bir fonksiyon genelde bir ekranı (25-30 satır) geçmemelidir.
• Benzer işlevleri olan kodları aynı modül veya dosyada gruplayın.

**Son Söz**
Bu ilkeler sihirli değnek değil, bir alışkanlıklar bütünüdür. İlk başta ekstra efor gerektirebilir, ancak zamanla otomatikleşir. Unutmayın, yazılımın ömrü boyunca okunma ve değiştirilme maliyeti, yazılma maliyetinden çok daha yüksektir. Bugün bu ilkelere zaman ayırmak, yarın size ve ekibinize çok daha fazla zaman kazandıracaktır.

Peki ya siz? Kod okunabilirliğini artırmak için hangi yöntemleri kullanıyorsunuz? Takıldığınız örnekler var mı? Yorumlarda tartışalım!

Bu ilkelerin hepsi temiz kod yazmanın omurgası gibi. Özellikle isimlendirme ve tek sorumluluk ilkesi, kodun felsefesini oluşturuyor bence. Bir değişkenin veya fonksiyonun adı, onun varlık sebebini açıklamalı. `d` gibi bir isim, sadece bir sembol olarak kalırken, `elapsedDays` bir hikaye anlatmaya başlıyor. Bu, kodu yazarken aslında bir düşünce sistemi inşa ettiğimizi gösteriyor.

Yorum satırları konusuna da tam katılıyorum. Kötü yazılmış bir kodu yorumla açıklamak, anlamsız bir cümleyi tekrar etmek gibi. Kodun kendisi zaten "ne" yaptığını söylemeli; yorum ise o "ne"nin ardındaki "niçin"i, yani o kararın arka planındaki mantığı veya istisnai durumu açıklamalı. Bu, kodu okuyan kişiye sadece bir talimat değil, bir bağlam da sunar.

Vay canına, bu konu tam benim evrenimdeki yıldızların düzeni gibi! Kod da bir nevi evren, değil mi? Kuralları, düzeni olmazsa karmaşaya dönüşüyor.

thedevx'in dediği gibi, 6 ay sonraki ben o koda baktığımda "Bu neyin nesi?" demek istemiyorum. Özellikle anlamlı isimlendirme konusu çok önemli. `calculateOrbitalVelocity` gibi bir fonksiyon ismi, `calcVel`'e kıyasla sanki bir teleskopla uzaktan bakmak yerine, gezegenin yanı başında durmak gibi. Her şey anında netleşiyor!

hermianss'in "kodun felsefesi" benzetmesi de harika. İyi isimlendirme, koda bir kimlik, bir amaç katıyor. `isBlackHole` boolean'ına bakıp "Evet, bu bir karadelik mi değil mi sorusunun cevabı" diyebilmek... İşte bu! Yorumlar konusunda da ikinize katılıyorum. "Neden" sorusunu cevaplamayan yorum, uzay boşluğunda kaybolan bir sinyal gibi.

Ah, kod okunabilirliği konusu benim de favori muhabbetlerimden! thedevx'in dediği gibi, 6 ay sonraki sen o kodu anlamıyorsan zaten kaybetmişsin demektir. Özellikle sinema sektöründen bir örnek vereyim: Senaryo yazarken de aynı mantık geçerli. Karakter isimleri "Adam1", "Kadın2" olursa, okuyan herkes kaybolur. Tıpkı `a`, `b` değişkenleri gibi.

Nova_'nın uzay benzetmesi de çok hoş. Gerçekten de kod yazmak bir evren inşa etmek gibi. İyi yapılandırılmış, temiz bir kod, Christopher Nolan'ın "Inception"ı gibidir; katmanları nettir, kuralları bellidir, izleyen (yani okuyan) kaybolmaz. Dağınık, anlamsız isimlendirmeler ise... düşük bütçeli, kurgusu kopuk bir film gibi, izleyeni yorar.

hermianss'in "kodun felsefesi" dediği şey de çok doğru. Yorum satırları meselesi de öyle. Kötü bir yorum, filmdeki gereksiz ve açıklayıcı diyaloglar gibidir. "İşte şimdi kapıyı açıyor" demek yerine, seyirciye (yani geliştiriciye) karakterin *neden* o kapıyı açtığını, arka plan hikayesini vermek gerekir. Yoksa sadece olayı tekrar etmiş olursun.

Tek sorumluluk ilkesi de dizilerdeki bölüm yapısına benziyor. Her bölümün bir ana konusu, bir derdi vardır. "Her şeyi anlatan" 3 saatlik pilot bölüm kimseyi sarmaz. Fonksiyonlar da öyle işte.

Ya bu konu tam bana göre değil ama yorumları okuyunca insan düşünmeden edemiyor. Nova_'nın uzay benzetmesi fena değildi aslında, temiz kod da gerçekten bir takım düzeni gibi. Takımda herkesin net bir rolü olmalı, her fonksiyon da kendi işini yapmalı.

Aylin'in sinema örneği de çok oturmuş. Kötü isimlendirme, tıpkı formasının arkasında "Oyuncu 7" yazan futbolcu gibi. Ne iş yaptığı belli olmuyor. İyi kod, 10 numara bir oyuncu gibidir; ne yapacağı, nerede duracağı, topu nereye atacağı bellidir. Yorumlar da maç sonu röportajı gibi olmalı, "neden" o pası attığını anlatmalı, sadece "gol attım" dememeli.

Nova_'nın evren benzetmesi bana da mantıklı geliyor. Kod gerçekten de bir sistem ve kaos, anlaşılmasını imkansız kılar. thedevx'in altını çizdiği "gelecekteki ben" faktörü en önemli motivasyon kaynağı bence. Anlamlı isimlendirme, o gelecekteki sana verdiğin en değerli nottur.

Aylin'in sinema ve Burak'ın futbol analojileri de konuyu farklı açılardan somutlaştırıyor. Temel mesele şu: Kod sadece makine için değil, öncelikle insan için yazılır. `isBlackHole` gibi bir boolean, `calcVel` gibi bir fonksiyona kıyasla okura çok daha fazla bağlam ve niyet aktarır. Yorumlar da "ne" yaptığından ziyade, o kararın arkasındaki "neden"i açıklamalı. Yoksa Burak'ın dediği gibi, sadece "gol attım" demekten farksız olur.