Tüm geliştiriciler için aynı kod formatını uygulamak iyi bir fikir midir?

Projemizde tek bir standart kod formatı uygulamayı düşünüyoruz (Eclipse'de kaydetme işlemleriyle otomatik format). Sebep şu anda, birkaç geliştiricinin kullandığı kod formatlarında, bir geliştiricinin başka bir geliştiricinin kodu üzerinde çalışmasını zorlaştıran bir fark olduğu. Aynı Java dosyası bazen 3 farklı format kullanır.

Dolayısıyla, avantajın açık (okunabilirlik => verimlilik) olduğuna inanıyorum, ancak bunu dayatmak iyi bir fikir olabilir mi? Ve değilse, neden?

GÜNCELLEME
Hepimiz Eclipse kullanıyoruz ve herkes planın farkında. Zaten çoğu tarafından kullanılan bir kod formatı var, ancak bazıları kendi kod formatlarına uymayı tercih ettiği için zorunlu değil. Yukarıdaki nedenlerden dolayı bazıları onu zorlamayı tercih eder.

Şu anda standart bir kod formatının uygulandığı ve dosyayı kaydettiğinizde olduğu gibi otomatik olarak formatlanan bir yerde çalışıyorum. Şirketin yeni bir üyesi olarak, genel biçimlendirme kurallarının bana "bu adamlar ne yaptığını biliyor" diye sıcak ve bulanık bir his verdiğini öğrendim, bu yüzden daha mutlu olamadım. ;) İlgili bir not olarak, genel formatlama kuralları ile Eclipse'de çoğu, Hata olarak ayarlanmış, çoğu Uyarı olarak ayarlanmış ve neredeyse hiçbiri Yoksaymaya ayarlanmamış olan bazı kesin derleyici uyarı ayarlarını da uygularız.

Bir projede tek bir kod formatı uygulamanın iki ana nedeni olduğunu söyleyebilirim. Öncelikle sürüm kontrolü ile ilgili olmalı: herkes kodu aynı şekilde biçimlendirirken, dosyalardaki tüm değişikliklerin anlamlı olması garanti edilir. Artık burada veya orada bir boşluk eklemek veya kaldırmak yok, bir dosyanın tamamını, sadece bir ya da iki satırını değiştirmenin "yan etkisi" olarak yeniden biçimlendirmek bile yok.

İkinci sebep ise programcıların egolarını denklemden çıkarmasıdır. Herkes kodunu aynı şekilde biçimlendirirken, artık kimin ne yazdığını kolayca söyleyemezsiniz. Kod daha adsız ve ortak bir özellik haline gelir, bu nedenle hiç kimsenin "başkasının kodunu" değiştirme konusunda huzursuz olması gerekmez.

Ana sebepler, diğerleri de var. Eclipse kaydettiğimde otomatik olarak benim için yapacağı için kod biçimlendirmesini düşünmekle kendimi rahatsız etmek zorunda olmadığımı rahatlatıyor. LaTeX ile belge yazmak gibi: Bu daha sonra formatlanır ve yazarken endişelenmenize gerek yoktur. Ayrıca herkesin kendi stiline sahip olduğu projelerde de çalıştım. O zaman, başka birinin kodunu kendi tarzınızda değiştirmenin uygun olup olmadığı ya da onun tarzını taklit etmeye çalışmanız gibi aptal ve anlamsız sorunları düşünmeniz gerekir.

Durumunuz için düşünebildiğim ortak kod formatlama ayarlarına karşı tek argüman, halihazırda devam etmekte olan bir proje olduğu için, tüm dosyalarda gereksiz gereksiz değişikliklere neden olacak ve gerçek dosya geçmişlerini bertaraf edecek. En iyi senaryo, ayarları bir projenin başından itibaren uygulamaya zorlamaya başlayabilmenizdir.

Her profesyonel yazılım geliştirici, ana hatlarıyla belirttiğiniz nedenlerden ötürü stil üzerine yapılan geleneksel savaşlara girmek yerine (iyi) bir standart benimsemeyi tercih edecektir.

