Aslında 'temiz kod' yazıyor musunuz? [kapalı]

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

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

Peki, kaçınız “temiz kod” yazıyor? İyi bir uygulama mı? Bunun diğer yararları veya sakıncaları nelerdir?

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

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

İşyerindeki Kodlayıcılardan alıntılar :

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

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

Yani. Akıllı ol. Temiz ol. Basit ol. Gemi! Ve küçük bir koli bandı bantını hazırda tutun ve kullanmaktan korkmayın. - Bob Amca.

Eğer bir kod yazarsa, yazar yazar temiz olur ve çalışır (teslim edilebilir), öyleyse, herkes için iyi olur. Ancak bir geliştirici, zamanında ve zamanında teslim edebilmek pahasına temiz ve okunaklı bir kod oluşturmayı deniyorsa, o zaman bu kötüdür. Çalışmasını sağlayın, koli bandı kullanın ve gönderin. Daha sonra refaktör ve süper güzel ve verimli hale getirebilirsiniz.

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

Karşılaştığım iyi bir kod parçası temiz değil. Bazıları düpedüz çirkin. Fakat hepsi serbest bırakıldı ve üretimde kullanıldı. Bazıları dağınık kod yazmanın profesyonelce olmadığını söyleyebilir. Katılmıyorum. Profesyonel olan, temiz veya dağınık olsun, işe yarayan bir kod sunmaktır. Geliştirici, teslimattan önce ne zaman ayrılırsa yapsın, yapabileceğinin en iyisini yapmalıdır. Ardından, temizlemek için geri dönün - bu profesyonel. Umarım, verilen kod saf koli bandı değildir ve “yeterince temizdir”.

Kodunuzun çok okunabilir, temiz ve bakımlı olduğundan emin olmalısınız. Tüm programcıların yapması gereken budur.

Ancak , yazarının egosundan başka hiçbir şeye hizmet etmeyen over styling(bu kız kodu daha iyi bir terim gibi) hakkında konuşuyorsunuz .

Geçmişte pek çok geliştiriciyi yarattıklarından gurur duyduğumu gördüm (tuvaletlerde olduğu gibi), kodlarını temizlemek ve parlatmak için saatler harcadılar. Bazıları o kadar titizdi ki, üyeler arasındaki doğru boşluklara saygı gösterilmesini sağladılar.

Bu çok fazla.

Bu tür davranışlara karşı verimsiz davranıyorum. Bir de profesyonel bağlamda, sen olmalısın profesyonel . Temiz, okunaklı ve bakımı kolay bir kod yazarak ve mutlu kullanıcılar veya iş arkadaşlarınızla konuşarak memnuniyetinizi elde edebilirsiniz.

Bu soruya kabul edilen cevaba katılmıyorum.

Sizin sorumluluğunuz açıkça bellidir, ancak genellikle kendiniz ve gelecekteki geliştiricilerin mümkün olduğu kadar düşük maliyetle idare edebileceği bir şeyi sevk etme sorumluluğunuz da vardır.

Bazı kötü belgelenmemiş sistemi anlamak ve hata ayıklamak zorunda olan kötü bakım programcısı veya danışman olarak dönemler geçirdim ve size kötü tasarımların ve karışık kafa karıştırıcı kodların saatler süren harcadığınız çabalara yol açabileceğini söyleyebilirim. İlk geliştiricinin fazladan N saatlik bir çaba göstermesinin zamanım açısından 5N maliyet tasarrufu sağlayabileceği pek çok durum düşünebilirim.

Bu konuda bir istatistik dalgası olduğunu biliyorum, ancak çoklu projelerdeki deneyimlerime göre, yazılan her kod satırı uzatma ve bakım sırasında 5-20 kez okunur.

Bu yüzden kodu ömrünün bir inçinde silmek için derim . Zaman alıyor, ancak projenin ömrü boyunca net bir maliyet tasarrufu sağlıyor.

Eğer kaputun altında sorun gidermek, bakım yapmak veya tamir etmek zor ve zor, ve olması gerekenden daha fazla kaynak gerektiriyorsa, herhangi birimiz bir araba satın alabilir miyiz?

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

Sadece son kullanıcıların kaputun altına bakamayacağı, asla bilemeyeceği anlamına gelmez. Er ya da geç o ortaya çıkacaktır.

"Gerçekten 'temiz kod' yazıyor musunuz? ' -- Ah evet.!

Eğer 'temiz kod' derken, kodun mümkün olduğunca net olduğundan emin olmak için yolumdan çekiliyor muyum?

Heck evet.

