Kıvrımlı kaşlı ayraçlar kendi çizgisinde mi görünmeli? [kapalı]

Kıvrımlı kaşlı ayraçlar kendi çizgisinde olmalı mı yoksa olmamalı mı? Bu konu hakkında ne düşünüyorsun?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

ya da olmalı

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

ya da

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Lütfen yapıcı olun! Nedenini açıkla, deneyimlerini paylaş, gerçeklerle ve referanslarla destekle.

Ben öğrenciyken, aynı satıra kıvırcık ayraçlar koyardım, böylece daha az satır olur ve kod daha az sayfaya yazdırılırdı. Bir satırdaki tek şey olarak basılan tek bir dirsek karakterine bakmak can sıkıcıdır. (çevre, kağıt israfı)

Ancak büyük uygulamaları kodlarken, içlerinde sadece parantez bulunan bazı çizgilere izin vermek, verdiği 'gruplama' hissini göz önünde bulundurarak uygun maliyetlidir.

Hangi stili seçerseniz seçin, tutarlı olun, böylece kendi beyninizin ilgili kod parçalarında çoklu stilleri işlemesi bir yük olmaz . Farklı senaryolarda (yukarıdaki gibi) farklı stilleri kullanmanın uygun olduğunu söyleyebilirim, bağlamı yüksek seviyede değiştirmek daha kolaydır.

Asla 3. yöntemi yapmamalısın.

Parantezlere bakmak, ilk defa birkaç tuşa basışınızı kurtarabilir, ancak bir sonraki kodlayıcı, diğer cümlenize, bloğun eksik parantezlerin çok acı çektiğini fark etmeden bir şeyler ekler.

Diğer insanlar için kodunuzu yazın.

Uzun zamandır ben bu kadar eşit değerde olduğunu veya savundu eşit çok yakın altına kadar doğru seçim yaparak olası kazanç uzakta olduğunu savunarak maliyeti bu konuda.

Tutarlı olmak yine de önemlidir . Ben de bozuk para çevirip kod yazmaya başlayalım dedim.

Programcıların daha önce bu şekilde değişime direnç gösterdiğini gördüm. AŞ bunu! Kariyerim boyunca birçok kez yer değiştirdim. C # 'sımda PowerShell'imden farklı stiller bile kullanıyorum.

Birkaç yıl önce, giriş talep etmeye karar veren bir ekip (~ 20 geliştirici) üzerinde çalıştım ve daha sonra bir karar verdim ve daha sonra bunu tüm kod tabanında uygulamıştım. Karar vermek için 1 haftamız var.

Bir sürü inilti ve göz yuvarlanma. "Yolumu seviyorum, çünkü daha iyi" çok ama madde yok.

Sorunun daha ince noktalarını incelerken, birisi bu konuyla aynı çizgi stili ile nasıl başa çıkacağını sordu:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Parametre listesinin nerede bittiği ve gövdenin başladığı yerin hemen belli olmadığını unutmayın. Karşılaştırmak:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Dünyanın dört bir yanındaki insanların bu sorunla nasıl başa çıktıklarına dair bazı okumalar yaptık ve açık desteklemeden sonra boş bir satır ekleme modelini bulduk:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Görsel bir mola yapacaksanız, bunu bir ayraçla da yapabilirsiniz. Sonra görsel aralarınız da tutarlı hale gelir.

Düzenleme : K&R kullanılırken 'ekstra boş satır' çözümüne iki alternatif:

1 / İşlev değişkenlerini işlev gövdesinden farklı bir şekilde girinti

2 / İlk argümanı işlev ismi ile aynı satıra koyun ve yeni argümanlardaki diğer argümanları o argümanla aynı hizaya getirin.

Örnekler:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Düzenle

Tutarlılığın diğer hususlardan daha önemli olduğunu hala savunuyorum, ancak yerleşik bir emsalimiz yoksa, bir sonraki adımda ilerlemenin yolu budur.

Kardinal kurallar:

