Kodlama standartlarımızdan nefret ediyorum ve bu beni deli ediyor, nasıl işleyeceğim? [kapalı]


18

Feragatname : Başlığın önerdiği kadar abartılı değil, ama yine de beni rahatsız ediyor. Sadece dürüstçe ifade edeceğim, bu yüzden bir tuz tanesi ile alın. Sadece bahsettiğim gibi davranmak o Çalıştığınız sevmiyorum o kodlama standardı.

Düzenleme : Sevmediğim, onu kullanmadığım veya zorlamadığım anlamına gelmez.


Bu soruyu, nasıl değiştirilebileceğinin daha iyi tartışılması konusunda yardım almak için sevmediğiniz bir standardı nasıl aşacağınız ruhu içinde sormaya karar verdim (bu son bölümle ilgili herhangi bir yorum takdir edilmesine rağmen). Ayrıca, büyük bir şirkette çalışıyorum ve bu kadar uzun süredir devam eden ve çok az önemli olan bir şeyin böyle bir değişikliğinin olması pek olası değil.

Standart, adanmış hat üzerindeki kıvırcık-süslü ayraç standardıdır:

somefunction()
{
    //...
}

* Açıkça üstün * yerine (şaka / sinirli tonu not edin):

somefunction() {
    //...
}

Standarda karşı kişisel görüşlerim:

  • Kodu şişirir : ekstra gereksiz çizgiler
  • Yazması daha zor: muhtemelen bu sadece standartla mücadele ediyor olmama rağmen, ekstra bir tuş vuruşunun o kadar da kötü olmadığını biliyorum.
  • Okuması daha kolay değil : Bir if bildirimi, if deyimi veya başka bir kapsam istifleme deyimi okumaya başladım ve zaten bir açılış ayracı aramak zorunda değilim. Bu standarda sahip iç içe bloklar sadece bir sebepten ötürü beni kızdırıyor.
  • Microsoft IDE geçmişinden gelen insanlar tarafından kullanılır : Bence sadece bir standardın arkasında tartışmalı bir neden (veya daha fazlası) olmalı, sadece paradigma tarafından kabul edilmemeli.

Onların argümanları (ve içsel olarak onlara karşılık verme yolum):

  • Okuması daha kolay çünkü blokların nereden başlayıp nerede bittiğini görebiliyorsunuz: Bunu anlayamıyorum, neye sahip olduğunu bilmiyorsanız blok ne kadar iyi, o zaman geriye doğru okumak zorundasınız.
  • Microsoft IDE'de kullandım ve beğendim : Ahh ... tamam mı?
  • Standartta : * cringes *

Belirli bir standarda karşı görüşlü bir tavırla mücadele eden tek kişi ben miyim? Bunları nasıl aştınız?, Bu standardın ne olması gerektiği hakkında ne düşünüyorsunuz (sadece eğlence için)?


6
Ne kadar süreyle "nefret" standardını kullanıyorsunuz? ve diğer standartları "paralel" olarak mı kullanıyorsunuz? Yani, sadece buna alışmak meselesi olabilir mi? Aynı standarttan nefret ettiğimi itiraf etmeliyim, ancak yaklaşık bir yıl sonra sadece bu şekilde yazdım, bu nefret tamamen ortadan kayboldu
gnat

54
Sen ihmal edilir açıkça gerekli fonksiyon tanımlaması sonu ve kıvırcık parantez arasındaki boşluk! Yanmalısın!
pap

5
Onunla yaşa. Bu gerçekten çok küçük bir problem. Sizi rahatsız eden tek şey budur. Dili değiştirirseniz, yeni stile de uyum sağlayabilmeniz gerekir. Yani birkaç hafta onunla çalışmak bu yanlış olduğunu düzeltmek gerekir.
schlingel

8
Used by people who come from a Microsoft IDE backgroundBu bir Microsoft işi değil, örneğin Linux Çekirdeği ve K&R aynı stili kullanıyor.
Lucas

5
Eğer tüm enerjinizi önemsiz şeylerle ilgili tüm öfkelenerek harcarsanız, gerçekten önemli olan şeyler için hiçbir iziniz kalmaz.
Blrfl

Yanıtlar:


47

Bunu aşmak istiyorsanız - Torvalds'ın bir teklifi vardı:

Kötü programcılar kod hakkında endişeleniyor. İyi programcılar veri yapıları ve ilişkileri hakkında endişelenir.

Şimdi düşünün, kod standartlarının uyguladığı destekleme tarzı gibi küçük bir şeyden endişe eden programcıları nereye koyar? Kod tabanınız başka türlü bu kadar bozulmamış mı, tartışmaya değecek tek sorun hazırlayıcı mı?


