it-swarm.dev

Aslında 'temiz kod' mu yazıyorsunuz?

Bazı programcıların kodlarını tekrar tekrar değiştirdiklerini gördüm, sadece 'iyi çalışmak' için değil, aynı zamanda 'iyi görünmek' için de.

IMO, 'temiz kod' aslında kodunuzun zarif, mükemmel anlaşılabilir ve bakımı kolay olduğunu gösteren bir iltifattır. Ve estetik açıdan çekici bir kod ile bakılması stresli bir kod arasında seçim yapmanız gerektiğinde fark ortaya çıkar.

Peki, kaçınız aslında 'temiz kod' yazıyor? İyi bir uygulama mı? Bunun diğer yararları ve dezavantajları nelerdir?

57
ykombinator

çoğumuzun temiz kod yazmadığını iddia ediyorum. Ve genellikle, bu bizim işimiz değil. Yazılım geliştirici olarak görevimiz, zamanında çalışan bir ürün sunmaktır.

Joel Spolsky'nin blog yazısı hatırlatıldı: Duct Tape Programmer .

İşyerinde Kodlayıcılar :

Günün sonunda, bu şeyi gönderin! Kodunuzu yeniden yazmak ve daha temiz hale getirmek harika ve üçüncü kez gerçekten güzel olacak. Ama mesele bu değil; kod yazmak için burada değilsiniz; ürünleri göndermek için buradasınız. - Jamie Zawinsky

Ayrıca hatırlatıyorum Robert Martin'in blog yanıtı :

Yani. Akıllı ol. Temiz ol. Basit olun. Gemi! Küçük bir koli bandı hazır bulundurun ve kullanmaktan korkmayın. - Bob Amca

Kod, bir geliştirici yazar temiz ve iş olur (teslim edilebilir), öyle olsun, herkes için iyi. Ancak bir geliştirici zamanında teslim edilme pahasına temiz ve okunabilir kod yapmaya çalışıyorsa, bu kötüdür. Çalışmasını sağlayın, koli bandı kullanın ve gönderin. Daha sonra yeniden düzenleyebilir ve süper muhteşem ve verimli hale getirebilirsiniz.

Evet, temiz kod yazmak iyi bir uygulamadır, ancak asla teslim edilmek pahasına değildir. Kanal bantlı bir ürünü zamanında teslim etmenin yararı, hiç bitmemiş ve teslim edilmemiş temiz kodun avantajlarından çok daha ağır basmaktadır.

Karşılaştığım iyi bir kod parçası temiz değil. Bazıları düpedüz çirkin. Ancak hepsi serbest bırakıldı ve üretimde kullanıldı. Bazıları dağınık kod yazmanın profesyonel olmadığını söyleyebilir. Katılmıyorum. Profesyonel olan şey, ister temiz ister dağınık olsun, çalışan kodu sağlamaktır. Geliştirici, teslimattan önce ayırdığı süre göz önüne alındığında elinden gelenin en iyisini yapmalıdır. Sonra, temizlemek için geri dönün - bu profesyonel. Umarım, verilen kod saf koli bandı değildir ve 'yeterince temiz'.

54
spong

Kodunuzun çok okunabilir, temiz ve bakım yapılabilir olduğundan emin olmalısınız. Tüm programcılar bunu yapar zorunluluk yapar.

Ama siz over styling (bu terim, yazarının egosundan başka hiçbir şeye hizmet etmeyen kız kodu gibi).

Geçmişte pek çok geliştiricinin yaratımlarından gurur duyduğunu gördüm (bilirsiniz, tuvaletlerde olduğu gibi;)), kodlarını temizlemek ve parlatmak için saatlerce harcadılar. Bazıları o kadar titizdi ki, üyeler arasında doğru beyaz boşluklara saygı gösterilmesini sağladılar.

Çok fazla.

Bu tür davranışları verimsiz buluyorum. profesyonel bağlamında, profesyonel olmalısınız. Temiz, çok okunabilir ve bakımı kolay kod yazarak ve mutlu kullanıcılar veya meslektaşlarınızla konuşarak memnuniyetinizi sağlayabilirsiniz.

39
user2567

Bu soruya kabul edilen cevaba katılmıyorum.