1. Projenin mevcut kodlama standardını izleyin.
2. Kodlama standardı yoksa ve başka birinin sahip olduğu bir kod tabanını düzenliyorsanız, ne kadar sevdiğiniz / ne hoşunuza gittiğiniz önemli değil, mevcut kodun stiliyle tutarlı olun.
3. Yeşil alanlı bir proje üzerinde çalışıyorsanız - diğer ekip üyeleriyle görüşün ve resmi veya resmi olmayan bir kodlama standardı üzerinde fikir birliğine varın.
4. Tek geliştirici olarak yeşil alanlı bir proje üzerinde çalışıyorsanız - kendi kararınızı verin ve ardından acımasızca tutarlı olun.

Üzerinde herhangi bir dış kısıtlama olmasa bile, mevcut (yaygın olarak kullanılan) bir kodlama standardı veya stil kılavuzunu aramak en iyisidir (IMO) ve bunu izlemeye çalışın. Kendi tarzınızı yuvarlarsanız, birkaç yıl içinde pişmanlık duymanız için iyi bir şans var.

Son olarak, mevcut stil denetleyicileri ve kod biçimlendiricileri kullanılarak uygulanan / uygulanabilen bir stil, el ile "uygulanması" gerekenden daha iyidir.

İlk yöntemin yararı, dikey olarak daha kompakt olması, bu nedenle ekranınıza daha fazla kod sığdırabilmenizin nedeni budur. İkinci yöntemin lehine duyduğum tek argüman açılış ve kapanış parantezlerinin eşleştirilmesini daha kolay hale getirdiği, ancak çoğu IDE'nin bunun için bir klavye kısayolu var ve bu aslında bir açılış braketini bir kapanışla eşleştirmek yerine yanlış bir cümle. braket Bir kapanış braketini aynı girinti seviyesindeki "blok başlangıcı" ifadesiyle eşleştirebilirsiniz (eğer öyleyse), bu yüzden bloğun başlangıcının nerede olduğunu belirlemek kadar kolaydır.

Bir satırın tamamını sadece bir parantez için harcamak için bir neden göremiyorum, önceki / while / if yapı zaten görsel olarak bir bloğun başlangıcını gösterir.

Bununla birlikte, kapanış dirseğinin kendi çizgisinde olması gerektiğine inanıyorum, çünkü bir bloğun sonunu ve çentiklenme yapısını görünür bir şekilde gösterecek bir şeye ihtiyacımız var.

tercih ederim

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

bitmiş

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

çünkü çizgi you.postAnswer();ilk bakışta okumak ve bulmak çok daha kolaydır. İkinci olarak, üstümdeki çizgiyle ( you.hasAnswer()) birleşerek gözlerimin okumaya daha fazla odaklanması gerekiyor.

Ben ilk yöntemi tercih ederim. Parantezler tamamen ayrı bir çizgiye değmez.

Mesele şu ki diş telleri önemli değil. Onlar sadece kodun ne anlama geldiğini, amacını ve uygulanma şeklini anlamada kesinlikle gereksiz olan sözdizimsel çöplerdir . Bunlar sadece düşük ekran alanı nedeniyle operatörlerin görsel gruplandırmasının mümkün olmadığı eski tarz C benzeri dillere bir övgüdür.

Hiç parantez olmadan Tamam olan diller (Python, Haskell, Ruby) vardır. Bu yalnızca diş tellerinin çöp olduğunu ve mümkün olduğunda onlar için bir çizgiyi haketmemesi gerektiğini doğrular:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Python'u kullanın ve argümanı tamamen kaldırın.

Kıvrımlı kaşlı ayraçların konumu

meta veri

Programcı tarafından IDE'de konfigüre edilebilir. Bu şekilde, yazara bakılmaksızın tüm kodlardaki sinir bozucu parantezler aynı görünüyor.

Değişir.

Javascript veya jQuery kodluyorum, ilk formu kullanın:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Ama eğer C # kodluyorsam, ikinci formu kullanıyorum, çünkü bu C # 'da yapmanın kurallı yolu.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Örneğinizin yazılabileceğini unutmayın

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