2
Tamamen katılıyorum. Diğer tüm sorunları çözdüyseniz ve kıvrımları nereye koyacağınıza karar vermek en önemli şeyse, diğer tüm yazılım projelerinden daha iyi durumdasınız demektir.

4
Kod tabanınız başka türlü bu kadar bozulmamış mı, tartışmaya değecek tek sorun hazırlayıcı mı? - Bu retorik bir soru olurdu - böyle bir kod tabanı tarihte hiç var olmadı!
MattDavey


Çünkü bir projeye girdiğiniz hakkında yorum yapıyordu, projenin stil rehberine saygı duyuyorsunuz ve değiştirmek için teklifler gönderiyorsunuz ... aksi takdirde stillerine sadık kalıyorsunuz!
Rudolf Olah

1
@GilesRoberts: Git komut mesajlarını "yanlış" olarak biçimlendirirseniz Linus, kurulan inceleme işlemiyle çalışmadığından çıldırır. Proje için 20 yıl boyunca iyi çalışan ve yüzlerce insanı kapsayan bir proje. Bazı işlem kuralları kod biçimlendirmekten çok daha önemlidir.
Jan Hudec

66

Bazı insanlar sizin tarzınızı beğenir, bazıları sevmez. Her iki durumda da birisi rahatsız olacak. Bu sefer sıra sizde. Em ve işe devam et.


5
Sanırım üstesinden nasıl gelmesi gerektiğini soruyor . Bu aslında çok farklı bir soru.
Zachary Yates

18
Standardı takip etmemek daha kötü bir sorun yaratır ve herkesi rahatsız eder . "Emmek" gerçekten!
Frank Shearar

2
Katılıyorum. Sadece bununla başa çıkmak zorundasın.
Cody

3
Dürüst olmak gerekirse, Bu beni de sinirlendirir, ama ne yazık ki, "emmek" doğru cevaptır.
Sulthan

27

Ekibin standardı belgelendi mi? Öyleyse, stil kılavuzunda herhangi bir neden var mı? Dürüst olmak gerekirse, tonlarca emmek ve gerçek iş yapmak zorunda kaldım. Sahip olmak daha kötü problemler var, ama seni hissediyorum - hala rütbeli (bu arada sana stil konusunda katılıyorum).

Üstesinden gelmeme ne yardım etti:

  1. Tek bir stilin gerçek faydaları olduğunu fark ettim (ne olursa olsun). Ya da en azından bir grup insan böyle düşünüyor .
  2. Tam olarak ne yaptığını, neden yanlış hissettiğini yaz, böylece gelecekte argümanı iyi bir şekilde ortaya çıkarabilirsin.
  3. Tanrı aşkına bir şekillendirme aracı kullanın , akıl sağlığınızı kurtaracak. Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , vb ... Visual Studio bile sizin için yapacak .
  4. Bu projede kıçını tekmelemek ve standartları belirleyebileceğiniz bir sonraki için hazır olun.

7
(3) için +1, bulunduğunuz SCM için çekme sonrası / itme öncesi kanca olarak ayarladıysanız bonus puan.
Martin Green

1
Şekillendirme araçları bu sorunu ortadan kaldırır ve insanların paralarını ağızlarının olduğu yere koymasını sağlar. Eğer gerçekten looooooove kıvırcık belirli bir şekilde parantezi, o size bunu kendiniz için tüm sıcak ve rahat hale getirmek için stil yapılandırmasını değiştirmek gidin. Aksi takdirde, ağzınızı kapatarak kodlama alabilirsiniz.
Calphool

16

Bir sözleşmenin diğerine üstünlüğü * açıkça keyfi * dir .

Karşılaştığınız okunabilirlik sorunları veya takım arkadaşlarınız standardınızla karşı karşıya kalacaktır, değişime karşı yalnızca psikolojik bir dirençtir.

Nesnel okunabilirlik argümanı tüm kod tabanı üzerinde * tutarlılık * lehinedir .


"sadece" değişime karşı psikolojik bir direnç? Değişime karşı psikolojik dirençler oldukça büyük olabilir.
Giles Roberts

8

Bir şey hakkında haklı olduğunuzdan emin olduğunuz ve bir süre boyunca yanlış olduğunuzu veya en azından yıllar önce aşırı tepki verdiğinizi fark ettiğiniz bir zamanı düşünün . Tekrar yanlış olabileceğinizi düşünün ve yeni kodlama standardını veya işlem süresini sizi ikna etmek için zaman verin.

