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


54

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?


Yerleşmiş ilkelere göre "temiz" kod yazma girişimlerimin hepsinde, bu tür öncüllere dayanarak belirli bir ölçeği korumanın o kadar kolay olduğunu asla bulamadım. Çok daha önemli olan, onun güvenilirliği ve ne kadar iyi test edildiği ve bunun amacı için ne kadar uygun olduğuydu (tasarım kadar uygulama ile de ilişkiliydi). Dünyadaki tüm temizlik bunlardan hiçbirinin eksikliğini telafi edemez ve bazen kullanmaya devam ettiğim en güvenilir kod en temiz değilken, en temizim her zaman en güvenilir olanı değildi.

Her şeyden önce - okunabilirlik, güzellik, KATI, başka herhangi bir şey - güvenilirliği ve "istikrarı" (kitabımda değişmeyen olmanın kalitesi ve daha da önemlisi, değiştirme ihtiyacı ya da eksikliğini) önceliklendirmek için faydalı buldum Daha ileri). Güvenilir ve istikrarlı şeyler benim için zaman testini sürdüren şeylerdir ve bazen pek çok insanın kitaplarında pek temiz değillerdir (en çok kullanılan kodlarımın bazıları 80'lerin sonlarına ve 90'ların başlarına dayanan C kodudur) artık herkesin anlayamadığı - hala çok güvenilir bir şekilde çalışan bit korsanlık gibi şeyler uygulayan şeyler.

Yanıtlar:


52

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”.


45
Teknik borcunuz ( en.wikipedia.org/wiki/Technical_debt ) sizi “teknik iflas” durumuna getirmediği sürece (yeni özellikler getirilemiyor, bir parçanın sabitlenmesinin düzeltilmesi vb.) Ve bir göz atın üzerinde katılıyorum.
Matthieu

3
@HolleyLley Anlaştık. Sadece temiz kod yazan geliştiricilerin yazması gerektiğine inanmıyorum. Bu sahte. Dağınık kod olur. Geliştiricilerin sadece başından itibaren temiz ve doğru kod yazması gerektiği fikri bir yanılsamadır. Etki alanı konusundaki anlayışımız düzeldiğinde, her zaman tekrar ziyaret ettiğimiz ve yeniden yönlendirici olduğu fikrini tanıtırım.
48'de spong

40
"Sadece şu lanet şeyi yolla" konusundaki sorun, yönetimin yeniden yapılanma nedenlerini daha sonra almayacağından, ancak ŞİMDİ görünmeden yaparsanız, her şey iyi olacak.
İş

5
Başka bir yanılsama daha sonra temizlemek için zamanınız olduğunu düşünmektir. Bu olmayacak. Gönderilecek başka şeyleriniz olacak. Dağınık kod vermemelisin. Bu arada, son tarihler üzerinde de çalışmalısın, temiz kod yazmanın ne kadar zaman alacağını bilen teknik adamsın. Bu, çılgınca bir süre boyunca temizlik ve temizlik yapmak anlamına gelmez, bu, kodu göndermeden önce refactor zamanı hesaba katılması gerektiği anlamına gelir.
Steve Chamaillard

3
"Daha sonra refactor yapabilirsiniz" [alıntı gerekli]
Carl Leth

39

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.


13
Kod açıkça tarafımca okunana kadar parlatıyorum. İki hafta sonra geri dönersem ve ne yaptığımı bulmak zorunda kalırsam, başkalarının kolayca anlayabileceği kadar açık değildir.
Robert Harvey,

14
Şık kod, doğal olarak daha fazla bakım gerektirebilir ve okunması daha kolay olduğunu düşünüyorum.
Craige

6
+1, geçmişte mükemmel bir şekilde tasarlanmış SPAGHETTI KODU gördüm.
Jas,

23
Bu düşünceye katılıyorum, ancak kodumu üyeler arasında doğru sayıda boşluk bırakıyorum ve bunu yapmayan insanlar tarafından rahatsız ediliyorum. Yapılması kolay bir şey (StyleCop gibi otomatik araçlarla daha da kolaylaştı) ve sağladığı tutarlılık, gereken az çabaya değer.
Robert Harvey,

3
@ sunpech: Temiz bir şekilde yazın ve temiz tutmak çok daha kolay.
David Thornley

24

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.


2
Hayır, zamanınızı ve bütçenizi ne zaman ve ne zaman varsa kodunuzu temizlersiniz. VE bunu yapmanın riski, yapmama riskinden daha küçüktür. Üretim ortamlarında bu, mevcut kodu daha güzel hale getirmek için cilalamayacağınız anlamına gelir, bu sadece maliyet açısından uygun değildir ancak yeni hatalar ortaya çıkma riskine neden olur.
12'de

Bu aynı zamanda, hangi yazılım geliştirme köşesinde çalıştığınıza da bağlıdır. Bir sonraki aşama kod temeli meselelerden dolayı daha uzun zaman alacaksa, müşterisine masraf ödemekten çok mutlu olan bir Dijital Pazarlama ajansı için çalışırdım. Mevcut sorunları çözmek için dev sırasında daha fazla zamana yönelik itişimiz, işletme için daha fazla paraya eşit uzun süreli dev zaman lehine düşürüldü.
Simon Whitehead

1
Buna katılıyorum, Kod vermelisin, ancak düzeltemez / güncelleyemez / yükseltemezseniz, verdiğiniz kod kod değil, para deliğidir. Bu fikirle savaşan insanların kötü ortamlarda çalışmak için kullandıklarını ve asla yaşamadıkları bir sistem olduğunu savunuyorum. Hem temiz hem de temiz olmayan kodları korudum ve size temiz kodun bakımı ve geliştirilmesi için çok daha ucuz ve daha hızlı olduğunu söyleyeceğim.
Jdahern

