Clean Code Derken?

Merhabalar, okuduğum Robert C. Martin ‘in “Clean Code “ kitabından aldığım notları sizinle paylaşmak istiyorum.Kodlamada kendini geliştirmek isteyenlerin kesinlikle okumalarını tavsiye ettiğim bir kitap.Kitabın başında yazar şöyle diyor :
”Bu kitabı iki nedenden dolayı okuyorsun. İlki bir programcısın. İkincisi, daha iyi bir programcı olmak istiyorsun. İyi, Daha iyi programcılara ihtiyacımız var.”

İlk üç bölümden başlayalım, herkese keyifli okumalar diliyorum :)

Clean Code ?

Clean Code nasıl olmalıdır;

1. Clean Code basit ve anlaşılır olmalıdır.
2. Orijinal yazarı dışındaki bir developer tarafından okunabilir ve geliştirilebilir olmalıdır.
3. Birim ve kabul testleri olmalıdır.
4. Tüm testleri çalıştırmalıdır.
5. Bugların gizlenmesini zorlayacak kadar düz ve anlaşılır olmalı.
6. Bakımı kolaylaştıracak kadar az bağımlılığa(dependency ) sahip olmalıdır.
7. Class ,metot ve fonksiyon gibi varlıkların sayısını en aza indirmeli.
8. Dublicate koddan kaçınılmalıdır.
9. Anlamlı isimlendirmelere sahip olmalıdır.
10. Sistemdeki tüm tasarım fikirlerini ifade etmelidir.

Meaningful Names(Anlamlı İsimlendirme)

İyi isimlendirme yapmak çok zaman alır fakat uzun vadede çok zaman kazandırır.O yüzden isimlendirme yaparken bazı şeylere dikkat etmeliyiz.

Avoid Disinformation(Açıklayıcı isimler kullanın)

İsimlendirme yaparken amacımızı belirtmeliyiz.Bir değişken ,fonksiyon ya da bir class adı yazarken; neden var olduğu ,niçin kullanıldığı ve nasıl kullanıldığını söylemelidir.

int d; // elapsed time in days

Örneğin d ile burda günü ifade etmek için kullanılmış fakat zihnimizde hiçbir şey uyandırmıyor.Bunun yerine açıklayıcı olan aşağıdakini kullanın.

int elapsedTimeInDays;

Make Meaningful Distinction(Anlamlı Ayrımlar Yapın)

İsimlerin farklı olması gerekiyorsa anlamları da farklı olmalıdır.Örneğin Product isimli bir classım var.Product Info ve Product Data isimli classlarım olsun.Aynı scope ta Info ve Data belirsizlik yaratır.Aynı anlama gelen isimler bir arada kullanılmamalıdır.

Use Pronounceable Names(Telaffuz Edilebilen İsimler Kullanın)

Okunabilir değişkenler tanımlamalıyız .

Use Searchable Names(Aranabilir İsimler Kullanın)

Bir değişken ya da bir sabit kod gövdesinde birden fazla yerde kullanılıyorsa aramaya uygun isimlendirme yapılmalıdır.

Örneğin burada WORK_DAYS_PER_WEEK değişkenini aramak 5 in kullanıldığı tüm yerleri aramaktan daha kolaydır.Burada sum değişkeni kullanışlı bir değişken değil fakat en azından aranabilir bir isimdir.

Class Names

Class isimleri ve nesneler isim ya da isim tamlaması olmalıdır. Örneğin :Customer ,Account ve WikiPage gibi . Manager, Processor, Data, ya da Info gibi isimledirmelerden kaçınılmalıdır.Bir class ismi fiil olmamalıdır.

Method Names

Metot isimleri fiil ya da fiil tamlaması olmalıdır. Örneğin: postPayment, deletePage, ya da save.

Constructorları overload etmek yerine argümanları tanımlayan isimlerle static factory methodlarını kullanın.Örneğin;

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

Yukarıdaki alttakine göre daha iyidir.

Complex fulcrumPoint = new Complex(23.0);

Add Meaningful Context(Anlamlı Bağlam Ekleyin)

firstName, lastName, street, houseNumber, city, state, ve zipcode gibi değişkenlerim olduğunu hayal edelim.Birlikte ele alındığında bir adresin detayları old. oldukça açık.Prefixleri kullanarak bir bağlam sağlayabilirsiniz. addrFirstName, addrLastName, addrState gibi.En azından okuyucular bu değişkenlerin daha büyük bir yapının parçası old. anlayacaktır.Elbette daha iyi bir çözüm ise Address adında bir class oluşturmaktır.

Don’t Add Gratuitous Context(Gereksiz Bağlam Eklemeyin)