Ben kodlama için oldukça yeni Kendi standartlar öfke çok kelimeli tanımlayıcılar olup olmaması gerektiği idi (Kariyerimin içine beş yıl demek) WrittenLikeThisveya written_like_this. Hangisini yattığımı bile söylemeyeceğim, ama önemli olan şu ki, bir süre sonra tarafları değiştirdim ve bir süre sonra her iki şekilde de umursamadım.


Evet, like_this ve likeThis arasında da parçalandım. Son zamanlarda küçük harfli stile yaslanıyorum, okumak daha açık.
doug65536

1
Tabii ki, şimdi bazı projelerde bunun gibi kaldım. Oh, adlandırma kuralları, şeylerin büyük düzeninde çok önemli değil.
16:13

1
Kesinlikle. Açılış ayracı hangi çizgi üzerinde olursa olsun önemli değil. MultiWordIdentifiers veya multi_word_identifiers yazmanızın bir önemi yoktur. Şirketiniz hangi standardı kullanırsa kullansın, birkaç ay içinde bunu başka şekilde yapmak istediğinizi hatırlamakta zorlanacaksınız.
Carson63000

8

Kıvırcık parantezlerle tanımladığınız standart fark büyük ölçüde keyfidir. Her iki yol da eşit derecede iyi yollardır ve bir şirket için, herkes aynı şeyi yaptığı sürece her şey iyidir.

Bahsettiğiniz "açıkça üstün", insanların "alışkın oldukları" şeylerden bahsettiklerinde bahsettikleri üstünlüktür.

Yakında buna alışacaksınız ve bir yıl içinde, diğer yol "açıkça üstün" olacak.

Kısacası: onunla başa çıkmak.


açıkça üstün bir cevap
Mawg diyor Monica

5

Bu konu, bir stili diğerine tercih edenler arasında bir Din Savaşı anlamına gelir. Çok az insan kararsızdır ...

Sonuçta, ikisi de doğru değil, ikisi de yanlış.

Stil kılavuzları ve kodlama standartları birkaç nedenden ötürü mevcuttur - ve önemli bir husus, bariz hataların sayısını azaltmayı ve sürdürülebilirliği artırmayı amaçlayan mizanpaj homojenliğini sağlamaktır.

Belirli bir standarda karşı görüşlü bir tavırla mücadele eden tek kişi ben miyim?

Kısa cevap "Hayır" dır. Sadece siz değilsiniz. Ancak endişelenmeniz gereken daha önemli şeyler var. Kişinin girdiği standartlarda bile, her zaman uzlaşı olacaktır - C99 ve C12'de benim için hiçbir anlam ifade etmeyen bazı yönlere tanık olun.

MISRA-C bile (üzerinde doğrudan etkim var) kişisel olarak kabul etmediğim öğeler içeriyor - ama başkalarının neden haklı olduğunu hissettiğini anlayabiliyorum.

bunların üstesinden nasıl geldin?

Ve bunun cevabı yatıyor - neden kişisel olarak sevmediğinize odaklanmak yerine, bunu kabul eden kişinin / bunu neden yaptığını anlamaya çalışın.

Önceki bir sorunu ele almak için kurallar genellikle (atlar bir tür vidalandıktan sonra sabit bir kapıda kapanır) uygulanır. Kural hala saçma ise, standart sahibiyle konuşun ve onları "eğitmeye" çalışın.


4

Bence bununla başa çıkman gerek. Notlarınızı kendi düşüncelerimle ele almaya çalışacağım:

  • Şişkinlik Kodu

    Ek bir kod satırı, yüzlerce fazladan satır ekleyecek tek bir sınıfta 100'lerin yöntemlerini yazmazsanız, kodu hiç şişirmez. Sonra tekrar tek bir sınıfta yüzlerce yöntem varsa tamamen başka bir sorun var.

  • Yazması Zor

    Bu konuda sizinle aynı fikirde değilim, yine de bir sonraki satıra ulaşmak için dönüş tuşuna basmanız gerekiyor. Yazmak ne kadar zor?

  • Okuması daha zor

    Bir kod parçasındaki her satırın belirli bir işlevi olması gerektiğini hissediyorum. Bunu takiben, bir satırda yöntem adını tanımlamanız gerekir, daha sonra kendi ayrı satırlarında açık ve kapalı parantezler.

  • MS IDE geçmişinden gelen kişiler tarafından kullanılır

    Tamam ..... Ahh?

Özetle, başka bir geliştiricinin aksine bir .Net geliştiricisi olmaktan ziyade, bu standardı varsayılan olarak kullanan bir IDE kullandıkları için nitelendiriyor gibi görünüyor.