C # ile.

İlkini tercih ediyorum çünkü bu örnekteki hatayı görmek benim için daha zor.

if (value > maximum);
{
    dosomething();
}

bu örnekte olduğundan daha

if (value > maximum); {
    dosomething();
}

; {Sadece ile biten bir çizgiden daha bana daha yanlış görünüyor ;ben bunu fark daha yatkın değilim bu yüzden.

1 hafif bir değişkeni tercih ederim)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Neden?

• Ben her zaman kendi satırında parantez koyarak okunabilirliği azalttığını düşünüyorum . Ekranıma yalnızca belirli bir miktarda kaynak kod sığdırabilirim. Braket stili 2) çok fazla iç içe döngü ve koşullayıcı ile acı algoritmaları zorlu hale getirir.

• Ancak, ben istiyorum elseçünkü yeni bir satıra başlamak ifve elsebirbirine ait görsel. Önünde bir dirsek varsa else, neye ait olduğunu tespit etmek çok daha zordur.

• 3) kendini diskalifiye eder. Destekleri dışarıda bırakıp unutursanız, ne kötü şeyler olabileceğini hepimiz biliyoruz.

Bir yerde, bazı kitapların yazarlarının kodlarını bu şekilde biçimlendirmek istediklerini okudum:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Ancak yayıncılarının alan kısıtlamaları, bunu kullanmak zorunda kalmaları anlamına geliyordu:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Şimdi bunun doğru olup olmadığını bilmiyorum (daha fazla bulamadığım için), ancak sonuncu stil kitaplarda çok yaygın.

Kişisel düzeyde, parantezleri ayrı bir satırda şöyle tercih ederim:

a) yeni bir kapsamı gösterirler
b) Bir uyuşmazlığı olduğunda fark etmek daha kolaydır (bu IDE'de sizin için hataları vurgulayan bir sorundan daha az olsa da).

Ah, Bir Gerçek Brace Stili .

Her şey Kutsal Yol için düşünüldü - hatta bir peygamber bile (Richard "benim yolum ya da otoyol" Stallman).

Adam bir çok şey için yanlıştı, ama GNU diş teli söz konusu olduğunda dikkat çekiyor.

[Güncelleme] Işığı gördüm ve şimdi Allman'a ibadet ediyorum

İkinci örnek, okunabilirlik konusunda çok büyüğüm. Eğer blokları başka bir yoldan izlemeye dayanamıyorum.

Basit cevap: hata ayıklamak daha kolay ne?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

Hangi durumda ilk önce konuyu teşhis ettiniz?

Kişisel tercihler için çok fazla umrumda değil (beyaz ve diğerleri de dahil olmak üzere daha birçok stil var) ve kod okuma ve hata ayıklama yeteneğimi engellemediği sürece umurumda değil .

“Atık alan” argümanı olarak, onu satın almıyorum: Programı daha net hale getirmek için yine de mantıksal gruplar arasına boş satırlar ekliyorum.

Kimsenin farkına varamayacaksınız, ancak bu yüzden parantezler şartlı ile aynı çizgiye aittir (çok uzun şartlamalar hariç, ancak bu çok önemli bir durumdur):

C'de, bu geçerli bir yapıdır:

(Doğru) ise;
{
    char c;
    getchar (); // Giriş için bekleyin
}

Hızlı! Bu kod ne yapar? Eğer "girdi isteyen sonsuz döngü" cevabını verdiyseniz yanılıyorsunuz! Girdiye bile gelmiyor. Yakalanır while(true). Sonunda bu noktalı virgül dikkat edin. Bu model aslında olması gerektiği gibi görünmektedir; C değişkenlerinizi bir bloğun başlangıcında bildirmenizi gerektirir, bu yüzden yeni bir tane başlatıldı.

Bir kod satırı bir düşüncedir. Parantez, şartlı veya döngü içeren düşüncenin bir parçasıdır. Bu nedenle, aynı çizgiye aittirler .

İlk yöntemi seviyorum. IMO daha düzenli görünüyor ve sevdiğim daha kompakt.

EDIT: Ah, üçüncüsü. Mümkün olduğunda en iyisini seviyorum, çünkü daha küçük / daha düzenli.

Yazabilirsin:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Soruyu cevaplamak için; Kıvrımlı parantezleri kendi hatlarında tercih ederdim; Ve java'yı tutulmada kodlarken, varsayılan ayraç stiliyle savaşmak (veya yapılandırmak) ilgim yoktu, bu yüzden Mısır'la da gittim. Şimdi ikisiyle de iyiyim.

Neredeyse tüm cevaplar, "Ne yaparsanız yapın, bir veya iki ile yapışmak" konusunda bazı farklılıklar söylüyor.

Bu yüzden bir an için düşündüm ve itiraf etmeliydim ki, bu kadar önemli görmedim. Biri dürüstçe aşağıdakilerin takip etmenin zor olduğunu söyleyebilir mi?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Kimseden emin değilim ... ama zihinsel olarak stiller arasında geçiş yaparken kesinlikle sıfır problemim var. Kodun ne yaptığını bulmam biraz zaman aldı, ama bu rastgele C-benzeri sözdizimi yazmamın sonucuydu. :)

