Tutarlı bir kodlama stiline sahip olmayan iş arkadaşlarınızla mı uğraşırsınız?

Stilsel olarak kötü kod yazma eğiliminde olan birisiyle çalışırken ne yaparsınız? Bahsettiğim kod genellikle teknik olarak doğru, makul bir şekilde yapılandırılmış ve hatta algoritmik olarak zarif olabilir, ama sadece çirkin görünüyor . Elimizde:

• Farklı isimlendirme ve başlıklar (karışımı underscore_styleve camelCaseve UpperCamelve CAPSaynı işlevi daha fazla veya daha az tesadüfi farklı değişkenlere uygulanır)
• Tuhaf ve tutarsız boşluklar, örneğin Functioncall (arg1 ,arg2,arg3 );
• Yorumlarda yanlış yazılan kelimeler ve değişken adları

Çalıştığım yerde iyi bir kod inceleme sistemimiz var, bu yüzden en kötü şeyleri inceleyip düzeltiriz. Bununla birlikte, 50 satırlık bir kod incelemesi göndermek için "kendinize bir boşluk ekleyin. 'İtalyan'ı doğru şekilde heceleyin. Bu büyük harfleri değiştirin."

Bu kişiyi bu tür detaylarla daha dikkatli ve tutarlı olmaya nasıl teşvik edersiniz?

Kodlama sözleşmesi üzerinde anlaşmaya varın

Bu bir çağrı cihazı olsa bile. Tüm ekibin oturmasını ve herkesin tümünün kullanabileceği temel çalışma kodlaması sözleşmesi üzerinde hemfikir olmasını öneriyorum.

Bence yaptığın şeyi yapmaya devam etmek zorundasın. Açıkça bir kodlama kuralları seti hazırlayın ve kod incelemeleri sırasında bunları zorlayın. Bir geliştirici, bir şeyi kontrol etmeye çalıştığında her seferinde 50 veya 100 satırlık "Buraya bir boşluk ekle" ve "İteratör" ü doğru şekilde heceleyin "alırsa ve gerçekte tüm bunlar düzeltilmeden önce check-in yapmasına izin verilmez. Sadece güçlük önlemek için temizleyici kodu yazmaya başlayacağım.

NimChimpsky'nin önerdiği gibi, bunları kendiniz giderirseniz, sonsuza dek bu kişiden sonra temizlik yapacaksınız.

Değişken adının yazım hatalarını ve biçimlendirmesinin önemli olmadığını söyleyen herkesi BS olarak adlandırıyorum. Açıkçası, sadece kendi kodlarını okudular. Ve oradaki kelimeye dikkat edin - okuyun. Çok sayıda yazım hatası içeren bir kitap okuduğunuzu, çok biçimli biçimlendirmeyi, tutarsız satır aralığını ve birçok kaynak kodunda yaygın olan diğer tembelliklerin bulunduğunu hayal edin. Bu sıkıcı olurdu.

Sözdiziminizin çalışması için% 100 doğru olması gereken bir meslek için, gerçek bir geliştiricinin temiz ve tutarlı bir kod stiline sahip olmaması için hiçbir sebep yoktur. Başka bir şey eksiklik ve tembelliktir. Her zaman titizlikle biçimlendirilmiş kodun uygulamadaki doğruluğunu sorgularım.

Çalıştığım yerde iyi bir kod inceleme sistemimiz var, bu yüzden en kötü şeyleri inceleyip düzeltiriz. Bununla birlikte, 50 satırlık bir kod incelemesi göndermek için "kendinize bir boşluk ekleyin. 'İtalyan'ı doğru şekilde heceleyin. Bu büyük harfleri değiştirin."

Kendim değiştiririm ve kodda kibar bir yorum eklerdim.

bu, daha önce belirtilen soruya göre bir stil rehberi olduğunu varsayar:

İyi bir kod inceleme sistemimiz var

Bu yüzden benim önerim son çare, bir e-posta ya da her neyse, kendiniz değiştirmenin ve yorum bırakmanın en hızlı yolu olduğunu düşünüyorum.