Sizin sorumluluğunuz açık bir şekilde gönderilmektir, ancak genellikle kendiniz ve gelecekteki geliştiriciler tarafından mümkün olduğunca düşük maliyetli bir şekilde muhafaza edilebilen bir şeyi gönderme sorumluluğunuz vardır.

Bazı kötü belgelendirilmemiş sistemi anlamak ve hata ayıklamak zorunda kalan zayıf bakım programcısı veya danışmanı olarak dönemler geçirdim ve size kötü tasarımların ve dağınık kafa karıştırıcı kodun saatler hatta günlerce boşa harcanmasına yol açabileceğini söyleyebilirim. İlk geliştiricinin fazladan bir N saatlik çalışmasının zamanım açısından 5N maliyet tasarrufu sağlayabileceği birçok durumu düşünebilirim.

Bu konuda yüzen bir istatistik olduğunu biliyorum, ancak birden fazla projedeki tecrübelerime göre, yazılan her kod satırı, uzatma ve bakım sırasında 5-20 kez okunur.

Bu yüzden hayatının bir inç içinde kodu temizlemek) söyleyebilirim. Zaman alır, ancak muhtemelen projenin ömrü boyunca net bir maliyet tasarrufu sağlar.

24
Benjamin Wootton

Davlumbazın altında sorun giderme, bakım veya onarım yapmanın zor olduğunu ve çalışması gerektiğinden daha fazla kaynak gerektirdiğini bildiğimizde herhangi bir araç satın alır mıyız?

Bir yazılım parçası için neden farklı olsun ki?

Son kullanıcıların kaputun altına bakamaması, onu asla tanımayacakları anlamına gelmez. Er ya da geç ortaya çıkacak.

"Aslında 'temiz kod' mu yazıyorsunuz?" -- Ah evet.!

21
Sifar

'Temiz kod' ile kodun olabildiğince açık olduğundan emin olmak için kendi yolumdan gidersem?

Heck evet.

Kod ne kadar temiz olursa, kodu o kadar temiz, bakımı o kadar kolay olur ve böylece uzun vadede size zaman kazandırır. Temiz kodlara makyaj gibi bakmayın; gelecekteki çaba ve zaman tasarrufu için bir yatırım olarak bakın.

18
GrandmasterB

Dürüst olmak gerekirse değişir. Herkesin "temiz iyi belgelenmiş koddan daha az bir şey saf bir travestidir!" çok kod herkesin yazdıkları iddia mükemmel temiz kod yazmak son derece zordur .

Kabaca benim yeteneğim olan biri tarafından kolayca korunabilen kod yazmaya çalışıyorum. Zor kısımları yorumluyorum, programları, değişkenleri ve sınıfları kolay isimlerle adlandırıyorum, konuşlandırıyorum ve devam ediyorum. Başka bir şey yapacak zamanım yok.

Bazen kendimi biraz suçlu hissediyorum, ama çok değil. Günlük olarak ele aldığım dehşetlerin bir kısmını görmelisin. Sıfır dokümantasyon ile belirsiz dillerde onlarca yıl süren özel kod. İş arkadaşlarımdan biri yalnızca Visual Basic 6.0'da gelişir ve her yerde şifreli olarak adlandırılan ikili dosyaları dağıtır. Değiştirdiğim kadın sadece RPG programladı.

Benim için bir programcı olarak gördüğüm kadar korkunç bir saçmalık gibi, herkesin sadece temiz kod oluşturduğuna inanmak benim için çok zor.

15
Satanicpuppy

Ben terim "kız kodu" gibi ama sanmıyorum temiz kod = sürdürülebilir kod sanmıyorum. Daha az olan herhangi bir şey profesyonel değildir.

Genel bir kural olarak, dağınıklığıma bakmak zorunda olan bir sonraki geliştiriciyi düşünüyorum.

Çoğu zaman benim ... birkaç ay sonra ... nasıl çalıştığını hatırlamadığımda ... ve bir değişiklik yapmak için daha az zamanım var.

7
Heath Lilley

Bob Martin anlamda "temiz kod" yazmaya çalışıyorum (örn. OO tasarım). Temiz kod yazarken büyük değeri var.

