Nedir bu Clean Code?

Her 3 teknik mülakattan 2'sinde mutlaka sorulan “clean code nedir” sorusunun cevabını irdeleyelim. Bunun için bir kitap önererek başlamak istiyorum. Robert C. Martin’in Clean Code kitabını edinebilirsiniz.

Kod, ekipteki herkes tarafından kolayca anlaşılabiliyorsa temizdir. Clean code, kodu yazan geliştirici dışındaki bir geliştirici tarafından okunabilir ve geliştirilebilir. Anlaşılabilirlik, okunabilirlik, değiştirilebilirlik, genişletilebilirlik ve sürdürülebilirliği beraberinde getirir.

Genel kuralları 🧽🧼
1.Standart kuralları takip edin.
2.Basit olmalı.Basit her zaman daha iyidir. Karmaşıklığı mümkün olduğunca azaltın.
3.Her zaman temel nedeni bulun. Her zaman bir sorunun temel nedenini arayın.

Tasarım kuralları 🧽🧼
1.Yapılandırılabilir verileri yüksek seviyelerde tutun. Erişilmesi kolay olmasın.
2.Polimorfizmi if/else veya switch/case’e tercih edin.
3.Multi-threading (çoklu iş parçacığı) kodlarını ayrıştırın.4.Aşırı yapılandırılabilirliği önleyin.
5.Dependency Injection’ı kullanın.
6.Demeter Yasasını takip edin. Bir sınıf yalnızca doğrudan bağımlılıklarını bilmelidir. Bir nesne veya bileşen, diğer nesnelerin veya bileşenlerin dahili çalışmasına ilişkin bilgiye sahip olmamalıdır.

Anlaşılabilirlik ipuçları 🧽🧼
1.Açıklayıcı değişkenler kullanın.
2.Sınır koşullarını kapsülleyin(encapsulate). Sınır koşullarını takip etmek zordur. Onlar için işlemeyi tek bir yere koyun.
3.Object tiplerini, primitif(int, string vb.) tiplere tercih edin.
4.Mantıksal bağımlılıktan kaçının. Aynı sınıftaki başka bir şeye bağlı olarak doğru çalışan methodlar yazmayın.
5.Negatif koşul cümlelerinden kaçının.

İsimlendirme kuralları 🧽🧼
1.Açıklayıcı ve net isimler seçin.
2.Telaffuz edilebilir isimler kullanın.
3.Kodun içerisinde gizli rakamlar ve sabitlerden kaçının.

4.İsimleri kodlamalardan kaçının. Ön ek eklemeyin veya bilgi yazmayın.

5.Encoding ve değişkenlerin önüne bir takım başlangıç tag takmayın.

Not: Önceden Javada Interface I gibi ön takılar olurdu. Şimdi editörlerin görsel gösterimleri ve arama kabiliyetleri sayesinde bu tarz isimlendirmelere gerek yok.

Kaynak kodu yapısı 🧽🧼
1.Kavramları dikey olarak ayırın.
2.İlgili kod dikey olarak yoğun görünmelidir.
3.Değişkenleri kullanımlarına uygun olarak tanımlanmalıdır.
4.Bağımlı fonksiyonlar birbirine yakın olmalıdır.
5.Benzer işlevler de yakın olmalıdır.
6.Fonksiyonları aşağı yönde yerleştirin.
7.Satırları kısa tutun.
8.Yatay hizalamayı kullanmayın.
9.İlgili şeyleri ilişkilendirmek ve zayıf ilişkili olanları ayırmak için boşluk kullanın.
10.Girintiyi bozmayın. Bunun için çoğu idede kısayollar bulunuyor.

Nesneler ve veri yapıları 🧽🧼
1.Kodun iç yapısını gizleyin.
2.Veri yapılarını tercih edin.
3.Hibrit yapılardan (yarı nesne ve yarı veri) kaçının.
4.Statik metotları , statik olmayanlara tercih edin.
5.Az sayıda örnek değişkeni.
6.Temel sınıf kendi türevleri hakkında hiçbir şey bilmemelidir.
7.Bir davranışı seçmek için bir fonksiyona bazı kodlar aktarmaktansa birçok fonksiyona sahip olmak daha iyidir.

Testler 🧽🧼
1.Test başına bir assert olmalı.
2.Okunabilir olmalı.
3.Hızlı olmalı.
4.Bağımsız olmalı.
5.Test tekrarlanabilir olmalı.

Bu kurallara uyulmadan oluşturulan code-baseler kötü kokmaya başlar diyebiliriz. Bu durum şu maddelere yol açar:

• Rigidity (Sertlik): Yazılımı değiştirmeniz çok zor hale gelmiştir. Küçük bir değişiklik, ardı ardına gelen değişikliklere neden olur.
• Fragility (Kırılganlık): Yazılımda ufak bir değişiklik uygulamanın bir çok yerini bozulmasına neden olur.
• Immobility (Hareketsizlik): İlgili riskler ve yüksek çaba nedeniyle kodun bazı kısımlarını başka projelerde yeniden kullanamazsınız.
• Needless Complexity: Gereksiz komplekstir.
• Needless Repetition: Gereksiz tekrar vardır.
• Opacity (Saydamlık): Okunabilirliği zordur.