Pek çok yazılım geliştiricisi evangelical savaşları sürdürürler ......

Takım içindeki pozisyonunuza ve takım dinamiğine bağlı olarak, savaşı kazanmanın mümkün olmadığına karar verebilirsiniz. Bu durumda, başlamak en iyisi olabilir ...

Evet, tüm geliştiriciler için bir kod formatı stiline sahip olmak iyidir.

Kod stili biçimlerini tasarlayın ve tüm geliştiricilerin tutulması için içe aktarın.

Bu, merging'Sürüm kontrolü' sistemine kod olduğumuzda yardımcı olacaktır .

Ne kazanmaya çalışıyorsunuz, onu ne kadar anal olarak koruyacaksınız (ve "kurallarınız" da ayrıntılı olarak belirtilecek), farklı dillerde yazılmış kodlar üzerinde zorlamaya çalışacaksınız, geriye dönük olarak mevcut kodla zorlamaya çalışacak mısın?

1. Ortak bir görünüm ve kodlama hissi gerçekten de kodu daha okunaklı hale getirmeye yardımcı olabilir, aynı zamanda yanlış görünüm ve his ise daha da kötüleşebilir. _hUngarian_lpfstr notasyonu birinci sınıf bir örnek olarak :)
2. Yorum bloklarında boşlukların sayısını, yöntem adlarının alfabetik sıralamasını ve diğer saçmalıkları zorlayan "kod standartları" gördüm. Yapma bunu.
3. Farklı diller, kullanımlarında deneyimli kişilerin alışkın olduğu farklı standartlara sahiptir. Hatta bazıları bile bu standartları zorunlu kılar (Python, Cobol, Visual Studio'nun, Java'nın geleneksel olarak C stilini kullanmasını vb.
4. değiştirmek için mevcut kodu hiçbir zaman değiştirmeyin, yalnızca bu şekilde yeni sorunlar ortaya koyuyorsunuz. Bu da tüm kaynak dosyalarının yanı sıra kod bölümleri anlamına gelir. Bu nedenle, bir kişi 1000 satırlık bir dosyada tek bir satır değiştiğinde mevcut kodu yeniden biçimlendirmeyin.
5. Deneyimli programcılar, yazdıklarının yarısının otomatik onay sistemine veya hakemine "doğru bakacağını" düşünmek zorunda kalmazlarsa çok daha üretken olabilirler. Aynı zamanda temiz kod yazma alışkanlığına da girecekler, çünkü doğal stilleri arasında küçük farklılıklar olsa bile, bu işe yarıyor.

Dolayısıyla, belirli bir stil ve standardı empoze etmek için iyi nedenler olsa da, kesinlikle yapmamak için de iyi nedenler vardır.

Evet, tutarlılık nedenleriyle iyi bir fikir olduğunu diğerleri gelmiş sözü .

Sadece başka bir yerde kullanılmamış birkaç nokta eklemek istedim:

• Oracle, fiili standart olan Java için bir takım sözleşmeler yayımladı .
  • Bunları kullanmak, hangi stilin izleneceğine dair tartışmalardan kaçınmanıza yardımcı olacaktır.
  • Çok sayıda halk kütüphanesi ve açık kaynak projesi bu sözleşmeleri kullanma eğilimindedir, bu nedenle biçimlendirmelere aşina olmanız gerektiğinde.
  • Eclipse formatlayıcısının, aynı zamanda yardımcı olması gereken bu kurallara uyması için yerleşik kuralları vardır.
• Kaynak kontrol kurulumunuzda bir kanca oluşturmayı düşünebilirsiniz, böylece kod ana şubeye girmeden önce otomatik olarak biçimlendirilir.
  • Standardı takip etmeyi reddeden özellikle inatçı programcılarla savaşmaktan kaçınabilirsiniz. Çalışırken kendi biçimlendirmelerini bile kullanabilirler, bu daha sonra standart hale getirilecektir!
  • Özel biçimlendirme ayarları kullanıyorsanız (örneğin, birçok kişi "satır başına maksimum 80 karakter" konvansiyonunu görmezden gelir) kullanmazsanız, yalnızca tek bir yerde değişiklikler yapmanız gerekir.

Checkstyle eklentisini kullanan bir takımdaydım . Kullanıma hazır özellikleri kullanmak yerine, ilgilenen geliştiricilerden oluşan küçük bir komite oluşturduk. Neyin eksik olduğunu, neyin aşırı olduğunu ve neyin dövüldüğünü anlattık. Hepimiz süreçte bir şeyler öğrendik ve bu geliştirici kasları güçlendirdik.

(Kararlarımızın örnekleri: 72 karakter genişliğinde, ancak 120 karakter daha iyiydi; statik finallerde _ALLCAPS kullanmak daha iyidir; bir işlevden tek çıkış yapmak zor bir fikirdir.)

Kod incelemelerimiz olduğunda ilk sorulardan biri şuydu: "Checkstyle’i kullandınız mı?" Kodlama standartlarına uymak büyük ölçüde otomatikleştirildi ve dikkatini inceleyen kişinin seçici davranmasından uzaklaştı. Checkstyle'in bir yöntem imzasını vurgulaması, sağ tıklaması ve bir değişkeni final olarak değiştirmesi çok kolaydı. Ayrıca, girintileri ve destekleri de düzeltebilir, böylece herkesin kodunda benzer bir görünüm ve his vardır. Genel bir işlev için Javadoc'u kaçırmak mı? Checkstyle işlevi işaretleyecektir.

(Kod kokusunu kaldırmak, tutarlı biçimlendirmeden daha önemlidir. Bu, otomatik araçların bir avantajıdır.)

Daha az olarak checkstyle gibi araçlar otomatik yerleştirebilirsiniz olur empoze aynı biçim ve daha teşvik benzer bir görünüm ve his. Ve kedileri sürerken, otomatik bir araç, hassas egoları zedelemeden, becerileri geliştirmenize ve kod kokusunu azaltmanıza yardımcı olabilir.

Aynı IDE'ye bağlı kalacak ve bazı biçimlendirme araçlarını dahil edecekseniz, bu çok iyi bir fikir çünkü çok fazla çaba gerektirmezsiniz. Okunabilirliğe odaklanarak ve anal kalıcılığa odaklanarak kuralları basit tutun . Bu ölçüm çubuğu olmalı.

Sürekli olarak oluşturulmuş bir çamur topunun sadece bir çamur topundan daha iyi olmasına rağmen, zamanınız parantezlerin nereye gittiği konusunda çok seçici olmak yerine onu temizleyerek daha iyi harcanır. Yeni kapak sayfalarının TPS Raporlarında bulunduğundan emin olmakla birlikte bir kod incelemesi sırasında girintili boşlukları sayarak işlerini yapmakta olduklarını düşünen pin yöneticisine dönüşmeyin .

Kişisel tercihler tam da budur ve üretimi nadiren iyileştirir: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Varsa üstesinden gel ve bir şey yap.

İnsanların kod biçimlendirmesini uygulamalarını ve küçük ihlallerin nezaketle göz ardı edilmesini veya dokunulmamasını şiddetle tavsiye ederim. Bunun nedenleri kısaca

1. Makine en kötü zamanda ve genellikle yeni bir dil özelliği kullanırken yanlış yapar. Java, vb. Kapanışlarla nasıl başa çıkacak? Jalopy, üye işlevleriyle numaralandırmada sorun yaşıyor.
2. Programcıya şirket koduna benzeyen şirket için kod üretmenin çok makul bir yük olduğunu düşünüyorum. Tüm kodların her yerde nasıl biçimlendirilmesi gerektiği değil, kodun "burada" nasıl biçimlendirildiğini ifade etmeyi faydalı buldum. Önceki şirketleri farklı bir yol seçmiş olabilir ve bu sorun değil. Yerel dilden farklı olarak, kod kültürünüze özgü hale getirmek istediğiniz deyimler vardır.
3. Kod sözdiziminin uygulanması en iyi şekilde kod incelemeleriyle yapılır:
   1. Biçimlendirme önemliyse, kuruluşunuzu kod incelemeleri yapmaya çekmesinden daha önemlidir. Bu çok büyük bir avantaj.
   2. Bir biçimlendirme kuralı ihlal edilirse, bir insan ona bakabilir ve niyet daha temiz bir şekilde iletilirse, bir makineden daha iyi karar verebilir. Bu çok nadir görülür, ancak bazen olur.

"Okunabilirlik => verimlilik" ile ilgili olarak, kod yapısı (tek sorumluluk sınıfları ve işlevleri gibi) sizi kod biçimlendirmeden çok daha hızlı satın alır. Kod biçimlendirme bir yardımcı olabilir, ancak farklı beyinler ifadeleri farklı şekilde ayrıştırır - herkes "daha üretken" olmaz. Biçimlendirme yerine kod yapısını ikiye katlamak isterim, çünkü bu, sizi kod incelemeleri yapmaya zorlayacak ve ekibin programın nasıl çalıştığını değil, tek bir döngünün nasıl göründüğünü düşünmesini sağlayacak bir şeydir.

Domain Driven Design'ın büyük bir hayranı değilim, ancak kodun nasıl yapılandırılması gerektiği konusunda ÇOK iyi tanımlanmış bir fikri olan ve kod formatlama kurallarının bir Domain Driven Design yapılandırılmış programından doğal olarak aktığı konusunda son bir model. Yine ... DDD'yi sevmiyorum, ama çok iyi bir örnek çünkü çok iyi tanımlanmış.

Sanırım bu cevabın teması, İncelemeleri kodlayın ve kültürden ve inceleme sürecinden dışarı akış biçimlendirmesine izin verin.

Genel olarak, makul geliştiriciler kiraladığınızı varsayarsak, evrensel bir kod formatı uygulamak kötü bir fikirdir. Bununla birlikte, kod kurallarını benimsemek iyi bir fikirdir .

Her durumda okunabilirliği en iyi duruma getiren bir dizi kod biçimlendirme kuralı görmedim. Aynı şekilde, İngilizce dilinde% 100 geçerli dilbilgisi kuralları yoktur: beyinlerimiz bu şekilde bağlanmış değildir. Bu nedenle yönergeleri kullanın, ancak geliştiricilere uygun gördükleri şekilde geçersiz kılma özgürlüğü verin.

Olduğu söyleniyor, daha zor bir kural "dosya / proje zaten mevcut kod kurallarını takip" iyi bir kuraldır.

Ancak, biçimlendirmenin, kodun ne kadar mantıksal olarak organize edildiğinden çok okunabilirliğe çok daha az katkıda bulunduğunu unutmayın. Mükemmel biçimlendirme w / okunamayan spagetti kodu bol gördüm!

Bunun basit bir cevabı olduğunu sanmıyorum. Bu evet ya da hayır sorusu değil. Tarz ve adlandırma kurallarının bir dereceye kadar önemli olduğuna inanırken, bunun hakkında çok fazla zaman harcamak da oldukça kolay. Örnek olarak cevap vermek en iyisidir.

Devam ettiğim belirli bir projede hiçbir sözleşme yoktu. Her geliştirici işleri kendi yöntemleriyle yaptı. Bu takımın göreceli deneyimsizliği nedeniyle, bir sınıftan diğerine geçmek gerçekten çok zorlayıcıydı. Stil, adlandırma kuralları probleminden daha az sorun teşkil ediyordu. Bir geliştirici, Macar göstergesine (modern IDE'lerin çağında aptalca bir uygulama) olan UI elemanlarına referans verecek, biri özel üyelere bir şekilde isim verecek, diğeri onları farklı şekilde isimlendirecektir. Sadece neye baktığını hiç bilmiyordun.

Karşı uçta, bir takım inşa sürecinin bir parçası olarak StyleCop'u (bu bir .Net projesi idi) kullandı. Daha da kötüsü, varsayılan kuralların çoğunu da kullanmaları. Böylece satır aralığı veya küme parantezi yerleştirme anlamında tamamen normal bir şey yaparsınız ve yapı bundan dolayı kusar. Eşyalara sadece boşluklar ve çizgiler ekleyerek çok zaman harcandı ve StyleCop'u kullanmakta ısrar eden adamlar da dahil olmak üzere herkes hemen hemen her şeyi tamamladı. Çok büyük bir zaman ve para kaybıydı.

Bu yüzden burada anlatacağım nokta esnek olmamak cevabı değil, ama Vahşi Batı'da olmak da değil. Asıl cevap, en mantıklı yeri bulmaktır, ki bence, araçları kontrol eden otomatik araçlara sahip değil, aynı zamanda rüzgara da kongre atmamaktır.

Ortak kodlama stiline karşı temel savım, kendi stilini okumak için deneyimli bir programcının kullanılmasıdır. Elinizi belli bir tarz yazması için eğitebilirsiniz ancak gözünüzden nefret ettiğiniz bir stili anlaması için neredeyse imkansızdır. Bir programcı bir kod parçasını bir kez yazar ve geliştirme ve hata ayıklama sırasında tekrar tekrar okur. Her zaman kendi kodunu okursa, onu BAD tarzında yazmaya zorlandığından beri anlamakta zorlanıyor, çok mutsuz ve daha az üretken olacak. Bu benim tecrübemden.

Ben Eclipse ile aşina değilim ama korkunç bir fikir gibi sesleri kaydetmek otomatik format. Bir geliştirici, kodlama stilinin uygulanmış olup olmamasına bakılmaksızın kodu üzerinde tam kontrole sahip olmalıdır. 'kaydetme' işlemi, kullanıcıdan açık bir şekilde izin almadan tek bir karakteri değiştirmemelidir.

Şirketiniz kaynak kodu satıyorsa, kodlama stili daha önemlidir, ancak derlenmiş kod satıyorsanız, bu daha az alakalı olur.

Kodlama stilinin orijinal kodlayıcıyı daha az ayırt edilebilir hale getireceğini ve ego savaşlarını engelleyeceğini ummak en iyi durumda saçmalık, en kötü durumda ise salaktır. Büyük programcılar, tarzından bağımsız olarak daima zarif kodlar üreteceklerdir.

Ayrıca, belirli kod birimlerinin her geliştiricisine sahipliğini ve herkesin her bir koda serbestçe dokunmasına izin vermeme konusunda çok profesyonelim. Kodda bütün birimler geliştirmek ve bunlardan sorumlu olmak, geliştiricinin işinde gurur duymasını sağlar ve böceklerin onu aramaya geri döneceğini bilerek berbat kod geliştirmesini önler.

Son olarak, kodlama stili olan herkes her zaman kendi kodlama stilinin seçileceğini ve herkesin izleyeceğini varsayar. Tüm geliştiricilerinizden en çok sevdiğiniz kodlama stilinin standart olarak seçildiğini hayal edin. Hala kodlama stilini benimsemekten hoşlanıyor musunuz?

Hepsine hükmedecek tek bir format ... gerçekten optimal mi?

Başka birinin arabasını sürmek gibi ...

Her hangi bir araca binebileceğinizi ve araç sürdüğünüze emin olun, ancak koltuğu, direksiyon simidini ve aynaları SİZİN tercihinize göre ayarlamak için zaman ayırırsanız daha güvenli, daha konforlu ve daha az çarpma olasılığı olacaktır .

Kodla, biçimlendirme, kodu okuma ve anlamadaki rahatlığınızı etkiler. Alıştığınız şeyden çok uzaksa, daha fazla zihinsel çaba gerektirecektir. Bunu geliştiricilere vermek gerekli midir?

Şimdiye kadar belirtilen tüm avantajlara +1, ancak ...

Otomatik uygulama, göz önünde bulundurulması gereken maliyetlerle birlikte gelir:

-1 kod formatlayıcıların kod formatlama estetiğini anlamadığı gerçeğine. Kaç kez bir kod formatlayıcısına, tablo biçiminde güzel bir şekilde dizilmiş olan bir yorum bloğunu yok ettiniz? Kaç kez, karmaşık bir ifadeyi okunabilirliği artırmak için belirli bir yolla kasıtlı olarak hizaladınız, yalnızca otomatik biçimlendirmenin onu "kuralları uygulayan" ancak çok daha az okunabilen bir şey haline getirmesi için hizaladınız ?

Bazen bu şeylere geçici çözümler olabilir, ancak geliştiricilerin otomatik biçimlendiricinin kodu düzenlemeyi nasıl önleyeceğinden daha önemli bir şeyleri var.

Biçimlendirme kurallarına sahip olun, ancak sağduyunuzu uygulamak için biraz özgürlük verin.

İyi geliştiriciler yaratıcı insanlardır ve onlara sanatsal lisanslar verirler. “Basit tut” programcı mantra olmalıdır. İki kuralım var:

Kural 1: Değişkenler / imleçler / nesneler / prosedürler / HİSSELİ İSİMLER ver. Kodunuza anlam ve anlayış getiren açık isimler.

Kural 2: Kodunuzun yapısını göstermek için girinti kullanın.

Bu kadar.

Benim için, otomatik olarak uygulanan ortak bir formatın ana avantajı, değişiklik izleme ve kod incelemelerimizin değişmesine yardımcı olmasıdır. git (ve diğer kaynak kontrol araçlarının çoğu) dosyaların önceki sürümlerindeki farklılıkları gösterebilir. Ortak bir tarz uygulayarak, programcı tercihini farklılaştırır.

Stil kılavuzları ayrıca çeşitli analitik amaçlar için programatik kod ayrıştırma işlemlerini kolaylaştırır.

Google, "Google’da Teknik Borç Yönetimi ile İlgili Tecrübe Oluşturma Deneyimleri" adlı bir makale yayınladı .

Bu diller kod değil. İnsanların 6000'den fazla dili var, bu yüzden onları tercüme ediyoruz. Dolayısıyla, "kodlarınızın" iletişim kurmasını istiyorsanız, ayarlarınızı yapmanız gerekecektir. Kullanıcıların veri formatlarımızı değiştirmemiz gerektiğini görüyoruz, böylece verilerimizi kaybediyoruz.

Öyle olmadığını söyleyebilirim. Bir takım arasında ortak bir kod yapısı / formatı kesinlikle iyi bir şeydir, ancak otomatik olarak zorlamak değildir. Bu, bilgisayar tarafından değil insanlar tarafından yapılmalıdır.

Konsept ile ilgili en büyük sorunum

1. Bir formatta kod yazıyorsam ve otomatik olarak yeniden biçimlendiriliyorsa, bu formatı gerçekten öğrenmek için hangi teşvik var?
2. Bu önceki noktadan sonra, formatı öğrenmezseniz, otomatik biçimlendirme noktasının tamamı (kodu daha kolay okunup değiştirebilmek için) tamamen kaybolur. Kodu okurken biçimlendirmeyi anlamak için zaman ayırmanız gerekir çünkü bu biçimi öğrenmediniz
3. Bir gün bir sınıf yazmanın, kapatmanın ve ertesi güne tamamen farklı olduğunu görmek için geri dönmenin zor bir deneyim olacağını düşünüyorum. Yani, diğerleri kodunuzu öğrenmek zorunda değil sadece anlamına gelir Eğer kodunuzu öğrenmek zorunda.
4. Ayrıca tembel kodlamayı da teşvik edebilir. Formatı öğrenmeye zorlamak yerine, güneşin altındaki herhangi bir formatta yazabilirler ve otomatik olarak herkesin istediği şekilde görünecektir. Bu, stili öğrenemediğiniz ve hala doğru okuyamadığınız # 2'ye geri döner.

Şimdi, tamamlanmış bir projede otomatik format çalıştırmanın iyi bir fikir olduğunu söylemeye meyilli olabilirim. Bu özellik daha sonra düzeltmek / eklemek için gittiğinizde, proje için her adımda aynı adımla başlayacak. Aktif gelişim sırasında, bunun çok kötü bir seçim olduğunu düşünüyorum.

Temel olarak: Şirketin stilini öğrenmek için çalışana sorumluluğu koyun, kodlarını olmayan bir şey olmaya zorlamayın.