Sonra ReSharper'ın benim için "güzel kod" yapmasına izin verdim (örneğin hizalama, satır kesmeleri, vb.). Güzel kod yazarken iyi değeri vardır. Ancak azalan getiriler var. Bazı hoşnutluklar, okuma kolaylığı nedeniyle onu biraz daha sürdürülebilir hale getirir.

Okunabilir hale getirmek için büyük kod bloklarını düzgün bir şekilde sıralamanın gerekli olduğunu düşünüyorsanız, sorun garip büyük kod bloğunuzdur! O çok büyük. Bazı kötü tasarlanmış kodları güzelleştirmek için büyük acılar çeken birçok insan örneği görüyorum.

ReSharper olmasaydı, yine de temiz bir kod olurdu, ama o kadar güzel olmazdı.

Kodlama zamanımın ~% 5'inden fazlasını güzelleştirmeye harcamam gerektiğini düşünmüyorum. Bu, editörüm ne kadar güçlü ve ne kadar becerikli olduğum anlamına gelirse, o kadar çok şey yapabilirim.

5
dss539

Görünüşe göre hiç kimse şirketinizin menfaatinin ne olduğunu yükseltmiyor?

Genellikle, her zaman olmasa da, programcılar sadece çalışanlardır ve yönetim kararları bizi hayal kırıklığına uğratırken, çoğu zaman yaptıkları tüm verilere sahip değiliz.

Örneğin, şirket yazılım hazır değilse, ödeme almayacağınız bir fıkra ile sözleşme yaptığını varsayalım. Evet, temiz kod önemlidir, ancak daha önemli olan, kodun ödeme günü çalışmasını sağlamaktır!

Başka bir örnek - şirketin finansal durumu kötü ve biraz para toplaması gerekiyor. Bil bakalım kim kaliteye önem veriyor? Daha sonra düzeltebilirsiniz, eğer gerekiyorsa, sadece gönderin!