Kod ne kadar temiz olursa, kod o kadar temiz olur, bakımı o kadar kolay olur ve bu sayede uzun vadede zaman kazandırır. Temiz koya kibir olarak bakmayın; buna gelecekteki çaba ve zamandan tasarruf etmek için bir yatırım olarak bakın .

Açıkçası buna bağlı. Herkesin parti çizgisini "temiz, iyi belgelenmiş bir kodun tamamen bir travesti olduğu kadar iyi bir şey olduğu" konusunda nasıl savunduğunu seviyorum, ama saçma dağıtım döngüleri ve sıfır gözetimi olan bir işletmede çalışıyorum: elimden gelenin en iyisini yapıyorum. Kodların çoğunun, herkesin yazdığını iddia ettiği temiz mükemmel kodu yazmak oldukça zor .

Kabiliyetim olan bir kişi tarafından kolayca korunabilecek bir kod yazmaya çalışıyorum. Zor kısımları yorumluyorum, programlara, değişkenlere ve sınıflara uygun isimlere isim veriyorum, konuşlandırıyorum ve devam ediyorum. Başka bir şey yapacak vaktim yok.

Bazen kendimi biraz suçlu hissediyorum ama çok değil. Günlük olarak uğraştığım bazı korkuları görmelisin. Gizli belgelerdeki onlarca yıllık özel kod, sıfır belgeli. İş arkadaşlarımdan biri yalnızca Visual Basic 6.0'da geliştiriliyor ve her yerde şifreli olarak adlandırılan ikili dosyaları dağıtıyor. Yerine koyduğum kadın sadece RPG programlandı .

Benim için son derece zor, bir programcı olarak yıllarımda gördüğüm kadar korkunç bir saçmalığa, herkesin yalnızca temiz kod ürettiğine inanmak benim için çok zor .

"Kız kodu" terimini sevdiğimi sanmıyorum ama temiz kod = korunabilir kod. Daha az bir şey profesyonelce değildir.

Genel bir kural olarak, karışıklığıma bakması gereken 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 olduğu zaman.

Bob Martin anlamında "temiz kod" yazmaya çalışıyorum (örneğin, OO tasarımı). Temiz kod yazarken büyük değer var . Çok daha bakımı yapılabilir.

Sonra ReSharper'ın benim için "güzel kod" yapmasına izin verdim (örn. Hizalama, satır sonları vb.). Güzel kod yazmanın iyi bir değeri var . Ancak azalan getiriler var. Bir parça titizlikle okuma kolaylığı nedeniyle biraz daha bakım yapılabilir hale getirir.

Düzgünce büyük kod bloklarını sıraya sokmak için okunabilir hale getirilmesi gerektiğine inanıyorsanız, o zaman sorun şu andaki büyük kod bloğunuzdur! O çok büyük. Çok kötü tasarlanmış bazı kodları güzelleştirmek için büyük acılar çeken birçok insan örneği görüyorum.

ReSharper olmasaydı hala temiz kodum olurdu, ama o kadar da güzel olmazdı.

Kodlama süremin ~% 5'inden fazlasını güzelleştirmek için harcamam gerektiğini düşünüyorum. Bu, editörüm ne kadar güçlü ve o kadar yetkinse, o kadar çok şey yapabilirim.

Görünüşe göre hiç kimse şirketinizin en çok ilgisini çeken şeyin ne olduğu anlamına gelmiyor mu?

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

Örneğin, şirkete, yazılım zamanında hazır değilse, size ödeme yapılmayacağına dair bir fıkra ile anlaşıldığını söyleyin (sonuçta bizden sonra ödeme aldığımızı sanmam da başımıza geldi). Evet, temiz kod önemlidir, ancak daha önemlisi kodun ödeme gününe göre çalışmasını sağlamaktır!

Başka bir örnek - şirket kötü durumda ve bir miktar para toplaması gerekiyor. Tahmin et kaliteyi kim önemsiyor? Daha sonra düzeltebilirsiniz, gerekirse, yalnızca gönderin!

Bir argüman "Neden satıp berbat kod yazmalıyım?" Olabilir. Peki, şirketiniz neden size her ay iyi bir çek ödemeli? Seçenekler, arkadaşım. İdealizmin peşindeyseniz, Özgür Yazılım Vakfı'nı deneyin ; Çok güzel şeyler yaptıklarını duydum (bunu kastediyorum ve FSF ve OSS'ye saygı duyuyorum).

İşlerin diğer tarafında, kullanımda patlayıcı bir büyümenin beklendiği bir projede çalışıyorsanız (bu projeksiyonların neredeyse hiçbir zaman doğru olmamasına rağmen), en iyi kod kalitesine sahip sağlam bir temel hazırlayın; proje için daha büyük maliyet.

