Temiz kod nasıl yazılır? “Temiz Kod”dan alınan dersler.

Üzeyir AYDIN

15 Mar

Paylaş :

İki şey vardır - Programlama ve İyi Programlama. Programlama hepimizin yaptığı şeydir. Şimdi iyi programlama yapma zamanı. Hepimiz kötü kodun bile çalıştığını biliyoruz. Ancak bir programı iyi hale getirmek zaman ve kaynak gerektirir. Ayrıca, diğer geliştiriciler, kodunuzda neler olduğunu bulmaya çalışırken sizinle alay ederler.

Ancak programlarınızla ilgilenmek için asla geç değildir.

Bu kitap bana en iyi uygulamaların neler olduğu ve gerçekte nasıl kod yazılacağı konusunda çok fazla bilgi verdi. Şimdi kodlama becerilerimden utanıyorum. Kodumu her zaman daha iyi hale getirmeye çalışmama rağmen, bu kitap çok daha fazlasını öğretti.

Şimdi, bu blogu iki nedenden dolayı okuyorsunuz. Birincisi, sen bir programcısın. İkincisi, daha iyi bir programcı olmak istiyorsunuz. İyi. Daha iyi programcılara ihtiyacımız var.

Temiz kodun özellikleri :

Zarif olmalı - Temiz kod okumak hoş olmalıdır. Onu okumak, iyi hazırlanmış bir müzik kutusu veya iyi tasarlanmış bir araba gibi sizi gülümsetmeli.

Temiz kod odaklıdır—Her işlev, her sınıf, her modül, çevredeki ayrıntılar tarafından tamamen dikkati dağıtılmamış ve kirletilmemiş olan tek fikirli bir tutumu gözler önüne serer.

Temiz kod halledilir. Birisi bunu basit ve düzenli tutmak için zaman ayırdı. Ayrıntılara gereken özeni göstermişlerdir. Onlar umursadılar.

4. Tüm testleri çalıştırır

5. Çoğaltma içermez

6. Sınıflar, yöntemler, işlevler ve benzerleri gibi varlıkların sayısını en aza indirin.

Temiz kod nasıl yazılır?

Anlamlı İsimler

Niyet açıklayıcı isimler kullanın. İyi adları seçmek zaman alır, ancak gerekenden daha fazlasını kazandırır. Bir değişkenin, işlevin veya sınıfın adı, tüm büyük soruları yanıtlamalıdır. Size neden var olduğunu, ne yaptığını ve nasıl kullanıldığını anlatmalıdır. Bir isim bir yorum gerektiriyorsa, o zaman isim onun amacını ifşa etmez.

Örn. d; // gün olarak geçen süre.

Neyin ölçüldüğünü ve bu ölçümün birimini belirten bir isim seçmeliyiz.

Daha iyi bir ad şöyle olurdu: - int elapsedTime. (Kitap elapsedTimeInDays yazsa da ben yine de eskisini tercih ederim. Diyelim ki geçen süre milisaniye olarak değiştirildi. O zaman elapsedTimeInDays yerine long'u int ve elapsedTimeInMillis'e çevirmemiz gerekecek. Ve ikisini de ne kadar süreyle değiştirmeye devam edeceğiz? veri türü ve adı.)

Sınıf Adları — Sınıflar ve nesneler, Müşteri, WikiPage, Hesap ve AddressParser gibi isim veya isim tümcesi adlarına sahip olmalıdır. Sınıf adında Yönetici, İşlemci, Veri veya Bilgi gibi sözcüklerden kaçının. Bir sınıf adı bir fiil olmamalıdır.

Yöntem Adları — Yöntemler, postPayment, deletePage veya save gibi fiil veya fiil öbeği adlarına sahip olmalıdır. Erişimciler, mutatörler ve yüklemler değerlerine göre adlandırılmalı ve başına get, set eklenmelidir.

Yapıcılar aşırı yüklendiğinde, bağımsız değişkenleri tanımlayan adlarla statik fabrika yöntemlerini kullanın. Örneğin,