Bir argüman "Neden sadakat kodu satıp yazmalıyım?" Olabilir. Peki, şirketiniz neden size her ay güzel bir çek ödeyesin ki? Seçimler dostum. İdealizmin peşindeyseniz, Özgür Yazılım Vakfı ; Oldukça havalı şeyler yaptıklarını duyuyorum (bunu kastediyorum ve FSF ve OSS'ye saygı duyuyorum).

Diğer tarafta, kullanımda patlayıcı bir büyümenin beklendiği bir proje üzerinde çalışıyorsanız (bu tür projeksiyonlar neredeyse hiç doğru olmasa da), gerekli olan en iyi kod kalitesine sahip sağlam bir temel döşemeniz daha iyi olacaktır, çünkü neredeyse kesin bakım yapılacaktır. proje için daha büyük maliyet olacak.

Programcılar ne demek olursa olsun 'temiz' kodu sever. Neyin temiz olduğuna bile karar veremeyiz, ama seviyoruz. Bununla birlikte, bazen kullanılabilirlik ve doğruluk kadar önemli değildir. Bunlar eşanlamlı görünebilir, ancak değil - gerçek bir Perl korsanı tarafından 4 saat içinde iki kez kullanılmak ve atılmak niyetiyle yazılmış bir kod görürseniz, temiz olmadığını kabul edersiniz, ancak işe yarar.

Bazen ego bir yana, sadece işe koymalıyız. Alışkanlık olarak kötü kod yazmayı önermediğimi unutmayın; Sadece gerekli olabileceğine işaret ediyorum. Mükemmellik şirketinizin sahip olmayabileceği zaman alır. Yani işvereniniz sorun çıkarmazsa, zanaat yazılımı, ama eğer ihtiyacınız varsa, sadece çalışma kodunu yazın, 'temizliği' boş verin. . Bu sadece 'Tek beden herkese uyar' cevabı değil - öncelik vermelisiniz.

4
K.Steff

Çok fazla şey asla iyi olmaz.

Ancak, "kirli" kod ile akılda tutulması gereken önemli bir şey, kolayca " kırık pencereler " yol açabilir olmasıdır. Kod çok kötü biçimlendirilmişse, kod tabanına yeni gelen birçok kişi, bakım ve evrim ile iyi bir iş yapmaya daha az meyilli hissedebilir, bu da yazılımın çalışma koşullarını etkileyebilecek aşağıya doğru bir spiral oluşturur.

Bu nedenle, kodda belirli bir temizlik düzeyini korumak, diğer geliştiricilerinizden daha faydalıdır. Üzerinde çok fazla zaman harcamayın (~% 5 belirtilmiştir). Manuel görevleri otomatikleştirmek için teknenizin araçlarını kullanmayı öğrenin (bu durumda kod biçimlendirme). Yaptığınız işlerin sorumluluğunu üstlenin ve şirket/müşteriler/kullanıcılar için her zaman en faydalı olduğunu düşündüğünüz şeyi yapın.

3
Per Noalt

Bu Bob Martin'den Clean Code'dan bir alıntı:

Bu noktayı eve götürmek için, ya bir doktor olsaydınız ve çok fazla zaman aldığı için ameliyat için tüm aptal el yıkamasını durdurmanızı isteyen bir hasta olsaydı? Açıkçası hasta patron; ve yine de doktor kesinlikle uymayı reddetmelidir. Neden? Çünkü doktor, hastalık ve enfeksiyon riskleri hakkında hastadan daha fazlasını biliyor. Doktorun hastaya uyması profesyonelce olmaz (suçluya aldırmayın).

Bu nedenle, programcıların karışıklık yapma risklerini anlamayan yöneticilerin iradesine eğilmeleri profesyonel değildir.

3
Tulains Córdova

Emin değilim "iyi görünüyor" ve "zarif, mükemmel anlaşılabilir ve bakımı" eşdeğerdir.

Ben "zarif, mükemmel anlaşılabilir ve bakımı kolay" kod yazmaya çalışıyorum. Bu kriterleri daha iyi eşleştirmek için kendi kodumu yeniden düzenlerim.

Zaman içinde ortaya çıkan maliyet dışında herhangi bir dezavantaj görmüyorum.

Kodun "iyi görünmesi" için, her şeyi istediğiniz gibi girintili kılacak ve boşluk bırakacak birçok otomatik araç vardır.

3
back2dos

Kodun okunabilir olmasını seviyorum, ama en önemli şey tutarlılık. Benim için bu, adlandırma kurallarıyla tutarlılık anlamına gelir ve işlevler arasındaki boşluk, aynı satırdaki parantez veya if ifadesinin sonraki satırı vb.

Tabii ki, birisinin tutarlı bir kod stiliyle bir şey programladığı ve hala beni delirttiği zamanlar var. Özellikle "nefes almayan" kod. Örneğin:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Şey ... Objective-C yöntemleri ve çok sayıda iç içe if ifadeleri ve satırları 80 karakterden daha uzun olan daha kötü görünüyor. Ama yine de beni rahatsız ediyor :)

2
vedosity

"Temiz kod" fizik/mühendislik/matematik sınavlarına yazmak için kullandığınızdan daha temiz veya daha temiz olması gerektiğini düşünüyorum. Çok dağınıksa, greyder çalışmanızı anlamaz ve muhtemelen doğru olsa bile yanlış işaretler.

2
chiurox

Kodu temizlemek için çok uzun zaman harcıyorum. Hataların öne çıkmasına çok yardımcı olduğunu düşünüyorum.

Temiz kod geleceğe yapılan bir yatırım olduğu için "şimdi lanet şeyi gönder" konseptine katılmıyorum. Ayrıca çok fazla yazılım çok fazla hata ile gönderilir. Bence bir hatayı çözmek, yeni bir özellik uygulamaktan daha iyidir.

Ayrıca programcı üretkenliği tahminleri 'a bakarsanız, çok kötü puan aldığımı sanmıyorum. Temiz kod yazmak bir alışkanlıktır ve bir programcı olarak ne kadar çok deneyim olursa, kod o kadar verimli olur. Eğer hiç denemezse, açıkçası, hiç deneyimlenmeyecektir.

Dikkate alınması gereken bir diğer nokta, çoğu geliştirici zamanının kodu okumaya gitmesidir, bu nedenle okunabilir kod, okuma için harcanan süreyi büyük ölçüde azaltır. Belgelenmemiş algoritmaları anlamak pahalıya mal olabilir ve yeni hataları davet edebilir.

Kesinlikle özlediğim ve bir gün olmasını istediğim bir şey, stilime uyum sağlayabileceğim, özellikle de başkalarının kodlarını okurken bana biraz zaman kazandıracak otomatik bir kod formatlayıcı.

