Kodlama standartlarında çok fazla tekdüzelik olabilir mi?


12

Çok fazla homojenlik diye bir şey var mı? Çalıştığım yerde elbette isimlendirme sözleşmeleri, mimariler, kaldıraç çerçeveleri vb. Dahil standartlarımız var.

Örneğin, ififadeler ??yerine == nullgirintiler için boşluk miktarları vb. Yerine c # null birleştirme operatörünü kullanarak bir satıra vs birden çok satırda ifade yazmak .

Bana öyle geliyor ki, bu kişisel bir stil seçimine daha fazla girmeye başlıyor ve bir ekip ya da şirkette üniform olması gerekmiyor. Bir insanın düşündüğü şey daha net bir şekilde okuyor olabilir. Bu "ekstra" tekdüzelik için bir değer var mı?


2
Merhaba Gratzy, Programcılar.SE bir tartışma panosu değildir ; karşılaşabileceğiniz gerçek sorunları çözmek için buradayız. Çözmeye çalıştığınız gerçek bir sorununuz mu var? Eğer öyleyse, cevapları yapıcı ve tartışma olmanın tuzaklarından uzak tutmak için sorunuzu yeniden düzenleyebilir misiniz?

1
@ Şahsen başka bir deyişle, kişisel olarak karşılaştığınız bir durum göz önüne alındığında, doğru cevap için kriterler nelerdir?

2
@ Mark Trapp SSS'ye göre bunlar bir soru için kriterlerdir Tüm öznel soruların yapıcı olması beklenmektedir. Bunu nasıl tanımlıyoruz? Yapıcı öznel sorular… 1. “neden” ve “nasıl” açıklayan cevaplara ilham verin. 2. cevapları uzun, kısa değil eğilimindedir. 3. yapıcı, adil ve tarafsız bir ton sahibi olur. 4. fikirleri paylaşma deneyimlerini davet edebilir. 5. görüşün gerçekler ve referanslarla desteklenmesi konusunda ısrar eder. 6. sadece akılsız sosyal eğlenceden daha fazlasıdır.
Sorumun

2
@ Sıkça sorulan sorulardan da faydalanabilirsiniz: "Yalnızca karşılaştığınız gerçek sorunlara dayanarak pratik ve cevaplanabilir sorular sormalısınız. Konuşkan, açık uçlu sorular sitemizin kullanışlılığını azaltır ve diğer soruları ön sayfadan çıkarır."

2
@ Trak Trapp Zaten kabul edilebilir bir cevap için kriterler belirttim ve evet, bunun gerçek bir sorun olduğunu söylüyorum ve açıkçası soruya olan ilgiden ve başkalarının kabul ettiğini söyleyeceğim cevaplardan.
Gratzy

Yanıtlar:


16

Tekdüzelik bir sorun değildir (iyi), ancak sertlik veya esneklik olmayabilir. Eğer tekdüzelik için çabalarsanız dogmatik olursanız, ekibe yaptığınız zarar (muhtemelen) ortaya çıkan tekdüzelikten gelen faydadan daha büyük olabilir.

En önemli şeyler için temel stil ayarlamak (adlandırma ve büyük harf kullanımı standartları, girinti, yeni satırlar ve köşeli parantez yerleştirme vb.), Daha az önemli şeyler için öneriler ayarlamak (eğer ifade biçimi, parantez etrafındaki diğer boşluklar vb.) ve sonra geri kalanı için endişelenmeyin.


1
Ben orada oldum

+1, ne demek istediğimi söyledi, ama daha iyisi!
FrustratedWithFormsDesigner

@Pierre bu yüzden şimdi serbestsiniz? :)
Nicole

gerçekten değil, ama yönergeler hakkında somany saplantılı insanlarla tanıştım. Aşırı olması nasıl korkutucu. Sanırım sınırı oldukça iyi tanımladın.

7

Potansiyel olarak onlarca insan ömrü boyunca bir proje üzerinde çalışırken, stilleri atlamak zorunda kaldığınızda bazen kafa karıştırıcı oluyor. Yazım stilini bir şekilde koruyan farklı yazarlar tarafından farklı bölümlerin yazıldığı bir kitap okuduğunuzu düşünün . Mümkün ama sinir bozucu.

Çoğu IDE bu günlerde stilleri uygulayabilir, bu yüzden gerekirse (proje kaynak kodunun bir parçası olarak) seçilen kodlama stilini belirten bir IDE tercih dosyasını dağıtabilir ve herkesin yükleyip yazdıkları kodu biçimlendirmesini sağlayabilirsiniz. . Bahse girerim check-in sırasında kodu yeniden biçimlendirmenin / tarzın oluşturulmasının yolları bile var (yine de bunu araştırmak zorunda kalmadım).