Karmaşık dayanak noktası = Complex.FromRealNumber(23.0); genellikle Complex fulcrumPoint = new Complex(23.0)'dan daha iyidir;

Kavram Başına Bir Kelime Seçin - Bir soyut kavram için bir kelime seçin ve buna bağlı kalın. Örneğin, farklı sınıfların eşdeğer yöntemleri olarak getirme, alma ve alma kafa karıştırıcıdır. Hangi metot adının hangi sınıfa ait olduğunu nasıl hatırlıyorsunuz? Aynı şekilde, aynı kod tabanında bir denetleyiciye, bir yöneticiye ve bir sürücüye sahip olmak kafa karıştırıcıdır. DeviceManager ve Protocol-Controller arasındaki temel fark nedir?

Fonksiyonlar

Fonksiyonların ilk kuralı, küçük olmaları gerektiğidir. Fonksiyonların ikinci kuralı, bundan daha küçük olmaları gerektiğidir. Bu, if ifadeleri, else ifadeleri, while ifadeleri vb. içindeki blokların bir satır uzunluğunda olması gerektiği anlamına gelir. Muhtemelen bu satır bir işlev çağrısı olmalıdır. Bu, yalnızca çevreleyen işlevi küçük tutmakla kalmaz, aynı zamanda, blok içinde çağrılan işlevin güzel açıklayıcı bir adı olabileceğinden, belge değeri de ekler.

fonksiyon argümanları

Bir işlevin 3'ten fazla argümanı olmamalıdır. Mümkün olduğunca düşük tutun. Bir işlev iki veya üçten fazla argümana ihtiyaç duyduğunda, bu argümanlardan bazılarının kendi sınıflarına sarılması muhtemeldir. Onlardan nesneler yaratarak argüman sayısını azaltmak, hile yapmak gibi görünebilir, ama değil.

Şimdi, bir fonksiyon boyutunu küçült dediğimde, kodunuzu çok daha büyük hale getirdiğinden, kesinlikle try-catch'i nasıl azaltacağınızı düşünürdünüz. Cevabım, sadece try-catch-finally ifadelerini içeren bir fonksiyon yapmak. Ve dene/yakala/son olarak bloğun gövdelerini ayrı bir işlevde ayırın. Örneğin-

Bu, mantığın kristal berraklığında olmasını sağlar. İşlev adları, elde etmeye çalıştığımız şeyi kolayca tanımlar. Hata işleme göz ardı edilebilir. Bu, kodun anlaşılmasını ve değiştirilmesini kolaylaştıran güzel bir ayrım sağlar.

Hata İşleme bir şeydir - İşlev bir şey yapmalıdır. Hata işleme başka bir şeydir. Bir fonksiyon try anahtar sözcüğüne sahipse, bu ilk anahtar sözcük olmalıdır ve catch/finally bloklarından sonra hiçbir şey olmamalıdır.

Yorumlar

Amacını kanıtlamak için yorum yazıyorsan, bir gaf yapıyorsun. İdeal olarak, yorumlara hiç gerek yoktur. Kodunuzun yorumlanması gerekiyorsa, yanlış bir şey yapıyorsunuz. Kodumuz her şeyi açıklamalıdır. Modern programlama dilleri, amacımızı kolayca açıklayabileceğimiz İngilizce gibidir. Doğru adlandırma yorumları engelleyebilir.

Hukuki yorumlar burada dikkate alınmaz. Yazmak için gereklidirler. Yasal yorumlar, telif hakkı ve lisans beyanları anlamına gelir.

Nesneler ve Veri Yapıları

Bu karmaşık bir konudur, bu yüzden ona iyi dikkat edin. Öncelikle nesne ve Veri Yapıları arasındaki farkı netleştirmemiz gerekiyor.

Nesneler, verilerini soyutlamaların arkasına saklar ve bu veriler üzerinde çalışan işlevleri ortaya çıkarır. Veri yapısı, verilerini açığa çıkarır ve anlamlı işlevleri yoktur.

