Kodlama stillerini geliştiricinin özerkliği lehine teşvik etmeli mi yoksa tutarlılık lehine cesaretlendirmeli miyiz?


15

Bir geliştirici, aşağıdaki if/elsegibi tek satırlı kod ifadelerine sahip bloklar yazar :

if (condition)
   // Do this one-line code
else
   // Do this one-line code

Bir diğeri hepsi için kıvırcık parantez kullanır:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

Bir geliştirici önce bir nesneyi başlatır, sonra kullanır:

HelperClass helper = new HelperClass();
helper.DoSomething();

Başka bir geliştirici nesneyi bir satırda başlatır ve kullanır:

new HelperClass().DoSomething();

Bir geliştirici diziler ve fordöngülerle daha kolaydır :

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

Başka bir yazar:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

Neden bahsettiğimi bildiğine eminim. Ben buna kodlama stili diyorum (çünkü ne dediğini bilmiyorum). Ama her ne dersek, iyi mi kötü mü? Teşvik etmenin geliştiricilerin daha yüksek üretkenliği üzerinde bir etkisi var mı? Geliştiricilerden kodu anlattığımız şekilde yazmaya çalışmasını istemeli miyiz, böylece tüm sistemi stil tutarlı hale getirmek için mi?


1
Aslında buraya çok benzer bir soru sormaya geldim - otomatik kod biçimlendirme araçları kullanılabilir ve kullanışlı olduğunda, bu araçların çalıştırılmaması (ve tutarsız kişisel stilleri korumak) veya bir stilin uygulanması daha mı önemlidir?
kabarık

Tutarlı stil okuma kodunu kolaylaştırır, bu nedenle tutarlı bir stil kullanın. Örneklerinizde, okunması en kolay 2, 1, 2'dir. Son durum farklı olsa da. Performans açısından kritik öneme sahip uygulamalarda, for döngüsü listeler üzerinde yineleme yaparken daha hızlıdır. Performans, diziler üzerinde aynı yinelemedir. Ve her durumda, vartam nitelenmiş tür adı yerine kullanın .
Stephen

Yanıtlar:


19

Bir kodlama standartları belgesi yararlıdır. Bu var en çok kimsenin çok fazla sorun olmadan her şeyi hatırlıyorum o kısa yeterli zaman kullanışlı ve herkes çok fazla ağrıya neden değil yaptığında.

Kuruluşunuzdaki kodu girintiye almayı veya adları büyük harfle kullanmayı veya döngülerinizi nasıl uygulayacağınızı veya kodunuzu nasıl yorumlayacağınızı o kadar önemli değil; yardımcı olan kısım herkesi, herkesinkiyle aynı görünen kodlar yazmaya teşvik etmektir.

  • Diş tellerinin nerede olması gerektiği ve bir başkasının koduna her baktığınızda böyle bir beklentinizi yeniden ayarlamak için bir dakika harcamak zorunda kalmaz.
  • Aynı dosyada birkaç farklı kod stiline sahip olmaktan kaçınır.
  • Belki de en önemlisi, yazılı bir standarda sahip olmak, kod incelemeleri sırasında kodlama uygulamaları hakkında tartışmalardan kaçınır.

Yine, standartların ne olduğu basit, basit bir standarda sahip olmak kadar önemli değildir. Bu nedenle, tüm geliştiricilerinizi bir odaya koyun ve standartların ne olması gerektiği konusunda tartışmalarına izin verin. Bu toplantı süresiz olarak devam edebilir, bu yüzden kurallar:

  • Toplantının sonunda karar verilmeyen herhangi bir şey yönetici tarafından kararlaştırılacaktır.
  • Toplantı iki saat sonra veya biri bağırmaya veya ağlamaya başladığında hangisi önce gelirse biter.
  • Tüm standart (makul tip boyutunda!) Bir kağıda veya iki kağıda sığacaktır, sadece kesinlikle gerekliyse çift taraflı.

Birini evlat edinmeyi düşünün | başkasının | standartları kendi kodlama standartları toplantınız için bir başlangıç ​​noktası olarak veya toplantıdan tamamen kaçınmanın bir yolu olarak.