Sınıfların ve değişkenlerin isimlendirilmesi gibi sözleşmelerin önemli olduğunu ve takip edilmesi gereken şık ve etkili bir kod olduğunu düşünüyorum, ancak cevabımın birçok kez indirgenme riski altında olduğunu, genel olarak "güzel kod" paradigmasını söylemeliyim. etrafında çok itilir IMHO çok fazla abartılıyor.

Öncelikle, bunu yazan geliştirici ilk etapta sürdürmek zorunda kalacak ve eğer bir otobüs tarafından vurulursa ve başka bir programcı nasıl çalıştığını çözemez, çünkü kodun "güzel" olmadığı söylenebilir. Diğer geliştirici zaten çok iyi değil. Dışarıda bir sürü otomatik formatlayıcı / güzelleştirici var, bu nedenle herhangi biri gerektiğinde kodu güzelleştirmek için, "bölgedeki" akışta "olurken zaman kaybetmeden herkes bunları kullanabilir.

Lütfen buraya kodlama yaparken spagetti / kovboy tarzını desteklemediğimi unutmayın, aslında çok güzel bir şekilde biçimlendirilmiş spagetti kodu (4-5 ekrana yayılan işlev gövdeleri, farklı kaynak kod dosyalarının etrafına dağılmış global değişkenler, genellikle kötü ad seçimleri) görüyorum. , vb).

Meslektaşlarımdan biri html'yi cildimin taramasını sağlayacak şekilde yazıyor. Benim html'imin güzel ve iki boşluk girintisi ile yapılandırıldığını, aynı satırda veya daha sonra ayakta durmak için kolunu atması gereken bazı sarhoşlar gibi bazı sarhoşlar gibi etiketlenen parçalara çarptığını hayal edin. Yeni çizgiler nadiren girintilidir, ancak öyleyse, galaksinin bir kısmında irrasyonel sıcaklık değerlerini yayan bir şekilde basamakları bu tür girintide kullanılan boşlukları veya sekmeleri yansıtacak şekilde yayılan oldukça kaotik bir kara delik olduğundan eminim. bu kadın tarafından. Şanslıysam, " </input>" ile kapalı bir giriş etiketi göreceğim . Tamamen kabus anlayabilirsin.

Kimse bunu anlamıyor gibi görünüyor; buradaki çoğu yükselişin, organize kodun veya organize edilmemiş kodun nasıl olduğunu görmek, sandviçlerimizin üzerine İsviçre peyniri veya amerikan peyniri koymamız arasındaki fark gibi değil, yani gerçekten daha az umursayabilecekler. Kaydırmaya başladım çünkü başka bir projede strese girdim ve geliştirmek istediğinden önce böyle bir kodu anlamanın ne kadar zor olduğunu anlamaya başladığını düşünüyorum. Tavsiyem , kodunuzu neden basitçe yapmalarını söylemekten daha fazla tercih etmenin tercih edildiğini göstermek olacaktır .

Bahsettiğim kod genellikle teknik olarak doğru, makul bir şekilde yapılandırılmış ve hatta algoritmik olarak zarif olabilir ...

Hepsini aldığın için mutlu ol. Çoğu programcı size bu listedeki ilk şeyi verebilir. Değişken isimlendirmenin ve boşluk bırakmanın endişelenecek en az şey olduğunu düşünüyorum.

Bir stil sözleşmesi kurmanız ve kabul etmeniz gerekiyor gibi görünüyor. 3 boşluk girintisi olan, 4'ü diğerleri, Camel Case, bazıları ise undercore_case kullanan kütüphaneleriniz yoksa.

Kişisel tercihlerinizi yapmak istediğiniz değişiklikler mi yoksa izleyeceğiniz gerçek bir standart var mı? Eğer gerçek bir standart yoksa, o zaman bunu yapma. İlk önce bir standart belirleyin. Ardından, kodu standart ayarlara göre yeniden ayarlamak için ayarlanabilen bir yazılım alabilirsiniz (en azından bazı şeylerde).