1
-1 Tüm puanları kabul ediyorum, ancak çeşitli noktaların her biri hakkında herhangi bir görüşün özellikle yararlı olduğunu düşünmüyorum.
Caleb

4

Belirli bir standarda karşı görüşlü bir tavırla mücadele eden tek kişi ben miyim?

Tabii ki değil. Kodlama standartlarını belirlemek için toplantılar korkunç! Saatlerce sürüyorlar ve katılımcılar standartta yer alan kendi favorilerini (ve benimkiler dışında her zaman yanlış) almak için kişisel olarak yatırım yapıyorlar. Sonunda kimse sonuçtan memnun değil. Kodlama standartları toplantısından daha kötü bir şey varsa, standardın belirlenmesini izleyen birkaç aydaki resmi kod inceleme toplantıları: bazı insanlar standardı benimsemeye çalışırken, diğerleri (kasıtlı olarak veya değil) görmezden gelir ve alırsınız. saatlerce geri bildirim: SillyFileConverter.cpp'nin 132, 142, 145, 181, 195 ve 221 satırlarında, kodlama standardı aşağıdaki satırda olması gerektiğini açıkça söylediğinde açılış kümesini aynı satıra koyarsınız !

bunların üstesinden nasıl geldin?

Toplantılar kendi yollarıyla yardımcı olur. Açılış ayracı koşullu veya aynı şekilde aynı çizgide bırakan adama tamamen sempati duysanız bile, sadece onu emip aptal standardı takip etmekle zamanınızı boşa harcadığınız için ona kızacaksınız. Adam bir curmudgeon ise ve aynı şeyi tekrar tekrar yaparsa, daha da can sıkıcı hale gelir. Bu davranıştan rahatsız olmak, tercih ettiğinizden biraz farklı bir tarzda yazmayı haklı çıkarmayı çok daha kolay hale getirir - kesinlikle o adam olmak istemezsiniz .

Bitmeyen resmi kod incelemelerine tabi olmasanız bile, özellikle standartlara uyumluluk için kendi kodunuzu gözden geçirmeyi deneyebilirsiniz. Standart hakkında ne düşündüğünüz önemli değil, sadece yazdıklarınızı standardın söyledikleriyle karşılaştırıyorsunuz. Her uymamanız durumunda kendinizi ölürseniz, bu, standardı benimsemenize yardımcı olmak için ihtiyaç duyduğunuz olumsuz geri bildirimlerin bir kısmını sağlayabilir.


"Bir dil standardizasyon çabasına katılın ...
Beni Cherniavsky-Paskin

3

Bu tür şeylerle Lilliput'ta Gulliver'i hatırlıyorum. Lilliputyalılar, üzerine haşlanmış yumurta açmak için savaşmışlardı. (Orijinal büyük endian, küçük endian savaşı).

Kendinize gülmek için bir fırsat olarak kabul edin, iş dünyasında yeterince sık gelmiyorlar.


2

Bazı örnekleriniz bazılarının hemfikir olacağı ve bazılarının kabul etmeyeceği bir örnek olduğundan talihsiz bir durumdur. Örneğin aleyhindeki argümanlarınıza katılmıyorum ve eminim ki diğerleri gibi, birçokları da aynı fikirde olacak. Neredeyse sübjektif olduğu için sorunun kapatılması gerektiğini düşündürüyor.

Ancak, kabul etmediğiniz bir standartla nasıl başa çıkılacağı sorusu daha sorumludur. Cevap, stil yönergelerinin var olduğu ve üzerinde anlaşıldığı ve kullanıldığı yerlerde, cevabın sadece sırıtmak, dayanmak ve onunla başa çıkmak olduğunu düşünüyorum. Tutarlılığa sahip olmanın daha önemli olduğunu düşünün. Kılavuz yanlış veya yanlışsa, değişim için bir argüman olabilir, ancak bu stilistiktir, bu yüzden kişisel tercih dışında gerçekten bir argüman yoktur.

Bir Java geçmişinden geldim, bu yüzden bahsettiğiniz standardı takip ettim. Daha sonra nefret ettiğiniz stilin kullanıldığı daha fazla C ++ ve C # 'a geçtim. Ama doğru ya da yanlış cevabı yok. Daha da önemlisi, herkesin izlediği bir standarda sahip olmak. Eğer bir kodlama standardı bu şekilde üslupsa ve açıkça yanlış değilse, tartışmaya çalışmak takımda sürtünmeye neden olacaktır.


1
Soruda belirtildiği gibi, soru gerçekten belirli bir standartla ilgili değildir, bu nedenle ilk paragrafınız almanca değildir.
Caleb

2