Evet, muhtemelen bir yere karınca senaryosu yapıştırabilirsin.
Michael K

1
IntelliJ, en azından, check-in işleminden önce kodu yeniden biçimlendirme seçeneğine sahiptir.
Nicole

3

Gördüğüm aşırı homojenlik durumu, uygunluğuna bakılmaksızın tüm programlama dilleri için geçerli olan tek bir standarda sahip olmaktır:

  • Cesaret kırıcı gotoolmadan C gibi dillerde bile try... catch.
  • InitialCapsStandart kitaplığın bulunduğu JavaScript'te adları kullanma (Microsoft'un MFC ve C # 'ında olduğu gibi) initialLowerCase.

2

Çok fazla homojenlik diye bir şey olduğunu sanmıyorum. Bununla birlikte, çoğu zaman kodlama standartlarında çok fazla ÖZGÜNLÜK buldum. Açılış ayracı ayrı bir satıra koyan herkesin faydaları en iyi ihtimalle şüphelidir ve bu konuda tartışmak veya kozmetik sorunları kodlamak için harcanan zamandan daha ağır basmaz.


2
@Tungano Daha fazla anlaşamadım. Kodlama standartlarının çelişkisi, sahip olmaya değer oldukları, ancak tartışmaya değmezler.
Charles E. Grant

3
Belirli bir stili bir programcının boğazından aşağı zorlamanın bu argümanlardan kaçınmanıza nasıl yardımcı olacağını görmüyorum. Aslında, bir programcıyı sevmedikleri bir stile adapte etmenin bu argümanları ya da en azından küskünlüğü SAĞLAR.
JohnFx

1
@JohnFx, çünkü çoğu programcı, stilin tutarlılığının kod kalitesine ve sürdürülebilirliğine herhangi bir stil seçiminden çok daha büyük bir katkı sağladığını fark edecektir. Deneyimlerime göre, ekibin hızlı bir burun sayımı yapabilir, insanların neyi sevdiğini ve sevmediğini görebilir ve hızla bir fikir birliğine gelebilirsiniz. Bazen birisi tuhaf bir bugabooya sahip olacak ve onları barındırıyorsunuz, o zaman başka birinin bugaboo'sunu veriyorlar. Kendimi deve davasının neden kötü olduğu konusunda takımı beş dakika boyunca harangu'lu bulursam, vazgeçip kişisel esnekliğimin bir testi olarak verim.
Charles E. Grant

1
Çoğu programcının stilin tutarlılığının böylesine büyük bir katkı sağladığını DÜŞÜNÜYOR, ama gerçekten değil. Görünüşe göre, evcil hayvan tarzınızla uyuşmayan koda bakmak sinir bozucu ve küçük kozmetik konular için "temizlemek" kod bloğundan geçmek ertelemek için iyi bir yoldur. Bakın, altın kaplamaya odaklandığımı ve teslim edilemediğini anlayana kadar o bant bandındaydım.
JohnFx

1
Alman ekibimizin koduyla, birkaç OSS projemizle ve sahip olduğumuz bazı eski kodlarla ve güncel şeylerimizle çalışıyorum. Bazıları C, bazıları C ++, bazıları C #. Bu yüzden her zaman birkaç farklı kod stilleri ile çalışmak zorunda. Bunu yaptığınızda, standartlarda zorunlu olan stil yönergelerinin ne kadar küçük olduğunu fark edersiniz. Bir projeden diğerine geçebilirsem, {} 'i farklı yerlere yerleştiren biriyle başa çıkabilirim. Bu yüzden lanet olası tek standartın 1 kuralı olan tek şey olduğunu düşünüyorum: "her projede tutarlılık".
gbjbaanb

2

Tekdüzelik için 2 argümanım olacaktı:

  • Kolektif mülkiyeti teşvik etmek. Birisinin "bebeğinin" değişiklikten zarar görmesinden korkmadan başka birinin kodunu düzenleyebilmesi. Bir çeşit "Hepimiz beraberizde" zihniyeti.

  • Ekleme kolaylığı. Başka bir yerde daha önce bir şey yapılmışsa, bu muhtemelen alınabilir ve tekrar kullanılabilir. Bazı kurallar bazen işleri daha kolay okunmasına veya değiştirilmesine yardımcı olabilir.

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.