Anlaşmaya varıldıktan sonra, geliştiriciler polisi kendileri yapabilmelidir (ve beklemelidir). Standarttan zaman zaman sapma çok önemli olmamalı (ve haklı bile olabilir), ancak standart lehine favori bazı kişisel stilleri terk etmeyi reddetmek, sızan su boruları ile ofise derhal taşınma ile sonuçlanmalıdır. .

Demian Brecht tüy bırakmayan aletlere işaret ediyor. Bunlar bir kodlama standartları belgesinin mükemmel bir tamamlayıcısıdır. Kodlama stili standartlarına bağlı kalmak sadece iyidir ; bu kadar önemli tehlikeli uygulamaları ile ilgili standartlar kodlama için sopa. Yazar dışındaki hiç kimse, her kod satırının stil standardını karşıladığını kontrol etmeyecektir, ancak olası hataları otomatik olarak yakalamak için ekibinizin iş akışına bir tiftik aracı oluşturmayı kesinlikle düşünmelisiniz. Ek olarak, aracın kendisi kabul edilen uygulamaları kodlayabilir, böylece hepsini kodlama standartlarında tek tek listelemeniz gerekmez; aracın yapılandırmasını belirtmeniz yeterlidir.

Not: "Kodlama standartları" fikri programlamaya özgü değildir. "Kodlama standartları" birçok alanda, bazen bir kuruluşta, daha çok bir endüstri veya mesleğin tamamında kullanılır. Bazı örnekler:

Her durumda (ve diğer pek çok kişi), yetkili bir uygulayıcı, beklenen standarda uymayan "kodu" kolayca anlayabilir. Neden bu kadar çok sektör bir derleyici tarafından ayrıştırılması gerekmeyen belgeler için ayrıntılı gereksinimler yazmaya devam ediyor? Çünkü stil önemlidir . Standart bir tarzda bilgi sunmak, okuyucunun tamamen içeriğe odaklanmasını sağlar, okumayı daha hızlı hale getirir ve anlaşmaya yardımcı olur ve hataları azaltır.


1
Eğer mesajınıza linting araçlarının kullanımını eklerseniz, benimkini silerim ve sizinkini + 1'leyeceğim :)
Demian Brecht

@ DemianBrecht, İyi öneri, teşekkürler. Cevabımı geliştirmek için tüy bırakmayan araçlar eklendi, ancak sizinkini de bırakmanız gerektiğini düşünüyorum.
Caleb

Peki o zaman iyi. Yine de +1 :)
Demian Brecht

Ve ayrıca sana!
Caleb

Deneyimlerime göre bu tür davranışlar, yazılım geliştirme ekipleriyle uyumlu olmayan sosyopat ve / veya narsisistik eğilimlerle tutarlıdır.
mattnz

16

Stil önemli değil.

Orada dedim.

30 yıl ve yüzlerce müşteri sitesi ve o yıllarda 500 (veya daha fazla) ekip üyesinden gelen kod (tahmin), bu tarzın önemli olmadığını gördüm.

Önce işe koyulsun.

En uygun kaynak hacmini (yani doğru veri yapısı, doğru algoritma) kullanmasını sağlayın.

Her şey çözüldükten sonra "stil" üzerinde yaygara . Hiçbir zaman elle, sadece araçları ile "stil" yaygara.


2
Amin! Kodlama standartlarının gerçek faydalar ve tutarlılık açısından gerekçelendirilmesi gerekir, gerçek bir fayda değil, bir lüks.
JohnFx

12
Ancak stil nadiren stil ile ilgilidir. Bu yaygın hatalardan kaçınmakla ilgilidir.
Martin York