Çok alçakgönüllü görüşüme göre, açma parantezleri kod okunabilirliği ile neredeyse tamamen alakasızdır. Bir stilin veya diğerinin fark yarattığı yukarıda sıralanan birkaç köşe durumu vardır, ancak çoğu zaman, boş çizgilerin makul şekilde kullanılması bunu temizler.

FWIW, iş yerindeki kodlama stillerimiz biraz daha yapısal bir form 1 ve değiştirilmiş bir form 3 kullanıyor. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Form 2'yi şiddetle tercih edenler form 1'in bu versiyonunu daha iyi bulacaklarsa, boş satır daha güçlü bir görsel ayrım sağladığından dolayı merak ediyorum.

Bunun henüz ortaya çıkmamasına şaşırdım. İkinci yaklaşımı tercih ediyorum çünkü bloğu daha kolay seçebilmenizi sağlıyor.

Parantezler aynı sütunda ve kendi satırlarında başlayıp bittiğinde, kenar boşluğundan veya imlecin 0 sütunundaki imleç ile seçim yapabilirsiniz. Bu, genellikle fare seçimiyle veya klavye seçimiyle daha az tuş vuruşuyla daha cömert bir alan anlamına gelir.

Başlangıçta koşullu ile aynı hat üzerinde parantez ile çalıştım, ancak değiştiğimde çalıştığım hızı artırdım. Elbette gece ve gündüz değil, ama koşullanıcılarınızın yanındaki kaşlı ayraçlarla çalışmanızı yavaşlatacak bir şey.

Şahsen ikinci yolu sevdim.

Ancak, göstereceğim yol bence en iyisidir, çünkü bu en büyük iş güvenliğine yol açar! Üniversitemden bir öğrenci, ev ödevlerinde yardım etmemi istedi ve bu onun kodu böyle görünüyordu. Tüm program tek bir blok gibi görünüyordu. İlginç olan, programdaki hataların% 95'inin uyumsuz diş tellerinden kaynaklanmış olmasıdır. Diş telleri eşleştikten sonra diğer% 5 açıktı.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

Benim kişisel tercihim ilk yöntemdir, muhtemelen PHP'yi ilk öğrendiğim yol budur.

Tek satırlı ififadeler için kullanacağım

if (you.hasAnswer()) you.postAnswer();

you.postAnswer();Çok uzun bir şey değilse , you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);muhtemelen ilk türe geri döneceğim gibi :

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Asla bir satır sonu kullanmayacağım ve bir elseifade varsa, bu yöntemi asla kullanmayacağım .

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

