Tek satırlı if veya döngü için kaşlı ayraçlar (yani {}) kullanmanın amacı nedir?

C ++ öğretim elemanımın bazı ders notlarını okuyorum ve şunları yazdı:

1. Girintiyi Kullan // Tamam
2. Asla operatör önceliğine güvenmeyin - Her zaman parantez kullanın // Tamam
3. Her zaman bir {} bloğu kullanın - tek bir satır için bile // tamam değil , neden ???
4. Karşılaştırmanın sol tarafındaki sabit nesne // Tamam
5. > = 0 // güzel hile olan değişkenler için imzasız kullanın
6. Silme işleminden sonra İşaretçiyi NULL olarak ayarlayın - Çift silme koruması // kötü değil

3. teknik benim için net değil: Bir satırı bir a yerleştirerek ne kazanırdım { ... }?

Örneğin, şu garip kodu alın:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

ve aşağıdakilerle değiştirin:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

1. sürümü kullanmanın yararı nedir?

En de değiştirmeye çalışmayın edelim ibiz artırır zaman j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

Oh hayır! Python'dan geliyor, bu iyi görünüyor, ama aslında, buna eşdeğer olduğu için değil:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Tabii ki, bu aptalca bir hatadır, ancak deneyimli bir programcının bile yapabileceği bir hatadır.

Başka çok iyi bir nedeni de işaret edilmektedir ta.speot.is cevabı .

Aklıma gelen üçüncü bir şey iç içe geçmiş if:

if (cond1)
   if (cond2) 
      doSomething();

Şimdi, karşılanmadığı doSomethingElse()zaman istediğinizi varsayalım cond1(yeni özellik). Yani:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

elseiç ile olan ilişkiden beri yanlıştır if.

Düzenleme: Bu biraz dikkat çekiyor, benim görüşüme açıklık getireceğim. Yanıtladığım soru:

1. sürümü kullanmanın yararı nedir?

Hangi tarif ettiğim. Bazı faydaları var. Ancak IMO, "her zaman" kuralları her zaman geçerli değildir. Bu yüzden tamamen desteklemiyorum

Her zaman bir {} bloğu kullanın - tek bir satır için bile // tamam değil, neden ???

Her zaman bir {}blok kullan demiyorum . Yeterince basit bir durum ve davranış ise, yapmayın. Birisinin daha sonra girebileceğinden şüpheleniyorsanız ve kodunuzu işlevsellik eklemek için değiştirirseniz yapın.

{Ve kullanmıyorsanız kontrol akışını yanlışlıkla yorumlarla değiştirmek çok kolaydır }. Örneğin:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Eğer dışarı yorum yaparsanız do_something_else()tek bir satır yorum ile, bu ile bitireceğiz:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Derlenir, ancak must_always_do_this()her zaman çağrılmaz.

Kod tabanımızda bu sorunu yaşadık, birileri yayınlanmadan önce bazı işlevleri çok hızlı bir şekilde devre dışı bırakmak için gitti. Neyse ki kod incelemesinde yakaladık.

Öğretim elemanının yeterliliği konusunda şüphelerim var. Puanlarını göz önünde bulundurarak:

1. tamam
2. Herkes gerçekten yazar mı (veya okumak ister) (b*b) - ((4*a)*c) ? Bazı öncelikler açıktır (veya olması gerekir) ve ekstra parantezler sadece karışıklığa katkıda bulunur. (Öte yandan, gerekli olmadıklarını bilseniz bile, parantezleri daha az belirgin durumlarda kullanırsınız.)
3. Bir çeşit. Koşulları ve döngüleri biçimlendirmek için iki geniş yayılma kuralı vardır:

   eğer (koşullu) {
       kod;
   }
   

   ve:

   eğer (koşul)
   {
       kod;
   }
   

   İlkinde ona katılırdım. Açıklık {o kadar görünür değil, bu yüzden her zaman orada olduğunu varsaymak en iyisidir. Ancak ikincisinde, ben (ve birlikte çalıştığım insanların çoğu), parantezleri tek bir ifadeye dahil etmede sorun yaşamıyor. (Tabii ki, girintinin sistematik olması ve bu stili sürekli olarak kullanmanız şartıyla. (Ve çok iyi programcılar, çok okunabilir kod yazarak, ilk yolu biçimlendirirken bile parantezleri atlarlar.)
4. HAYIR . Gibi şeyler if ( NULL == ptr )okunabilirliği engelleyecek kadar çirkin. Karşılaştırmaları sezgisel olarak yazın. (Bu çoğu durumda sağdaki sabit ile sonuçlanır.) Onun 4'ü kötü tavsiye; kodu doğal olmayan yapan her şey onu daha az okunabilir yapar.
5. HAYIR . Her şey olabilir ama intözel durumlar için ayrılmıştır. Deneyimli C ve C ++ programcılarına unsignedsinyal bit operatörlerinin kullanımı. C ++ gerçek bir kardinal tipine (veya başka bir etkili subrange tipine) sahip değildir; unsignedpromosyon kuralları nedeniyle sayısal değerler için çalışmaz. Seri numaraları gibi, hiçbir aritmetik işlemin anlamlı olmayacağı sayısal değerler tahmin edilebilir unsigned. Ancak buna karşı çıkarım çünkü yanlış mesaj gönderir: bitsel işlemler de mantıklı değil. Temel kural, integral türlerinin int, _unless_ başka bir tür kullanmanın önemli bir nedeni olmasıdır.
6. HAYIR . Bunu sistematik olarak yapmak yanıltıcıdır ve aslında hiçbir şeye karşı koruma sağlamaz. Sıkı OO kodunda, delete this;(ve ayarlayamıyor genellikle en sık olduğu thisiçin NULL) ve aksi takdirde çoğu deletedaha sonra yine işaretçi erişemez böylece, yıkıcılar içindedir. Ve bunu ayarlamak, NULLetrafta yüzen diğer işaretçiler hakkında hiçbir şey yapmaz. İşaretçiyi sistematik olarak ayarlamak NULLyanlış bir güvenlik hissi verir ve size hiçbir şey satın almaz.

Tipik referansların herhangi birindeki koda bakın. Stroustrup, örneğin birincisi dışında verdiğiniz her kuralı ihlal ediyor.

Başka bir öğretim üyesi bulmanızı öneririm. Neden bahsettiğini gerçekten bilen biri.

Diğer tüm cevaplar öğretim elemanınızın kuralını savunur 3.

Size katıldığımı söyleyeyim: kural gereksiz ve bunu tavsiye etmem. Her zaman kıvırcık parantez eklerseniz teorik olarak hataları önlediği doğrudur . Öte yandan, gerçek hayatta bu problemle hiç karşılaşmadım : diğer cevapların ima ettiği aksine, bir kez gerekli olduklarında kıvırcık parantezleri eklemeyi unutmadım. Doğru girinti kullanırsanız, birden fazla ifade girintilendikten sonra süslü parantez eklemeniz gerektiği hemen anlaşılır.

“Bileşen 10” un cevabı aslında bunun gerçekten bir hataya yol açabileceği akla gelebilecek tek durumu vurgulamaktadır. Ancak öte yandan, kodun düzenli ifadeyle değiştirilmesi her zaman büyük bir özen gerektirir.

Şimdi madalyanın diğer tarafına bakalım: her zaman kıvırcık parantez kullanmanın bir dezavantajı var mı? Diğer cevaplar bu noktayı görmezden geliyor. Ama olan bir dezavantaj: dikey ekran çok yer kaplıyor ve bu size gerekenden daha fazla kaydırmak zorunda anlamına gelir çünkü bu da sizin kod okunamaz yapabilirsiniz.

Başlangıçta çok sayıda güvenlik yan tümcesine sahip bir işlevi düşünün (ve evet, aşağıdaki kötü C ++ kodu ancak diğer dillerde bu oldukça yaygın bir durum olacaktır):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

Bu korkunç bir kod ve aşağıdakilerin büyük ölçüde daha okunabilir olduğunu şiddetle savunuyorum:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Benzer şekilde, kısa iç içe döngüler kıvırcık parantezleri atlamaktan faydalanır:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

İle karşılaştırmak:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

İlk kod özlüdür; ikinci kod şişirilir.

Ve evet, bu , açılış çizgisini bir önceki hatta koyarak bir dereceye kadar hafifletilebilir . Ama bu olurdu hala herhangi kıvırcık parantez olmadan kod daha az okunabilir.

Kısacası: ekran alanı kaplayan gereksiz kod yazmayın.

Üzerinde çalıştığım kod temeli, parantezlere patolojik bir nefreti olan insanlar tarafından kodla dağılmış ve daha sonra gelen insanlar için, sürdürülebilirlik açısından gerçekten bir fark yaratabilir.

Karşılaştığım en sık karşılaşılan sorunlu örnek şudur:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Bu yüzden gelip o zaman bir ifade eklemek istediğimde, dikkatli olmazsam bununla kolayca sonuçlanabilirim:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

O neden hiç olur, ayıklama birkaç karıştı dakika ~ sürer 1 saniyede parantez eklemek ve en azından seni kurtarabilecek göz önüne alındığında değil azaltılmış belirsizlik seçeneği ile gitmek? Bana sahte ekonomi gibi geliyor.

Benim 2c:

Girinti Kullan

belli ki

Asla operatör önceliğine güvenmeyin - Her zaman parantez kullanın

"Asla ve" her zaman "kelimeleri kullanmazdım, ama genel olarak bu kuralın yararlı olduğunu görüyorum.Bazı dillerde (Lisp, Smalltalk) bu bir sorun değil.

Her zaman bir {} bloğu kullanın - tek bir satır için bile

Bunu asla yapmadım ve hiçbir zaman tek bir sorunum olmadı, ama bunun öğrenciler için nasıl iyi olabileceğini görebiliyorum, özellikle. daha önce Python okuduysa.

Karşılaştırmanın sol tarafındaki sabit nesne

Yoda koşulları? Hayır lütfen. Okunabilirliği incitir. Kodunuzu derlerken maksimum uyarı seviyesini kullanmanız yeterlidir.

> = 0 olan değişkenler için imzasız kullanın

TAMAM. Çok komik, Stroustrup'un aynı fikirde olmadığını duydum.

Silme işleminden sonra İşaretçiyi NULL olarak ayarlayın - Çift silme koruması

Kötü tavsiye! Asla silinmiş veya var olmayan bir nesneyi gösteren bir işaretçi kullanmayın.

daha sezgisel ve kolay anlaşılır. Niyeti açıklığa kavuşturuyor.

Ve bu yeni bir kullanıcı bilmeden kaçırabilir, kodun sonu yok olmasını sağlar {, }yeni bir kod deyimi eklerken.

Yukarıdaki çok mantıklı önerilere eklemek için, bunun kritik hale geldiği bazı kodları yeniden düzenlerken karşılaştığım bir örnek şöyleydi: Bir API'den diğerine geçmek için çok büyük bir kod tabanını değiştiriyordum. İlk API, Şirket Kimliğini aşağıdaki gibi ayarlamak için bir çağrı yaptı:

setCompIds( const std::string& compId, const std::string& compSubId );

oysa ikame iki görüşmeye ihtiyaç duydu:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Bunu çok başarılı olan düzenli ifadeler kullanarak değiştirmeye başladım. Kodu astyle de geçtik , bu da gerçekten çok daha okunabilir hale getirdi. Sonra, gözden geçirme süreci boyunca kısmen, bazı koşullu durumlarda bunu değiştirdiğini keşfettim:

if ( condition )
   setCompIds( compId, compSubId );

Buna:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

ki bu açıkça gerekli olan şey değil. Ben tamamen bir blok içinde yerine muamele ve daha sonra goofy seyir sona eren bir şey el ile değiştirerek tekrar yapmak zorunda kaldı (en azından yanlış olmaz.)

Fark ettim Astyle'nin artık --add-bracketshiçbiri olmayan köşeli parantez eklemenize izin veren bir seçeneğe sahip ve kendinizi olduğu gibi aynı konumda bulursanız bunu şiddetle tavsiye ederim.

{}Açık olduğu birkaç durum dışında her yerde kullanıyorum . Tek satır durumlardan biridir:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

Geri dönmeden önce bir yöntem eklediğinizde size zarar verebilir. Girinti, koşul karşılandığında dönüşün yürütüldüğünü gösterir, ancak her zaman dönecektir.

C # ifadesini kullanarak diğer örnek

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

eşdeğer

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

Düşünebileceğim en uygun örnek:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Hangi ifolacak elseeşleşmiş olmalıdır? Girinti dış ima ifalır else, ama bu derleyici bunu görecek kadar aslında değil; İç if alacak elseve dışif buna gerek yoktur. Bu kodun neden beklentilerinizi karşılayamayacağını denetleyerek bunu anlamanız gerektiğini bilmelisiniz (veya hata ayıklama modunda bu şekilde davrandığını görmelisiniz). Python'u tanıyorsanız daha kafa karıştırıcı olur; bu durumda girintinin kod bloklarını tanımladığını bilirsiniz, böylece girintiye göre değerlendirmesini beklersiniz. Ancak, C # boşluk hakkında uçan bir flip vermez.

Şimdi, bu "yüzünde her zaman parantez kullanın" kuralına özellikle katılmıyorum dedi. Kodu çok dikey olarak gürültülü hale getirir ve hızlı bir şekilde okuma yeteneğini azaltır. İfade şu ise:

if(someCondition)
   DoSomething();

... o zaman böyle yazılmalıdır. "Her zaman parantez kullan" ifadesi, "her zaman matematiksel işlemleri parantez içine al" gibi sesler çıkarır. Bu, çok basit bir ifadeyi , yakın bir paren (bir kodlayıcının bane'si) kaçırma olasılığını a * b + c / dgetirecek ((a * b) + (c / d))ve ne için? İşlem sırası iyi bilinir ve iyi uygulanır, bu nedenle parantezler gereksizdir. Parantezleri yalnızca normalde uygulanmasından farklı bir işlem sırası uygulamak için kullanırsınız: a * (b+c) / dörneğin. Blok parantezler benzerdir; bunları varsayılandan farklı olduğu ve "açık" olmadığı (öznel, ancak genellikle sağduyu) durumlarda ne yapmak istediğinizi tanımlamak için kullanın.

Cevaplara baktığımızda, hiç kimse alışkanlık yaptığım türden bir alışkanlığı açıkça belirtmedi ve kodunuzun hikayesini anlattı:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

Oluyor:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Eğer if ile aynı satırj++ üzerine koyarak kimseye işaret etmelidir, "Ben sadece bu bloğun artmasını istiyorum " . Coursethis itibariyle burada bir kesme noktası koyarak çünkü hattı, mümkün olduğunca basit olarak ise sadece değerli olduğunu peri bahseder, çok faydalı olacak değildir.j

Aslında ben sadece java bu tür 'kod' olan Twitter fırtına API parçası üzerinde çalıştım, İşte bu slayt gösterisi sayfa 43 , relipant snippet yürütme kodu formu :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

For döngü bloğu içinde iki şey var, bu yüzden bu kodu satır içi olmaz. Yani asla :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

Korkunç ve işe yarayıp yaramadığını bile bilmiyorum; bunu yapma . Yeni çizgiler ve kaşlı ayraçlar, aynı şekilde virgül veya noktalı virgülün düzyazıda yaptığı gibi, ayrı ancak ilgili kod parçalarını ayırt etmeye yardımcı olur. Yukarıdaki blok, birkaç cümle ve ayrı kısımları ayırt etmek için asla kırılmayan veya duraklamayan diğer bazı ifadelerle çok uzun bir cümle kadar kötüdür.

Gerçekten başka birine telgraf yapmak istiyorsanız, üçlü bir operatör veya ?:form kullanan tek satırlık bir iştir :

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Ama bu kod-golf üzerinde verging olduğunu ve ben büyük bir uygulama sanmıyorum (j ++ koymak :ya da değil bir tarafa koymak gerekir açık değil). Not Daha önce C ++ üçlü bir işleç çalıştırmadım, bunun işe yarayıp yaramadığını bilmiyorum, ama var .

Kısacası:

Okuyucunuzun (kodu yöneten kişinin) hikayenizi (kod) nasıl yorumladığını düşünün. Onlar için olabildiğince netleştirin. Acemi kodlayıcının / öğrencinin bunu sürdürdüğünü biliyorsanız, belki de {}mümkün olduğunca çok şey bırakın , böylece kafaları karışmaz.

Çünkü iki ifadeniz olmadan {}, bir konuyu kaçırmak kolaydır. Kodun böyle göründüğünü varsayalım.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

İyi görünüyor. Bununla ilgili sorunu, özellikle kodu içeren işlev çok daha büyük olduğunda kaçırmak gerçekten kolaydır. Mesele şudur ki goto fail, koşulsuz bir şekilde yürütülmüştür. Bunun ne kadar sinir bozucu olduğunu kolayca hayal edebilirsiniz ( hash_updateher şeyin hash_updateişlevinde iyi görünmesinden sonra sonun neden başarısız olduğunu sormanızı sağlar).

Ancak, bu {}her yere eklediğim anlamına gelmez (bence {}her yeri görmek sinir bozucu). Sorunlara neden olsa da, kişisel kodlama tarzım {}aynı hatta olmadıkları sürece koşulsuzları yasakladığından, kendi projelerim için hiçbir zaman olmadı (evet, kodlama tarzımın geleneksel olmadığını kabul ediyorum, ama hoşuma gidiyor ve ben diğer projelere katkıda bulunurken projenin kod stilini kullanın). Bu, aşağıdaki kodu iyi yapar.

if (something) goto fail;

Ama şu değil.

if (something)
    goto fail;

Döngülerinizin ve koşullu bloklarınızın kapsamını açıkça tanımlayarak kodunuzu daha okunabilir hale getirir. Ayrıca sizi yanlışlıkla yapılan hatalardan da korur.

wrt 6: Boş bir işaretçiyi silmek bir işlem olmadığı için daha güvenlidir. Bu nedenle, yanlışlıkla bu yoldan iki kez geçerseniz, bellek bozulmasının, boş olan veya başka bir şeye tahsis edilen belleği boşaltmasına neden olmazsınız.

Bu, yaşamları çok net olmayan ve yok edildikten sonra yeniden oluşturulduğu bilinen statik dosya kapsamı nesneleri ve tek tonları ile ilgili bir konudur.

Çoğu durumda, auto_ptrs kullanarak buna olan ihtiyacı önleyebilirsiniz

Luchian'ın kabul edilen cevabını seviyorum, aslında onun doğru yolunu öğrendim, bu yüzden tek satırlı bloklar için bile her zaman parantez kullanıyorum. Ancak, örneğinizde olduğu gibi, bir filtre yazarken şahsen bir istisna yapıyorum. Bu:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

bana dağınık görünüyor. Gerçekten döngü tek bir eylem olduğunda, for döngüsünü ve if ifadesini ayrı eylemlere ayırır: 2 ile bölünebilen tüm tam sayıları saymak. Daha anlamlı bir dilde, bu şöyle yazılabilir:

j = [1..100].filter(_%2 == 0).Count

Kapanışı olmayan dillerde, filtre tek bir ifadede ifade edilemez, ancak bir for döngüsü ve ardından bir if ifadesi olmalıdır. Ancak, hala programcının zihninde bir eylemdir ve bunun koda yansıtılması gerektiğine inanıyorum:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Yukarıda açıklanan hataları önlemeye yardımcı olmak için bir seçenek, parantez kullanmadığınızda ne olmasını istediğinizi satır içine almaktır. Kodu değiştirmeye çalıştığınızda hataları fark etmemeyi çok daha zorlaştırır.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Eğer bir derleyici iseniz, hiçbir fark yaratmaz. Her ikisi de aynı.

Ancak programcılar için birincisi daha açık, okunması kolay ve daha az hataya açıktır.

Kıvırcık parantez eklemeye başka bir örnek. Bir kez bir hata arıyordum ve böyle bir kod buldum:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Yöntemi satır satır okursanız, yöntemde doğru değilse dönen bir koşul olduğunu fark edeceksiniz. Ama aslında bazı koşullara bağlı olarak bazı değişkenler ayarlayan 100 diğer basit olay işleyicisi gibi görünüyor. Ve bir gün Hızlı Kodlayıcı gelir ve yöntemin sonuna ek değişken ayarı ifadesi ekler:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

Sonuç olarak, SetAnotherVariableUnconditionnaly, SomeConditionIsMet () olduğunda yürütülür, ancak hızlı adam bunu fark etmedi çünkü tüm satırlar neredeyse benzer boyuttadır ve dönüş koşulu dikey olarak girintili olsa bile, o kadar da fark edilmez.

Koşullu getiri şu şekilde biçimlendirilirse:

if (!SomeConditionIsMet())
{
    return;
}

çok dikkat çekicidir ve Hızlı Kodlayıcı bir bakışta bulacaktır.

Birincisinin sonra net olduğunu düşünüyorum. Kapanma talimatı verir, kod karmaşıklaştığında küçük kod iyi {...}olur endifveya olmasa bile çok yardımcı olur.begin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

İşiniz bittiğinde işaretçiyi NULL olarak ayarlamak en iyisidir.

İşte bir neden:

A sınıfı aşağıdakileri yapar:

1. Bir bellek bloğu tahsis eder
2. Sonra bir süre sonra, bu bellek bloğunu siler, ancak işaretçiyi NULL olarak ayarlamaz.

B Sınıfı aşağıdakileri yapar

1. Belleği ayırır (ve bu örnekte A sınıfı tarafından silinen aynı bellek bloğuna sahip olur)

Bu noktada hem A Sınıfı hem de B Sınıfı, aynı bellek bloğuna işaret eden işaretçiler içerir, A Sınıfı söz konusu olduğunda, bu bellek bloğu, bittiği için mevcut değildir.

Aşağıdaki sorunu düşünün:

Sınıf A'da şimdi Sınıf B'ye ait olan belleğe yazılmasına neden olan bir mantık hatası varsa ne olur?

Bu özel durumda, bellek adresi yasal olduğu için kötü erişim özel durumu hatası almayacaksınız, ancak A sınıfı şimdi B sınıfı verilerini etkin bir şekilde bozuyor.

B Sınıfı, beklenmedik değerlerle karşılaşırsa çökebilir ve çökme olasılığı varsa, sorun A probleminde B sınıfında bu hatayı avlamak için oldukça uzun zaman harcayacaksınız.

Silinen bellek işaretçisini NULL olarak ayarlamış olsaydınız, A Sınıfındaki herhangi bir mantık hatası NULL işaretçisine yazmaya çalıştığında bir istisna hatası alırsınız.

İşaretçiler ikinci kez NULL olduğunda çift silme ile mantık hatası konusunda endişeleriniz varsa, bunun için onay ekleyin.

Ayrıca: Oyu düşürecekseniz, lütfen açıklayınız.

Her zaman kıvırcık parantezlere sahip olmak çok basit ve sağlam bir kuraldır. Ancak çok sayıda diş teli olduğunda kod yetersiz görünebilir. Kurallar kıvırcık parantezleri atlamaya izin veriyorsa, daha ayrıntılı stil kuralları ve daha sofistike araçlar olmalıdır. Aksi takdirde kaotik ve kafa karıştırıcı (zarif olmayan) kodlarla kolayca sonuçlanabilir. Bu nedenle, kullanılan stil kılavuzlarından ve araçlardan ayrı olarak tek stil kuralına bakmak muhtemelen sonuç vermez. Bu kural # 3 hakkında, diğer cevaplarda bile belirtilmemiş olan bazı önemli detayları getireceğim.

İlk ilginç detay, bu kuralın savunucularının çoğunun davayı ihlal ettiğini kabul etmesidir else. Başka bir deyişle, böyle bir kodun incelenmesini talep etmezler:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

Bunun yerine, görürlerse böyle yazmayı önerebilirler:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Hiçbir kıvırcık parantez arasında bulunmaktadır beri bu teknik olarak bu kuralın ihlali olduğunu elseveif . Kuralın böyle bir ikiliği, akılsız bir araçla otomatik olarak kod tabanına uygulanmaya çalışıldığında ortaya çıkar. Gerçekten, neden tartışmak için, bir aracın stili otomatik olarak uygulamasına izin verin.

İkinci ayrıntı (bu kuralın savunucuları tarafından da sıklıkla unutulur) oluşabilecek hataların asla sadece bu kuralın 3'ünün ihlali nedeniyle olmamasıdır. Aslında neredeyse her zaman # 1 kuralı ihlalleri içerir (kimsenin tartışamadığı). Yine otomatik araçlar açısından, # 1 kuralı ihlal edildiğinde hemen şikayet eden bir araç yapmak zor değildir ve bu nedenle hataların çoğu zamanında yakalanabilir.

Üçüncü ayrıntı (genellikle bu kuralın muhalifleri tarafından unutulur), tek noktalı virgülle temsil edilen boş ifadenin kafa karıştırıcı doğasıdır. Biraz tecrübesi olan çoğu geliştirici er ya da geç tek yanlış noktalı virgül ya da tek noktalı virgül kullanılarak yazılan boş deyim ile karıştı. Tek noktalı virgül yerine iki kıvrımlı parantezin görsel olarak fark edilmesi daha kolaydır.

Her zaman {}tek satır için kullanılmadığını itiraf etmeliyim , ancak bu iyi bir uygulama.

• Diyelim ki köşeli parantezsiz şöyle bir kod yazıyorsunuz:

  için (int i = 0; i <100; ++ i) için (int j = 0; j <100; ++ j) DoSingleStuff ();

Ve bir süre sonra jbaşka şeyler eklemek istersiniz ve bunu hizalama ile yaparsınız ve parantez eklemeyi unutursunuz.

• Bellek ayrılması daha hızlıdır. Diyelim ki büyük bir kapsamınız var ve içeride büyük diziler oluşturuyorsunuz new. Bu diziler, kapsamdan çıktıktan hemen sonra bellekten siliniyor. Ancak bu diziyi tek bir yerde kullanmanız ve bir süre yığın halinde olması ve bir çeşit çöp olması mümkündür. Bir istifin sınırlı ve oldukça küçük bir boyutu olduğundan, istif boyutunu aşmak mümkündür. Bu nedenle bazı durumlarda bundan {}kaçınmak için yazmak daha iyidir . NOT bu tek satır için değil, bu tür durumlar için:

  if (...) {// SomeStuff ... {// if, while, vb. yok. // SomeOtherStuff} // SomeMoreStuff}

• Kullanmanın üçüncü yolu ikinciye benzer. Bu sadece yığın temiz hale getirme için değil açmak , bazı işlevler. mutexUzun işlevlerde kullanıyorsanız , verilere erişmeden hemen önce ve bunu okuduktan / yazdıktan hemen sonra kilitlemek ve kilidini açmak daha iyidir. NOT bazı kendi varsa bu şekilde kullanıyor classveya structbirlikte constructorve destructorkilit belleğine.

• Dahası:

  if (...) if (...) SomeStuff (); başka SomeOtherStuff (); // eğer ikinciye gider, ama alligment önce olduğunu gösterir ...

Sonuçta, her zaman {}tek bir satır için kullanmanın en iyi yolu nedir diyemem ama bunu yapmak kötü bir şey değil.

ÖNEMLİ DÜZENLEME Tek bir satır için derleme kodu parantezleri yazdığınızda hiçbir şey yapmaz, ancak kodunuz yorumlanacaksa kodu çok yavaş yavaşlatır. Çok az.

Kontrol ifadeleri yazmanın birkaç olası yolu vardır; bunların bazı kombinasyonları okunabilirliği bozmadan birlikte bulunabilir, ancak diğer kombinasyonlar sorun yaratacaktır. Tarzı

if (condition)
  statement;

kontrol ifadeleri yazmanın diğer bazı yollarıyla rahatça birlikte var olacak, ancak diğerleriyle o kadar iyi olmayacak. Çok satırlı denetimli ifadeler şöyle yazılırsa:

if (condition)
{
  statement;
  statement;
}

hangi ififadelerin tek bir satırı ve hangilerinin birden fazla satırı kontrol ettiği görsel olarak açık olacaktır . Ancak, çok satırlı ififadeler şöyle yazılırsa:

if (condition) {
  statement;
  statement;
}

o zaman ifgerekli parantez eklemeden tek ifadeli yapıları genişletmeye çalışan birinin olasılığı çok daha yüksek olabilir.

ifKod tabanı formdan önemli ölçüde yararlanırsa, bir sonraki satırdaki tekli ifade de sorunlu olabilir.

if (condition) statement;

Kendi tercihim, ifadenin kendi satırında olması, ifbenzer kontrol bloklarına sahip birçok ifadenin olduğu durumlar dışında genellikle okunabilirliği arttırmasıdır;

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

bu durumda, genellikle ifdiğer kodlardan görsel olarak ayırmak için bu tür ifade gruplarından önce boş bir satırla devam edeceğim . Hepsi ifaynı girinti ile başlayan bir dizi ifadeye sahip olmak, olağandışı bir şey olduğuna dair net bir görsel gösterge sağlayacaktır.