6
Ancak '==' yerine '=' karakterini önlemeye yardımcı olur (koşul içinde atama kullanmayın). Bunun if (t) { x;y;}yerine kaçınmaya yardımcı olur if (t) x;y;(eğer sonra her zaman '{}' kullanın). Const doğru kodu tercih edin (yazıldıktan sonra koda const doğruluğu eklemek çok zordur. Std :: cout / std :: cin değil fprintf / scanf kullanmayın, hataya neden olma olasılığı daha yüksektir. Dizilerden ziyade vektör kullanın (taşmayı önlemeye yardımcı olmak için)
Martin York

5
Çalışmak elbette çok önemlidir. Ancak bunun işe yaraması, yapıldığı anlamına gelmez. Ayrıca test edilmesi gerekir. Ve sonra gözden geçirdi. Hepsi birkaç gün sürebilir. Daha sonra, yıllar sonra, okunmalı ve anlaşılmalı ve sürdürülmelidir. Yararlı kod (neden başka türlü yazılır?) Yazıldığından çok daha fazla okunacaktır , bu nedenle okumayı ve anlamayı kolaylaştırarak üretkenliği geleceğe doğru geliştirir. Kuruluş genelinde tutarlı bir stil kullanmak, bu konuda yardımcı olmanın bir yoludur.
Caleb

1
Otomatik biçimlendirme araçlarının kullanımını zorlamaya ne dersiniz? Eclipse ve XCode kodu biçimlendirmeyi çok kolaylaştırır - ancak birlikte çalıştığım mühendislerden biri, kod tabanının geri kalanıyla tutarlı tutmak için kodunu "onun" (yani şirketin) kodunu otomatik olarak biçimlendirirse son derece üzülür. Biçimlendirme, stilin yalnızca küçük bir parçasıdır, ancak özellikle if / else yuvalama ve genel kod akışı (okunabilirlikten bahsetmemek) gibi konular için de önemlidir.
kabarık

4

Kodlama stilleri var ve kodlama kokuları var. Bulduğum bir zamanlar değildi:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Önceki işverenim, if()parantez içermeyen çok satırlı kullanımı kesin olarak yasakladı . "Tekrar yap ve kovuldun" tipi bir hata olarak kabul edildi. İzin verilen yapılar

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

Bu, tıpkı yukarıda gösterdiğim gibi, portalın ana sayfasını durdurabilmek için birkaç saat süren bir hatadan kaynaklandı.

Her zaman yapman gereken şeyler var. Gibi switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

Bu arada, şunu yazın:

     case 1:
         something();
     case 2:
         something();
     break;

Bir kapatmadan caseile //fallthroughbir hata olarak kabul edilir.

Genellikle, göz ardı edilebilir, yaratıcı bir şekilde yorumlanabilir veya belirli ihtiyaçlar için değiştirilebilen kılavuzlar olan kodlama standardı vardır. Bir de "kokular" bölümü var ve buna titizlikle uyulmalı.


3

İyi bir ön tasarım ile tutarlılık yaratın. Soruda tanımladığınız şey mikro yönetimden başka bir şey değildir. Çok fazla web geliştirme yapıyorum. Bu yüzden hizmet olarak maruz kalan RESTful ve CRUD gelişimini destekliyorum. Bu, çeşitli şekillerde kullanılabilen basit, iyi tanımlanmış varlıklar sağlar.

Bu tasarım aynı zamanda uygulama ayrıntılarını diğer geliştiricilere devretmeme izin veriyor. Bu şekilde, bütün bir sistem tasarımı oluşturmak yerine boşlukları dolduruyorlar.

Genel bir tasarım eksikliği sistem tutarsızlıkları yaratır. Temel yinelemelerin ve döngü yapılarının eleştirisi, sistem tasarımını iyileştirmek için çok az şey yapar. Bu tür sorunlar daha iyi bir yaklaşım olan StyleCop ile daha iyi çözülür .

Genel sistem tasarımınızın nispeten basit bir diyagramını çizebilir misiniz? Yeni bir ekip geliştiricisine dahil olan öğeleri / varlıkları tanımlayan bir tasarım. Yapamıyorsanız veya çok fazla ilgiliyse, tasarım eksiktir.


3

IMHO bağlıdır ...

İlk iki örneğiniz benim için sadece kişisel bir zevk meselesi değil.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(köşeli ayraç olmadan) = daha sonra hata kodu daha fazladır, daha sonra daha fazla kod eklenirse:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

Ve bu hata ayıklamak için daha az uygundur:

new HelperClass().DoSomething(GetSomeData()); // etc.

İhtiyacınız olan yerde bir kesme noktası ayarlayamazsınız. Bu bir kereye mahsus - yeterince adil, ancak bir stil meselesi olarak tartışırız ve her yerde böyle bir şey olduğunda, hata ayıklama olması gerekenden daha tatsız olur.

Üçüncü örneğinize gelince (vs foreach için), bunu bir zevk meselesi olarak görüyorum.


2

Ne. Sıkıcı, nit seçici, mikro yönetim ve tüm zaman kaybından en kötü olmasını önlemek için sert kodlama kurallarından kaçınırım. Özerklik duygunuz sizin kendi meselenizdir. Kendini daha iyi hissetmeni istersem, sana en sevdiğin içeceklerden bir tur alacağım. Bunun dışında bir şey yap.


2

Sözleşmelerin, değişken adlarının, sınıf adlarının vb. Kullanımı iyi bir uygulamadır. Ancak, sağladığınız örnekler gibi kodlama stilleri oldukça önemsizdir ve kodun okunabilirliği veya etkinliği üzerinde hiçbir etkisi yoktur. Öte yandan, belirli bir stilin geliştirilmesinin ek yükü geliştiricilerin çabaları ile birlikte takip etmesi sorunlara neden olacaktır.


2

Endüstri standardı bir linting aracı kullanın (görünüşe göre C # için FxCop ). O sonu tüm olmasa da, be-hepsi, tutarlılık olduğunu üzerlerinde çalışan insanların bir dizi büyük projelerde önemli.

Sadece kendi projeniz veya küçük ekibiniz üzerinde çalışıyorsanız, birçoğu bunun aşırıya kaçtığını iddia eder. Aksine inanıyorum ( PEP8'i kişisel tek geliştirici projelerimde bile Python için kullanıyorum ).

Bununla birlikte, verdiğiniz örneklerin çoğu, büyük olasılıkla önemli olmadıkları için bir linting aracı tarafından yakalanmaz.


1

Tek tip kodlama stilini uygulamak her zaman zordur. İdeal olarak, bu tür sıradan görevler işlenecek bir araca bırakılmalıdır. Go dili topluluğunu bunun için alkışlıyorum.


1

İkisinin bir karışımı. Bunun bir standart olması onu okunabilir ve bakımı kolay yapmaz. Henüz aşılanmış bir standart yoksa veya hatalı ve okunamayan yönleri varsa, revizyon uygundur.


1

Son analizde, programlamayı yönlendiren programcıdır. Stil sorunları var, ancak programı çıkarmaya ikincil.

Programcılara BAZI tarzı rehberlik vermek yararlı olur. Bu, programcılar çalışmaya başlamadan önce, özellikle de çevreye veya programlamanın kendisine yeni başlayanlarsa yapılabilir / yapılmalıdır. Rehberlik göz önüne alındığında, bazı programcılar çok stil bilincine sahip olurlar, diğerleri daha az. Projenin başında verilen rehberlik ilk programcı grubuna yardımcı olacak ve böylece genel görevi kolaylaştıracaktır. İkinci grup için (umarım) yaratıcılık, uyumsuzluklarını telafi edecek çok az şey olabilir.


1

Bence bu projenin büyüklüğüne ve üzerinde kaç kişinin çalıştığına bağlı. Yetenekli bir programcı, her iki farklı format stiline bakabilir ve her ikisinde de neler olduğunu bilir, ancak bir dikkat olması gerekir, böylece göz kolayca yakalayabilir. Eğer tek satırınızı yapacaksanız, curle parantezleri olmadan iftasanlar o projeyi kullanmamalıdır. Bu projeye liderlik eden kişi bu seçeneğe sahip olmalıdır. İşleri net bir şekilde kesmeyi ve onları alabildiğim gibi çok kompakt görünmesini seviyorum. Eğer tek bir satır yapacaksanız eğer statmeents ise daha iyi görünüyor

if() {}
else() {}

Ya da:

if() {} else () {}

Ancak tek bir satır halinde mulitilinin aralığını kullanmamalısınız. Ben böyle şeyler yaparım. Nesnenin nasıl çağrıldığına aldırmıyorum ve bu kaç kez çağrıldığına bağlı. Eğer birkaç kez çağrılırsa, daha ziyade nesneyi başlatırım ve bunun yapıtaşlarına ve ne olmadığına bağlıdır. Çünkü bir kurucunuz varsa ve şunu çağırırsanız:

Object.method();
Object.method2();

Daha sonra, nesneyi tam olarak örnekleyerek önlenebileceğinde, nesne oluşturma yöntemini iki kez çağırdınız.

Ne zaman foreach ve döngüler için Onun da lanauge hakkında bazı lanauges bir foreach döngüsünde diziye bakarken size daha iyi kontrol sağlar böylece geçici diziler anahtar ve değeri var. Ve biliyorum ki bazı diller bir çeşit optimizasyona sahiptir, çünkü döngüye bakabilirler ve tam olarak kaç kez çağrılacağını bilirler.


1

İlk örneğiniz harika olmasa da (modifikasyon altında hataya daha yatkın olduğu iddiası biraz ağırlık taşır), genel olarak geliştiricilerin biraz farklı kodlama stilleri kullanmasını tercih etmek için büyüdüm .

Diğer ekip üyelerinin kodlarıyla çalıştıktan sonra, bazen birkaç ay gibi kısa bir süre için, esas olarak bir satır içi çalışmaya başlar git blame. 10 yılı aşkın bir süredir şirketimde bulunduktan sonra, size 500k kod satırımızda herhangi bir yere herhangi bir sınıf yazan sadece% 80 + doğrulukla söyleyebilirim.

Kabul etmediğiniz bir stili kullanan bir koda bakmaya başladığınızda ufak bir "rampa zamanı" varken, o zaman gerçekten yaptığınız şey "oh, bu John Doe'nun koduna benziyor (çünkü X stilini kullanıyor, ancak Y stilini kullanmıyor vb.) ". Ve bu beraberinde bütün bir bağlam yığını getiriyor. İlk bir yaklaşım olarak, John'un kodundan ne bekleyeceğinizi biliyorsunuz - kod tabanının diğer kısımlarını iyi anlıyor ve hangi parçaları anlamadığını, SQL gurusu veya GUI acemi vb.

Herkesin kodunu bir biçimlendirici aracılığıyla çalıştırmak, aslında bu bilgileri a git blame.


0

Bu gerçekten organizasyon türüne bağlıdır.

Küçük bir süper kahraman grubuysanız, her türlü stil iyidir. Herkesin kendi stili varsa ve hem iyi hem de dahili olarak tutarlıysa, ihtiyacınız olan tüm süreç budur. Süper kahramanlar "Jane'in parantezleri var, bu yüzden demek istediği" veya "Jack değişkenler için camelCase kullanıyor" der.

Evrensel standartlar herkesi B + oyuncusu yapmak için en iyi olma eğilimindedir. Süper kahramanlarınız bundan aşağı çekilecek. Ancak bir A oyuncusu ve bir yarım düzine B oyuncusu ve bir yarım düzine C oyuncusu B + 'ya kadar ortalama olmasını istiyorsanız, tutarlı standartlar istiyorsunuz. Bu durumda, herkesin aynı şeyi yapmasını istersiniz, böylece bir A oyuncusu herkesin kodunu olabildiğince çabuk geçebilir.

Birçoğunuz, "Ama bekleyin, neden B ve C oyuncuları ile gitmiyorsunuz?"

Gerçek şu ki, pek çok Süper Kahraman yok. Bunları Google'da bulup büyütmek için para ödeyebilse de, Ma Bell için yeni bir faturalandırma sistemi koymak, ikinci ekiple daha uygun maliyetli olabilir. (Ve gerçekten Süper Kahramanlarınız varsa, 4 veya 5'i bir düzine gençten iki kat daha pahalı olacaktır)

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.