Bir biçimlendirici + kontrol kancası iyi bir başlangıçtır. Ancak bu yeterli değildir, çünkü yazdıklarınız gün boyunca baktığınız kadar önemli değildir. Bazı durumlarda, Emacs Gözlük modunun yaklaşımı - dosyaları kendi tarzında tutar ancak tarzınıza daha yakın görüntüler - çekici.

Onunla ilgili deneyimim - tam olarak yazdığı meseleyle karşı karşıya, CamelCapsvs underscore_separated- hızlı bir şekilde yardımcı olmaktan daha sinir bozucu oldu, ancak birkaç hafta boyunca şirketin tarzını kabul etmenin (kaba bir şekilde) geçişini düzeltti ve bir çıkış sağladı öfkemi kanalize etmek ( "ah nefret ediyorum, en azından ben orada yaptım beni ... yine ayarlarını izin şey ") ;-)

Her neyse, Gözlük modu brace yerleşimini işlemez, muhtemelen Emacs kullanmazsınız ve kodu yalnızca düzenleyicinizde okumazsınız :-(
Ancak son nokta da bir fırsattır - okursanız çoğu zaman kodu ayrı bir araç olarak, gidiş-dönüş yeniden biçimlendirme gürültüsünden endişe etmeden stilleri dönüştürmek için hackleyebilirsiniz - çünkü salt okunur! Özellikle, bazı web arayüzlerinde kod okursanız Greasemonkey'i kullanın.

Hafif hafifletme için bazı daha kolay fikirler:

  • Kayıp ekran satırlarını geri almak için daha geniş ancak çok yüksek olmayan bir yazı tipi seçin.

    • Varsa, tam ekranı daha sık kullanın.
  • İnce bir renkle (ve daha küçük yazı tipi?) Vurgulanacak parantezleri ayarlayın, böylece kodun geri kalanından daha az görünür olurlar. Girinti okumak için yeterli olmalıdır, özellikle. {satırlardaki boş alanla ...

  • Editörünüz bittiğinde eşleşen açılış desteğini vurguladığından emin olun }- gözleriniz içgüdüsel olarak yanlış yere gittiğinde biraz yardımcı olabilir.

  • Re "yazmak zor": gerçek bir editör alın, tuşuna bastığınızda otomatik olarak yeni bir satır açmak için yapılandırın {.


0

Onunla yaşa.

Bu açıkça kozmetiktir ve kodun kalitesi veya bir geliştirici olarak verimliliğiniz hakkında hiçbir şey değiştirmez. Tartışmaya değer bir şey yok.

Bu tür kodlama standardı için, kod tabanı genelinde tutarlılık ve herhangi bir özel (hatta iyi gerekçeli) "dini" yaklaşım üzerinde okunabilirlik seçerdim.

Bunu, ekip üyelerinin çoğunluğunun çok önemli olmayan bir sorun hakkında demokratik bir karar olarak düşünmek, bunun üstesinden gelmenize yardımcı olabilir.



-5

Sadece devam edin ve istediğiniz stili kullanın. Daha sonra kodu standart biçimde değiştirmek için bazı kod güzelleştirici kullanın veya kodu stilinizden verilen standart stile dönüştürecek kendi küçük uygulamanızı düzeltin. Kodu kontrol etmeden önce güzelleştiriciyi kullanın.
Ayrıca, üzerinde çalışırken iade edilen kodu standart biçimden biçiminize değiştirmek için bunun tersini de yapabilirsiniz.


2
-1 Sorunun konusu: bunun üstesinden nasıl gelebilirim? , ancak önerileriniz üstesinden gelmek için kaybolmaz, sadece yolunuza devam edin. Yararlı görünmüyor. Aynı zamanda çok pratik değil - güzel bir yazıcı kullanmak, teminat hasarı olasılığını yaratır, yani tercih ettiğiniz formata ve tekrar döndükten sonra, birçok çizgi tam olarak aynı şeyi ifade etseler bile tam olarak aynı olmayabilir. Bu, neyin gerçekten değiştiğini bulmaya çalışan farklı versiyonlara bakan insanlar için çok fazla sorun yaratır.
Caleb

@Caleb - Prettyprinter kullanma deneyiminiz farklı olabilir. Atristic Style'ı kullanıyoruz ve kimsenin bu konuda şikayeti yok.
Manoj R

9
Herhangi bir ciddi yazılım geliştirmesi bir kaynak kontrol sistemi kullanacaktır. Önemli olmayan farklılıkların ortaya çıkması sorunlara yol açacak ve farkları görüntüleyen kişilerin rahatsız olmalarını veya daha kötüsünü check-in çatışmalarına neden olacaktır.
13
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.