teorik bir olasılıktır, fakat hiç kullanmayacağım bir şey. Bunun dönüşmesi gerekecekti

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Yapmamalılar; benim için ilk yöntem.

İkinciye baktığımda, kullanılmayan çizgiler (son kapanış ayracı dışında yalnızca üzerinde teller olan) nedeniyle, kodun sürekliliğini kırıyor gibi hissediyor. Hızlı okuyamıyorum çünkü genellikle kod amaçlı bir ayrım veya bunun gibi bir şey anlamına gelen boş satırlara özel olarak dikkat etmem gerekiyor, ancak hiçbir durumda "bu satır bir küme parantezine ait değil" (yalnızca anlamı yineliyor) girinti).

Her neyse, tıpkı bir metin yazarken olduğu gibi ... bir paragrafın başına bir girintinin eklenmesi gereksizdir, eğer ondan önce boş bir satır varsa (paragraf değişikliğinin iki işareti), doğru girintili.

Artı, daha önce de belirtildiği gibi, ekrana daha fazla kod sığdırılmasına izin verir, aksi halde biraz fazla üretkendir.

Bu platforma / dile / sözleşmelere bağlıdır

Java’da:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

C # ile

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

C’de:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Java adamlarının kendi stillerini C # kodu ile kullanması ve tam tersi olduğunda nefret ediyorum.

Söyleyebileceğim tek şey, eğer # 3 yönteminin hayranıysanız, dünyadaki her IDE kod biçimlendiricisine zulmedileceksiniz.

İlk yöntemi basitçe kullanıyorum çünkü ekranda daha kompakt ve daha fazla kod bulunuyor. Ben kendimi hiçbir zaman diş tellerini eşleştirmekle ilgili bir sorun yaşamadım ( ifKoşulları eklemeden önce ifadeyle birlikte bunları her zaman yazıyorum ve çoğu ortam eşleşen ayracı atlamanıza izin veriyor).

Eğer varsa vermedi görsel parantez çifti gerekir, o zaman ben ikinci yöntemi tercih ediyorum. Ancak bu bir seferde daha az kod sağlar ve bu da daha fazla kaydırma yapmanızı gerektirir. Ve bu, en azından benim için, okuma kodu üzerinde düzgün şekilde hizalanmış parantezlerden daha büyük bir etkiye sahip. Kaydırmadan nefret ediyorum. Sonra tekrar, eğer tek bir ififadede kaydırmanız gerekirse , büyük olasılıkla çok büyük ve yeniden düzenlemeye ihtiyaç duyuyor.

Fakat; hepsinden en önemlisi tutarlılık. Birini veya diğerini kullanın - asla ikisini de yapmayın!

12'de ilk programlama öğrenirken, Microsoft kodlama öğreticileri böyle olduğu için bir sonraki satıra diş tellerini koydum. Ayrıca o zaman 4 boşluklu TABS ile girintili çıkarıyorum.

Birkaç yıl sonra, Java ve JavaScript öğrendim ve aynı satırda daha fazla parantez gördüm, bu yüzden değiştim. Ben de 2 boşluklu SPACES ile girintiye başladım.

Parantezleri hizalı tutan fakat yer israf etmeyen 4. seçenek vardır:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Tek sorun, çoğu IDE'nin otomatik biçimlendiricisinin bunun üzerine boğulmasıdır.

Bazı kodlama kısıtlamalarının veya bazı standartların proje yöneticisi tarafından belirlenmiş olduğu bir proje üzerinde çalışmadığınız sürece, bu proje üzerinde çalışan tüm programcıların kodlama sırasında izlemesi gereken sürece bağlıdır.

Şahsen ben 1. yöntemi tercih ederdim.

Ayrıca 3. yöntemde göstermek istediğini anlamadım.

Bu yanlış bir yol değil mi? Örneğin bir durumu düşünün ..

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

Şimdi, birisi if bloğuna daha fazla ifade eklemek isterse ?

Bu durumda 3. yöntemi kullanırsanız, derleyici sözdizimi hatasını atar.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();