Programcılar 'temiz' kodu seviyor, bu ne anlama geliyorsa. Neyin temiz olduğu konusunda hemfikir değiliz, ama seviyoruz. Ancak, bazen sadece kullanılabilirlik ve doğruluk kadar önemli değil. Bunlar eşanlamlı görünebilir, ancak görünmüyorlar - 4 saat içinde gerçek bir Perl korsanı tarafından iki kez kullanılma ve atılma niyetiyle yazılmış bir kod gördüyseniz, temiz olmadığını kabul edersiniz, ancak işe yaradığını kabul edersiniz.

Bazen, ego bir yana, sadece çalışmasını sağlamalıyız. Kötü kodun bir alışkanlık olarak yazılmasını önermediğimi unutmayın; Sadece gerekli olabileceğini işaret ediyorum. Mükemmellik, şirketinizin sahip olamayacağı zaman alır. Bu nedenle, işvereniniz sorun yaratmıyorsa, yazılım geliştirir ancak ihtiyaç duyuyorsanız, sadece çalışma kodunu yazın, 'temizliği' dikkate almayın. Bu sadece 'Tek beden herkese uyar' cevabı değil - öncelik vermelisin.

"İyi görünmek" ve "zarif, kusursuz bir şekilde anlaşılabilir ve idare edilebilir" olmaktan emin değilim.

Kod yazmaya çalışıyorum, "zarif, kusursuz bir şekilde anlaşılabilir ve bakımı yapılabilir". Bu kriterleri daha iyi karşılayabilmek için kendi kodumu refactor yapıyorum.

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

Kodun "iyi görünmesi" için, istediğiniz her şeyi gerektiği gibi girip yerleştirecek birçok otomatik araç vardır.

Hiçbir şey çok fazla asla iyi değildir.

Bununla birlikte, "kirli" koduyla dikkat edilmesi gereken önemli bir şey, kolayca " kırık pencerelere " yol açabilmesidir . Kod çok kötü biçimlendirilmişse, kod tabanındaki yeni kişilerin çoğu, yazılımın çalışma durumunu etkileyebilecek aşağı doğru bir spiral oluşturacak şekilde bakım ve evrimle iyi bir iş yapma eğiliminde hissedebileceklerini düşünüyorum.

Bu nedenle, kodda belirli bir temizlik düzeyi sağlamak, diğer geliştiricilerinizden daha fazla yarar sağlar. Buna fazla zaman harcamayın (~% 5'den bahsedilmiştir). El işlerini otomatikleştirmek için el sanatı araçlarını kullanmayı öğren (bu durumda kod biçimlendirme). Yaptıklarınız için sorumluluk alın ve daima şirketiniz / müşterileriniz / kullanıcılarınız için en yararlı olduğunu düşündüğünüz şeyi yapın.

Bu Bob Martin'den Temiz Kod'dan bir alıntı:

Bu noktaya gelmek için, ya doktor olsaydınız ve çok aptalca zaman geçiriyordu, çünkü ameliyat için hazırlıkta tüm saçma yıkamayı bırakmanızı isteyen bir hasta varsa? Açıkça, hasta patrondur; ve yine de doktor kesinlikle uymayı reddetmelidir. Neden? Çünkü doktor hastadan ve enfeksiyon riskleri hakkında hastadan daha fazla şey biliyor. Doktorun hastaya uyması profesyonelce olmaz (suçu önemsemeyin).

Bu yüzden programcıların, karışıklık yapmanın risklerini anlamayan yöneticilerin isteğine boyun eğmesi de profesyonelce değildir.

Bence "temiz kod", fizik / mühendislik / matematik sınavlarına yazdığınızdan daha temiz veya daha temiz olmalıdır. Çok dağınıksa, sınıf öğrencisi çalışmanızı anlamaz ve doğru olsa bile muhtemelen yanlış işaretler.

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

Elbette, birisinin tutarlı bir kod stili olan bir şey programladığı ve beni hala çıldırttığı zamanlar vardır. Ö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öntemleriyle ve ifadeler ve satırları 80 karakterden daha uzun olan çok ve çok sayıda iç içe geçmiş ifadeyle daha kötü görünüyor. Ama yine de beni rahatsız ediyor :)

Kodu temizlemek için çok uzağa giderim. Böceklerin göze çarpmasına büyük ölçüde yardımcı olduğunu düşünüyorum.

"Lanet şeyi şimdi gönder" konseptine katılmıyorum, çünkü temiz kod geleceğe bir yatırımdır. Ayrıca çok fazla yazılım çok fazla hatayla birlikte gelir. Bence bir hatayı çözmek, yeni bir özellik uygulamaktan daha iyidir.