21

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.!


Katılmıyorum - bir arabanın içindekilerin aksine, yazılım paslanmaz (Joel'in söylediği gibi). Bir işletim sistemi yükseltildiğinde, yazılımın da yükseltilmesi gerektiğini, ancak bunun farklı bir şey olduğunu iddia edebilirsiniz. Ayrıca, ben do temiz kod yazmak, ama benim katkıların en önemli özelliği olduğunu düşünmüyorum.
K.Steff

18

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 .


15

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 .


Kabul. Çoğu kişi, ilk kez gönderilecek / bırakılacak temiz kod yazmayacak. İşi yapmak için koli bandı var.
31'de spong

2
Koli bandı ile yeter! Spolsky tanrı değil. Pantolonunu tıpkı bizim gibi tek bir bacağına koyar!
İş

5
Temiz kod yazmanızın bir nedeni, en kısa zaman çizelgesindeki (birkaç saat) herhangi bir zamanda temiz kod yazmanın kirli koddan daha hızlı olmasıdır. Değişken ve yöntem adları hakkında birkaç saniye düşünmek, son tarihi kaçırmanıza neden olacaksa, siz ve / veya iş arkadaşlarınız kodunuzla karıştığında kaybedeceğiniz değerli zaman geçerliliğini yitirir. Kod sesini neredeyse tek kullanımlık kılıyorsunuz, yazdığınız gibi, bakım olmadan bir süre kullanacak ve sonra emekli olacaksınız. Belki kendine özgü durumunuzda kod atılabilir. Bunun on yıllık bir pratik deneyim içerisinde olduğunu hiç görmedim.
PeterAllenWebb

1
@peter: Ve yirmi yılda, her kodun temiz olduğu bir yer görmedim. Nadiren yarım olan bir yer bile gördüm . Nerede çalışıyorsun? NASA?
Satanicpuppy

2
@Satanicpuppy Zamanımda çok fazla kirli kod gördüm ve payımı yazdım, ancak neredeyse hepsi zamanımı veya bir başkasının zamanını boşa harcıyordu. Bir kaç saatten daha uzun bir zaman diliminde temiz kodun kirli koddan daha HIZLI yazılabileceğini iddia ediyorum.
PeterAllenWebb 21:11

7

"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.


5

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.


4

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.


3

"İ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.


2
Kötü biçimlendirilmiş kod gördüğümde bu beni daha fazla rahatsız ediyor. Yazan kişi, bu araçlardan birini, onlar için yapmak için kullanabilirdi. Ayrıca, en sık olarak, kutsal bir karmaşa oluşturmak için sekmeleri ve boşlukları karıştırırken ortaya çıkar.
jsternberg

3

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.


3

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.


2

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.


2

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 :)


2

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ı .


1

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.


Kanat veya (daha da kötüsü) kutu yorumu gibi, demek?
David Thornley

1

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.


1

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.


1

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ı.


0

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.


0

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 .


11
Bence zaten bunu yapan bir şey icat ettiler - buna fonksiyon denir. Kendinizi bu bloklardan birini yaratırken bulduğunuzda, bunun yerine bir fonksiyon yaratmalısınız. Oradan çalıştırmak istemiyorsanız, işlev çağrısını yorumlayın (backhanded yorum yapmak yerine)
riwalk

1
@ stargazer712: Tanımlanmış isim alanları olmadığı için php'nin işlevlerinden nefret ediyorum. Kaçınılmaz olarak, birinin kodunu okuduğu, bir tanesinin üstünde "dahil" var, her biri 4 tane daha içeren 5 şey daha içeriyor, ve sonra fonksiyon tanımını bulmak için tüm kod tabanında bir arama yapmam gerekiyor. Çok sinir bozucu.
Satanicpuppy

Genellikle bu, bir işlev bildirimi için geçerli olmayan koddur. Örneğin. Yeniden kullanma imkanı, ilgili yerel kapsamdaki değişkenlerin hesaplanması / ayarlanması vb.
Craige

Öte yandan, yeniden kullanma imkanı olmayan kod nadirdir. Kendinizi tekrar kullanılamayan bir çok kod yazarken bulursanız, geliştirilebilmesi için iyi bir olasılık var.
riwalk

-2

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


2
Genel olarak olanlar dışında, başkasının, temizlik işine giremediğiniz şeyleri temizlemeye çalışırken bir güzelleştiriciden geçirmesi biter.
riwalk,

@ Stargazer712 tam olarak bu yüzden şirket standartlarına
uymanın

@ Maud'Dib, o zaman sorun şu ki sonuç sadece güzelleştirici kadar iyi. Yatay beyaz boşluk tamamen kapsamla ilgilidir (ve bu nedenle çok iyi temizlenir), dikey beyaz boşluk genellikle niyetle ilgilidir (ilişkili olanı gruplandırır) ve çok zayıf bir şekilde temizler. Sonuç olarak, geliştiricilerinize merhamet edin.
riwalk,

@ Stargazer712 Sorun, "şirket standartları" dışında, her şey tamamen bir zevk meselesidir, özneldir. örneğin, iş arkadaşımın onlardan olumlu olarak nefret ettiği yerlere boşluk bırakmayı seviyorum. Bana güzel görünmesini sağladım ve bu benim yaptığım kadarıyla.
Muad'Dib

1
"Güzelleştiriciler" konusunda dikkatli olun, çünkü birleşme işlemlerinin üstesinden gelinebilir (ilk elden deneyimim var :)).
Juha Untinen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.