Bir standart varsa, kod incelemesinde zorlamaya başlayın. Kod incelemesinde zorunlu tutmuyorsanız standarda sahip olmanın bir anlamı yoktur. Bu, bakım sırasında insanların standartlara uygun olmayan eski kodları dokunduğunda orjinal olarak karşılaması gerekmeyeceğinden, bakım konusunda çok fazla çalışma anlamına gelir.

Standart olmasa bile, değişken adlarındaki yanlış yazımların düzeltilmesi konusunda ısrarcı olun (çünkü yorumlarda özellikle endişelenmeyin), koda sonsuza dek delice dokunan herkesi tahrik edeceklerdir.

Kodlama standartlarının belirlenmesi gerekir, böylece herkes ne olduklarını bilir ve daha sonra uygulanmaları gerekir. Kurallara uymamanın sonuçları olmalı.

İşte, bazı teşvikler vermesi gerekenler:

1. Kod incelemeleri sıkıcı ve gerekenden daha uzun sürecektir.
2. Kod daha sık reddedilecek.
3. Tarifeleri karşılanmayacak.

Eğer bu kişi bu konuda endişelenmek zorunda kalmazsa, çünkü kimse sizin kurallarınızı zorlamaz veya verimsiz olup olmadıklarını umursamaz (ve hiç kimse bu konuda hiçbir şey yapmaz), bu konuda yapabileceğiniz pek bir şey yoktur.

Özel bir sohbet etmeyi önermek ve her ikinizin de bir neden bulup bulamayacağını görmek için cazip olurum:

1. İş arkadaşı koştu mu ve birileri dün kodu istediğinden, kişi olabildiğince hızlı bir şekilde çalışmaya çalışıyor mu? Bu, bu kişiyi işlerinde hızdan çok kaliteye odaklanma konusunda bilgilendirmek için bir fırsat olabilir. "Zaman ayırın" gibi bir mantra, eğer bu ters üretken değilse faydalı olabilir.

2. Kişi çalışmalarını nasıl görüyor? Gurur hissi varsa, geliştirmek için kullanmak için bir açıya sahip olabilir. Faturaları ödeyen sadece bir iş ise, değişiklik yapmak çok daha zor olabilir. Harika bir iş yapmadıklarını ama çok yakın olduklarını biliyorlar mı?

3. Bu kişi sözleşmelere katılmıyor mu ve protestoda kodlamaya çalışıyor mu? Eğer öyleyse, o zaman büyük bir probleminiz olabilir, ancak durumun böyle olup olmadığını ya da kişinin sadece tembel olup olmadığını öğrenmeye değer mi? Burada ne tür bir motivasyon faydalı olabilir, örneğin, kişinin gelişmesini sağlamak için açgözlülüğe, gurur veya başka bir yardımcılığa itiraz edebilir misiniz? Bu sinsi ama iyi herif rotasını denemek hiçbir yerde olmazsa muhtemelen etkilidir.

4. Arkadaş Kazandırma ve Etkileme Nasıl Kazanılır? İnsanların , işe yarayacakları konusunda, ikna edici olmaları, iyileştirmelere övgü yapma ve kişiye iyi bir itibar tanıma gibi bazı önerileri vardır.

Bunun neden özel olarak yapılması gerektiğine gelince, işte birkaç neden:

1. Bir kişinin karakterinin öldürüldüğünü hissedebileceği açıkta bırakılmaktan ziyade kapının ardında daha iyi tutulan aşağılanma, eleştiri ya da diğer tatsızlık için iyi bir şans var.

2. Bu kişiyi biraz açmaya teşvik etmek istiyorsun. Buradaki zorluk, bazı insanların o kadar güvende oldukları ki, duvarlarını yıkmaları uzun zaman alabilir.

3. Mümkünse, bunu ofisten biraz uzakta yapmaya çalışmayı öneririm. Öğle yemeği için dışarı çıkın, yürüyüşe çıkın ya da bir şey yapın, böylece etrafta kendinizi biraz daha rahat hissedebilecek kadar çevreniz değişecek. Bu bir meydan okuma olabilir ve kişiyi tanımak ister, ancak buradaki fikir ofiste bazı kişilerin burada yardımcı olmayacak bir çalışma maskesi takmalarıdır.