Temiz kodlama, asla gerçekleşme riski taşımayan mükemmeliyetçiliğe bir bağlantıya sahiptir, ancak bence bu başlangıçta bir problemdir, çünkü daha sonra yatırım yaparsınız ve kendi zarif kod parçalarınızı yeniden kullanırsanız, deneyiminizle birlikte , yaşlandıkça, dağınık kodlayıcılardan daha çok böcek ve çok daha az perili olacaksınız.

Bu bir parça kodlama tarzımı gösteren kod.

2
user20416

Sadece "özel kod" dan kaçının. Dışarıda tamamen kibir (ya da bir OKB nedeniyle) ve başka hiçbir şey yapmayan birçok geliştirici var. Külotlarım gerçekten bu insanlarla bükülüyor.

1
ElGringoGrande

Verilen problemi en verimli ve teorik olarak 'zarif' şekilde çözmeye çalışan bir kod yazıyorum. Bu anlamda sadece temizdir. İşim bittiğinde 'güzel' olursa, öyle olsun.

Sınırlı deneyimlerimde bulduğum şey, insanlar 'temiz kod' hakkında şikayet ettiğinde, çirkinliğin genellikle kodlama kuralından ziyade korkunç bir çözümün sonucudur.

1
Kurtis

Temiz kod yazmak için çaba harcadığımı söyleyebilirim, ancak zaman kısıtlamaları veya zor bir şey üzerinde çalışıyorsam bu değişebilir. Çalışmaya odaklanırken dağınık olma eğilimindedir. Sonra geri gider ve ben gözden gibi temizleyeceğim. Eğer koda dönerseniz ve belleğinizi yenilemek için çok fazla zaman harcamak zorunda kalırsanız, yeterli yorum yapmadınız.

Temiz kod iyi ama her şey gibi, sadece yeterince temiz olması gerekiyor. 5 satır kod 4 boşluk ve bir satır 5 boşluk girilmesi okuma zorluğunu artırmaz.

1
JeffO

Bence ne yaptığınıza bağlı. Eğer bir kavram kanıtı uygulaması yazıyorsam, o zaman temelde kıçımı kovboy kodluyorum ve geriye bakmıyorum. Bir süre üzerinde çalışacağım bir uygulama üzerinde çalışıyorsam, o zaman bir ay sonra anlaşılabilir olmasını sağladığımdan emin olun.

Kodunuzu şekillendirmenin biraz havalı olduğunu düşünüyorum. Yukarıda belirtildiği gibi, işiniz biçimlendirilmiş kod değil, bir ürün yapmaktır, ancak en azından birinin yorum ve kodlama şeylerinin tanımlanmış bir stiline sadık kalması gerektiğini söyleyebilirim. Deve kasalı değişkenlerin yarısını, diğer yarısı Macarları görmekten nefret ediyorum.

Ama aynı zamanda 'temiz kod' ile ne demek istediğinize de bağlıdır.

1
user7007

Kodunuzu zarif hale getirmek için yeniden düzenlemek, okumayı ve bakımını kolaylaştırır. Değişken ödevlerinizi hizalamak gibi küçük şeyler bile:

int foo    = 1;
int bar    = 2;
int foobar = 3;

okumak daha kolay

int foo = 1;
int bar = 2;
int foobar = 3;

bu, daha sonra hata ayıkladığınız zaman gözden geçirmenin daha kolay olduğu anlamına gelir.

Ayrıca, PHP rastgele kod blokları herhangi bir sayıda izin verilir. Bunları mantıksal görevleri gruplandırmak için kullanın:

// do x
{
    // ...
}

// do y
{
    // ...
}

Bu, ilgili koda net bir tanım ekler.

Düzenle: Ek bir bonus olarak, geçici olarak atlamak istiyorsanız bu mantıksal kod bloklarından birini if (false) ile önceden ayarlamak kolaydır.

0
Craige

Bunu yapmayı kabul ediyorum; ve fayda her gördüğümde rahatsız olmuyor. Sanırım okumak da daha kolay ve bu yüzden hatalar daha belirgin hale geliyor; ama asıl nedeni çirkin kod dayanamıyorum.

0
user281377