Bir isme gerekli olmayan bir bağlam eklemeyin . Örneğin : “Gas Station Deluxe” (GSD) adında bu uygulamamız olsun.GSD’nin accounting modülüne MailingAddress classı oluşturduğunuzu ve GSDAccountAddress adıyla isimlendirdiğinizi düşünün.Sonradan müşteri iletişim uygulaması için mail adreslerini tutan bir classa ihtiyacınız oldu diyelim.Burada GSDAccount tamamen gereksizdir. 17 karakterden 10 u burada gereksizdir.Bu yüzden gereksiz bağlam kullanmaktan kaçınılmalıdır.

Chapter 3: Functions

Small!

Fonksiyonların ilk kuralı küçük olmaları gerektiğidir.İkinci kuralı, daha küçük olmaları gerektiğidir.Fonksiyonlar en fazla 20 satır uzunluğunda olmalıdır.

Blocks and Indenting

if statement ,else statements ya da while statements bir satır uzunluğuna sahip olmalıdır.Bir fonksiyonun girinti düzeyi bir ya da ikiden fazla olmamalıdır.

Do One Thing

Fonksiyonlar bir şey yapmalı, onu çok iyi yapmalı ve sadece onu yapmalıdır. Bir fonksiyonun bir şey yaptığından nasıl emin olabiliriz ? Bir fonksiyon adında verilen ifade ile aynı soyutlama seviyesinde olmalıdır.

Switch Statements

Switch doğası .gereği n tane şey yapar.Ancak . her switch ifadesi düşük seviyeli bir classa gömülü olduğundan ve asla tekrarlanmadığından emin olabiliriz.Bunu elbette polymorphism le yapar.

Bu fonksiyonla ilgili birkaç problem var.İlki büyük ve yeni bir çalışan türü eklenmek istenildiğinde büyümesi, ikincisi çok açık bir şekilde fonksiyonun birden fazla şey yapması, üçüncüsü SRP ‘yi (Single Responsibility Principle) ihlal ediyor çünkü değişmesi için birden fazla sebep var.Dördüncüsü Open Closed Principle ‘ı ihlal ediyor olması çünkü yeni tipler eklendiğinde fonksiyon değişmesi gerekiyor.Fakat bu fonksiyondaki en büyük problem aynı yapı altında sınırsız sayıda başka fonksiyonlara sahip olacak olması.

Bu sorunun çözümü switch ifadesini Abstract Factory (design pattern )tabanına gömmektir ve başka kimsenin görmesine izin vermemektir.

Use Descriptive Names

Ward’s prensibine göre:”her program istediğiniz gibi çalıştığında temiz kod üzerinde çalıştığınızı anlarsınız.” Bu prensibi gerçekleştirmenin ilk adımı tek şey yapan küçük fonksiyonlar için iyi isimler seçmektir.Bir fonksiyon ne kadar küçük ve odaklanmışsa isim seçmek o kadar kolay olur.Uzun tanımlayıcı bir ad, uzun bir yorum satırı yazmaktan çok daha iyidir.

İsimlendirme yaparken birden fazla kelimenin kolayca okunmasını sağlayan bir kural belirleyin ve ardından fonksiyonun ne yaptığını söyleyen bir isim verin.

İsimlendirme yaparken tutarlı olun.Modülleriniz için seçtiğiniz fonksiyon adları aynı cümleleri aynı isimleri ve fiilleri kullanın.Örneğin ;

includeSetup- AndTeardownPages, includeSetupPages, includeSuiteSetupPage, and includeSetupPage

Bu isimler gibi benzer ifadeler bir hikaye anlatmasına izin verir.

Function Arguments

Fonksiyonlardan ideal argüman sayısı sıfırdır(niladic).Sonra bir (monodic),ve ardından ikidir(dyadic).Mümkünse üç (triadic)argümandan mümkünse kaçınılmalıdır.Eğer üçten fazla argüman varsan bir class içerine konulmalıdır.

Have No Side Effects

Side effectler bizi kandırır.Bir fonksiyon adında verilen ifade ile aynı soyutlama seviyesine sahip olmalıdır.Yani adında verilen ifade ile aynı şeyi yapmalıdır.

Örneğin burada username ile password’ ü eşleştirmek için standart bir algoritma kullanılıyor.Buradaki side effecti farkettiniz mi?

Tabiiki de Session.initialize() ın çağrılmasıdır.Burada adında verilen ifade ile aynı şeyi yapmıyor. Bu fonksiyon adını checkPasswordAndInitializeSession şeklinde olarak yeniden adlandırabilirsiniz.Bunda da kesinlikle “bir şey yap” ilkesini ihlal ediyor.

Bir sonraki yazımda görüşmek üzere herkese Clean Code lu ‘günler :)