Bu 2 şey tamamen farklı. Biri sadece verileri depolamakla ilgili, diğeri ise bu verilerin nasıl değiştirileceği. Örneğin, aşağıdaki prosedürel şekil örneğini düşünün. Geometri sınıfı, üç şekil sınıfı üzerinde çalışır. Şekil sınıfları, herhangi bir davranışı olmayan basit veri yapılarıdır. Tüm davranışlar Geometri sınıfındadır.

Geometri'ye bir çevre() işlevi eklenirse ne olacağını düşünün. Şekil sınıfları etkilenmeyecektir! Şekillere bağlı olan diğer sınıflar da etkilenmeyecektir! Öte yandan, eğer yeni bir şekil eklersem, onunla başa çıkmak için Geometri'deki tüm fonksiyonları değiştirmem gerekir. Tekrar, baştan okuyun. İki koşulun taban tabana zıt olduğuna dikkat edin.

Şimdi yukarıdaki senaryo için başka bir yaklaşım düşünün.

Artık önceki duruma kıyasla kolayca yeni Şekiller, yani veri yapıları ekleyebiliriz. Ve eğer sadece bir Shape'e perimeter() fonksiyonu eklemek zorunda kalırsak, Shape sınıfı, area() ve perimeter() fonksiyonlarını içeren bir arayüz olduğundan, bu fonksiyonu tüm Shapes'e uygulamak zorunda kalırız. Bu şu anlama gelir:

Veri yapıları, mevcut veri yapılarını değiştirmeden yeni işlevler eklemeyi kolaylaştırır. OO kodu (nesneleri kullanarak), mevcut işlevleri değiştirmeden yeni sınıflar eklemeyi kolaylaştırır.

Ücretsiz de doğrudur:

Prosedürel kod (veri yapılarını kullanarak), tüm fonksiyonların değişmesi gerektiğinden yeni veri yapıları eklemeyi zorlaştırır. OO kodu, tüm sınıfların değişmesi gerektiğinden yeni işlevler eklemeyi zorlaştırır.

Yani, OO için zor olan şeyler prosedürler için kolaydır ve prosedürler için zor olan şeyler OO için kolaydır!

Herhangi bir karmaşık sistemde, yeni işlevler yerine yeni veri türleri eklemek istediğimiz zamanlar olacaktır. Bu durumlar için nesneler ve OO en uygunudur. Öte yandan, veri türleri yerine yeni işlevler eklemek isteyeceğimiz zamanlar da olacaktır. Bu durumda prosedürel kod ve veri yapıları daha uygun olacaktır.

Olgun programcılar, her şeyin bir nesne olduğu fikrinin bir efsane olduğunu bilirler . Bazen üzerlerinde çalışan prosedürlere sahip basit veri yapılarını gerçekten istersiniz . Bu nedenle, neyin güncelleneceğinin gelecekteki perspektifini düşünerek neyin uygulanacağını dikkatlice düşünmelisiniz. Bu örnekte olduğu gibi, gelecekte herhangi bir yeni şekil eklenebileceğinden, bunun için OO yaklaşımını seçeceğim.

Görevlerinizi yapmanız gereken zaman çizelgesi göz önüne alındığında iyi programlar yazmanın zor olduğunu anlıyorum. Ama nereye kadar erteleyeceksin? Yavaş başlayın ve tutarlı olun. Kodunuz kendiniz ve çoğunlukla başkaları için harikalar yaratabilir. Başladım ve her zaman yaptığım birçok hata buldum. Günlük zaman sınırımdan fazladan saatler almış olsa da, gelecekte bana ödeme yapacak.

Bu, bu blogun sonu değil. Kodunuzu temizlemenin yeni yolları hakkında yazmaya devam edeceğim. Ayrıca, herhangi bir teknolojide her geliştiricinin bilmesi gereken bazı temel tasarım kalıpları hakkında da yazacağım.

Bu arada blogumu beğendiyseniz ve ders aldıysanız lütfen alkışlayın. Daha hızlı yeni blog oluşturmam için bana motivasyon veriyor :) Yorumlar/Öneriler her zaman olduğu gibi memnuniyetle karşılanmaktadır. Öğrenmeye ve paylaşmaya devam edin.