4. Konuşmanın oldukça ısınması veya çirkinleşmesi için hazırlıklı olun, ancak diğer kişiyi meşgul tutarsanız ve iyi bir diyalog kurabiliyorsanız, bu iyi bir işaret olabilir. Bazı insanlar olayları açıkta tutmaktan hoşlanırken, diğerleri bazı şeyleri yapmanın daha ince yollarını tercih edebilir. Önemli olan empati kuracak ve kendi taraflarını anlamaya çalışacak kadar çok kişiyi dinlediğinizden emin olmaktır.

Biçimlendirme sorunlarını arayan bir JUnit testimiz var. Yapının bir parçası olarak çalışır. Açılış parantezleri arasında,, sırasında veya arasında boşluk bırakarak sürekli ısırıyordum. Ancak kodumuz tutarlı bir şekilde biçimlendirilmiş.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

Gibi kod güzelleştirme unscrutify senin sorunların bazılarını çözmek mümkün olacak. Bunun için para ödemeye hazırsanız, parasoft gibi kaynak koduna kuralları yerleştiren üst düzey yazılımlar vardır . Parasoft, kodun tek tip bir tarzda yazılmasını zorunlu kılar. Sen de kendi kurallarını koyabilirsin. Bu tür araçlar kullanıldığında, geliştiriciler tek tip tarzı kullanmaya zorlanır. Ve bir süre sonra buna alışacaklar.

Eclipse kullanıyorsanız, Java Editörleri için İşlemleri Kaydet'i etkinleştirin ve herkese bunu kullanmasını söyleyin. Bu, her tasarrufta biçimlendirme sorunlarını düzeltir, ancak hatalı büyük harfleri düzeltmez. Yine de oldukça yardımcı olabilir!

Stil kurallarını takip etmek ne kadar zor? Yazım hatalarını anlıyorum ama gerisi özensiz düşünme ve kodlamanın bir göstergesi. Üretim koduna gelince daha tutarlı olmaları gerektiğini söyleyin, çünkü yalnızca bakacak olanlar değiller. Üretim kodunu tutarsız bir tarzda yazmak sadece kaba, bencil ve düşüncesiz.

LOL. Kodumdan kesinlikle nefret edersiniz. Hayatımı kurtarmak için heceleyemiyorum ve umrumda değil.

Fakat biliyorum ki bazı insanlar aslında bu şeyleri önemsiyor.

Değişmezlerse o çirkin kodu yazan kişiyi kovmanızı ve sonra gerçekten güzel şeyler yapan birini bulmanızı ve kod yazabileceklerini ummanızı istiyorum.

genellikle teknik olarak doğru, makul bir şekilde yapılandırılmış ve algoritmik olarak da zarif olabilir

ve eğer o zaman yapamazlarsa en azından kırık güzel kodu müşteriye gösterip bunları satabilirsiniz!

Ama ciddice. Önce gerçekten önemli olan şeylere odaklanın. Dışında "hassas hassaslıklarımı incitiyor" dışında iyi ve sağlam bir sebep bulamazsanız, şimdilik bunu görmezden gelin. Eğer gerçekten önemliyse, o zaman kişiyle birlikte oturun ve onları bu önemi konusunda ikna edin. Sınıf düzeyi, yöntem düzeyi, paylaşılan, sabit değişkenler arasındaki farkı anlatmayı kolaylaştıran standartlar gibi şeyler fark yaratır. Söz konusu kodlayıcı mesleğini hiç umursamıyorsa, doğru şeyi anlayacak ve yapmaya çalışacaklardır.

Biçimlendirme hakkında (veya bu konuda kolayca önlenebilir hatalar)% & # $ vermeyen dış kaynaklı kaynaklarla çalışırken çözümüm, derleme sunucusunun bunu zorlamasıydı. Her gece kodları kontrol eden, Jalopy'yi ve bulma hatalarını kontrol eden bir CI sunucusu işi yarattım, sonra kodu tekrar kontrol ettim. Diğer takım standart kod kurallarını kullanmamayı zorlaştıracaklarını öğrendiğinde bir kez daha kullanmaya başladılar. Standart bir formatı korumak için IDE.