Ayrıca programcı üretkenliği tahminlerine bakarsanız, çok kötü puan aldığımı sanmıyorum. Temiz kod yazmak bir alışkanlıktır ve bir programcı olarak ne kadar deneyim olursa, o kadar verimli olur. Eğer biri hiç denemezse, belli ki, hiç kimse onunla tecrübe edemez.

Dikkate alınması gereken diğer bir nokta, çoğu geliştirici zamanının okuma koduna gitmesidir, bu nedenle okunabilir kod okuma harcanan zamanı büyük ölçüde azaltır. Örneğin belgelenmemiş algoritmaları anlamak pahalı olabilir ve yeni hatalar davet edebilir.

Kesinlikle kaçırdığım ve bir gün geçirmek istediğim bir şey, özellikle başkalarının kodlarını okurken bir süre gerçekten zaman kazandıracak olan, stilime uyarlayabildiğim otomatik bir kod biçimlendirici.

Temiz kodlamanın hiçbir zaman gerçekleştirmeme riski taşıyan mükemmeliyetçilikle bağlantısı vardır, ancak daha sonra yatırım yaptığınız ve kendi zarif kod parçalarınızı yeniden kullandığınızda, deneyiminizle birleştirdiğiniz zaman, bunun temelde bir sorun olduğunu düşünüyorum. yaşlandıkça, dağınık kodlayıcılardan çok daha üretken olacak ve böcekler tarafından daha az rahatsız olacaksınız.

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

Sadece "makyaj kodu" ndan kaçının. Dışarıda tamamen kibirsiz (veya bir OKB nedeniyle) işler yapan başka geliştiriciler var. Külotlarım o insanlarla gerçekten çarpılıyor.

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

Sınırlı deneyimlerimde bulduğum şey, insanlar 'temiz kod' hakkında şikâyet ettikleri zaman, çirkinliğin genellikle kodlama sözleşmesinden ziyade korkunç bir çözümün sonucudur.

Daha temiz kod yazmak için çaba sarf ettiğimi söyleyebilirim, ancak zaman kısıtlamaları nedeniyle veya zor bir şey üzerinde çalışıyorum. Çalışmaya odaklanırken dağınık olma eğilimindedir. Sonra geri dönüp gözden geçirirken temizleyeceğim. Koda dönerseniz ve hafızanızı yenilemek için çok zaman harcamak zorunda kalırsanız, yeterince yorum yapmadınız.

Temiz kod iyidir ancak her şey gibi, sadece yeterince temiz olması gerekir. 5 satır kod 4 boşluk ve bir satır 5 boşluk girinti okuma zorluğunu arttırmaz.

Yaptığın şeye bağlı olduğunu düşünüyorum. Eğer bir kavram kanıtı uygulaması yazıyorsam temelde kovboy kodlamamı kıçımı kapatıp geriye bakmayacağım. Bir süredir üzerinde çalışacağım bir uygulama üzerinde çalışıyorsam, bundan bir ay sonra anlaşılabilir hale getirmenin yanı sıra, yeterince iyi kodladığımdan emin oluyorum.

Sanırım kodunuzu şekillendirmek biraz şüpheli. Yukarıdakilerin söylediği gibi, işiniz biçimlendirilmiş bir kod değil bir ürün yapmaktır, ancak en azından birinin tanımlanmış bir yorum ve kodlama tarzıyla yapışması gerektiğini söyleyebilirim. Deve kasalı değişkenlerin yarısını ve diğer yarı Macarca'yı görmekten nefret ediyorum.

Ayrıca, 'temiz kod' ile ne demek istediğine de bağlı.

Bunu yaptığımı itiraf ediyorum; ve yararı her gördüğümde sinirlenmiyor. Sanırım okuması daha kolay ve bu yüzden de böcekler daha belirgin hale geliyor; ama asıl sebep şu ki çirkin koda dayanamıyorum.

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

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

okumaktan daha kolay

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

Bu, daha sonra hata ayıklama yaparken gözden kaçmanın daha kolay olduğu anlamına gelir.

Ayrıca, PHP'de istediğiniz sayıda rasgele kod bloğuna izin verilir. Bunları mantıksal görevleri gruplamak için kullanıyorum:

// do x
{
    // ...
}

// do y
{
    // ...
}

Bu, ilgili koda açık bir tanım ekler.

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

Şirket standartlarına uyarak kodumu yazıyorum. Eğer "hazırladım" ı istersem, bir kod güzelleştiricisini çalıştırabilirim.