Parantezleri gerekli olmasa bile mantıklı ifadelerde kullanmalı mıyım?

Diyelim ki bir boole şartım var a AND b OR c AND dve ANDöncekinden daha yüksek bir işlem sırası olan bir dili kullanıyorum OR. Bu kod satırını yazabilirim:

If (a AND b) OR (c AND d) Then ...

Ama gerçekten, bu eşdeğerdir:

If a AND b OR c AND d Then ...

Yabancı parantezlerin dahil edilmesinde veya dışında herhangi bir argüman var mı? Pratik tecrübe onları okunabilirlik için dahil etmeye değer olduğunu gösteriyor mu? Yoksa bir geliştiricinin gerçekten oturması ve dillerinin temeline güvenmesi gerektiğinin bir işareti mi?

İyi geliştiriciler açık ve doğru kod yazmaya çalışır . Koşullu parantez içinde, kesinlikle gerekmese bile, her ikisine de yardımcı olun.

Açıklığa gelince , koddaki yorumlar gibi parantezleri düşünün: kesinlikle gerekli değiller ve teorik olarak yetkili bir geliştirici onlarsız kod çözebilmelidir. Ve yine de, bu ipuçları son derece yararlı, çünkü:

• Kodu anlamak için gereken işi azaltırlar.
• Geliştiricinin amacının onayını sağlarlar.

Ayrıca, girintiler, boşluklar ve diğer stil standartları gibi ekstra parantezler, kodu görsel olarak mantıklı bir şekilde düzenlemenize yardımcı olur.

Doğruluk için parantez içermeyen koşullar saçma hataların reçetesidir. Oldukları zaman, bulunmaları zor olan böcekler olabilir - çünkü çoğu zaman yanlış bir durum çoğu zaman doğru şekilde davranır ve yalnızca zaman zaman başarısız olur.

Doğru bulsanız bile, kodunuz üzerinde çalışacak bir sonraki kişi, ifadeye hata ekleyerek veya mantığınızı yanlış anlayarak başka bir yere (LarsH'nin doğru bir şekilde işaret ettiği gibi) hata ekleyemez.

Hep birleştirmek ifadeleri parantez kullanmak andve or(benzer öncelik konularla aritmetik işlemler için ve ayrıca).

Daha az olmadığını önemli olan sen dili senin kavramak eminiz. Daha önemli olan, seni takip eden n00b'nin dilini kavramak.

Kodunuzu mümkün olan en açık şekilde yazın. Ekstra parantez sık sık (ancak her zaman değil) yardımcı olur. Bir satıra yalnızca bir ifade koymak genellikle yardımcı olur. Kodlama stilindeki tutarlılık çoğu zaman yardımcı olur.

Çok fazla parantez gibi bir şey var, ancak tavsiyeye ihtiyaç duymayacağınız durumlardan biri - gördüğünüzde bileceksiniz. Bu noktada, parantezi kaldırmak yerine ifadenin karmaşıklığını azaltmak için kodunuzu yeniden ayarlayın.

Evet

Her zaman parantez kullanmalısınız ... öncelik sırasını kontrol etmezsiniz ... derleyicinin geliştiricisi yapar. İşte parantez kullanmama konusunda başıma gelen bir hikaye. Bu iki hafta boyunca yüzlerce kişiyi etkiledi.

Gerçek Dünya Nedeni

Ana çerçeve uygulamasından miras kaldım. Bir gün, berrak mavi olanın dışında çalışmayı bıraktı. İşte bu ... sadece durdu.

Benim işim mümkün olduğunca çabuk çalışmasını sağlamaktı. Kaynak kodu iki yıl boyunca değiştirilmedi, ancak aniden durdu. Kodu derlemeye çalıştım ve XX. Satırda kırdı. XX no'lu çizgiye baktım ve XX no'lu çizginin kırılmasının ne olacağını söyleyemedim. Bu uygulama için ayrıntılı özellikleri istedim ve hiçbiri yoktu. XX hattı suçlu değildi.

Kodu yazdırdım ve en baştan aşağı incelemeye başladım. Neler olduğuna dair bir akış şeması oluşturmaya başladım. Kod o kadar karmaşıktı ki, neredeyse hiç anlamamıştım. Akış şeması yapmaya çalışmaktan vazgeçtim. Bu değişimin sürecin geri kalanını nasıl etkileyeceğini bilmeden değişiklikler yapmaktan korktum, özellikle uygulamanın ne yaptığı ya da bağımlılık zincirinde nerede olduğu konusunda hiçbir ayrıntıya sahip olmadığımdan.

Bu yüzden, kaynak kodunun başından başlamaya ve kodu daha okunaklı hale getirmek için boşluk ve el freni eklemeye karar verdim. Bazı durumlarda, vardı, fark ettiyseniz kombine koşullar ANDve ORve veri olmanın ne arasına açıkça ayırt değildi ANDed ve hangi verilerin ediliyordu ORed. Ben de onları daha okunaklı hale getirmek için parantez ANDve ORkoşulları koymaya başladım .

Yavaş yavaş temizlerken aşağıya doğru ilerlediğimde periyodik olarak işimi kurtaracağım. Bir noktada kodu derlemeye çalıştım ve garip bir şey oldu. Hata atlandı orijinal kod satırını geçti ve şimdi daha da aşağıdaydı. Böylece ben ANDve ORkoşulları parens ile ayrıştırmaya devam ettim . Temizlemeyi bitirdiğimde işe yaradı. Şekil git.

Daha sonra operasyon mağazasını ziyaret etmeye karar verdim ve ana kareye yakın zamanda yeni bir bileşen takıp takmadıklarını sordum. Evet dediler, yakın zamanda derleyiciyi yükselttik. Hmmmm.

Eski derleyicinin ifadesini soldan sağa ne olursa olsun değerlendirdiği ortaya çıktı. Derleyici yeni versiyonu da belirsiz kombinasyonu anlamına sağ ama belirsiz koda soldan ifadeleri değerlendirilerek ANDve ORçözülemedi.

Bundan öğrendiğim ders ... HER ZAMAN, HER ZAMAN, HER ZAMAN, birbirleriyle bağlantılı olarak kullanıldığında her zaman ayrı ANDkoşulları ve ORkoşulları kullanmak için parenler kullanırlar .

Basitleştirilmiş Örnek

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(bunlardan bir kaçı ile kodlanmış kod)

Bu, karşılaştığımın basitleştirilmiş bir versiyonudur. Bileşik boole mantığı ifadeleriyle başka koşullar da vardı.

Şununla kovaladığımı hatırlıyorum:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

Bunu yazamadım çünkü hiç bir şey yoktu. Orijinal yazar çoktan gitmişti. Yoğun baskıyı hatırlıyorum. Bütün bir kargo gemisi limanda mahsur kaldı ve bu küçük program çalışmadığı için yüklenemedi. Uyarı yok. Kaynak kodunda değişiklik yok. Ağ Operasyonlarına sormak bana sadece paren eklemenin hataları değiştirdiğini fark ettikten sonra bir şeyleri değiştirip değiştirmediklerini sormaya başladı.

Evet, eğer 've' ve 'veya' karışıksa.

Ayrıca iyi fikir () mantıklı bir çek nedir.

En iyisi, iyi adlandırılmış yüklem işlevlerini kullanmak ve buradaki çoğu kontrol ve koşulu çıkarmak, basit ve okunabilir durumda bırakmaktır.

Parantezler anlamsal olarak gereksiz, bu nedenle derleyici umursamıyor, ama bu kırmızı bir ringa balığı - asıl mesele programcının okunabilirliği ve anlaşılması.

Buradaki radikal pozisyonu alıp parantez içindeki doyurucu bir "hayır" vereceğim a AND b OR c AND d. Her programcı Boole ifadelerde öncelik gider ezbere bilmeli DEĞİL> VE> VEYA sadece hatırlama gibi, My Dear Teyze Sally dilerim lütfen cebirsel ifadeler için. Gereksiz noktalama, çoğu zaman kodlayıcıda, programcının okunabilirliğinde hiçbir faydası olmadan, görsel karışıklık ekler.

Ayrıca, her zaman mantıksal ve cebirsel ifadelerde parantez kullanıyorsanız, bunları "zor bir şey oluyor - dikkat edin!" İçin bir işaretleyici olarak kullanma yeteneğinden vazgeçersiniz. Diğer bir deyişle, varsayılan önceliği geçersiz kılmak istediğinizde ve çarpmadan önce veya VE'den önce VEYA'dan önce ek olarak değerlendirilen eklerde parantezler bir sonraki programcı için hoş bir kırmızı bayraktır. İhtiyaç duymadıklarında onları çok fazla kullanırsanız, sen de Ağlayan Oğlan olursun.

Böyle C, ibre ifadeler olarak cebir (Boole veya değil), alanının dışında herhangi bir şey için bir istisna yapmak nerede standart gibi deyimler daha karmaşık şey *p++veya p = p->nextmuhtemelen dereferencing ve aritmetik düz tutmak için parantez içinde olmalı. Ve elbette, bunların hiçbiri, ifadeler için bir tür Lehçe gösterim kullanan Lisp, Forth veya Smalltalk gibi diller için geçerli değildir; ancak genel dillerin çoğunluğu için, mantıksal ve aritmetik öncelik tamamen standart hale getirilmiştir.

Gördüğüm kadarıyla:

EVET Artıları:

• İşlem sırası açık.
• Sizi işlem sırasını anlamayan gelecekteki geliştiricilerden korur.

EVET Eksileri:

• Dağınıklığa neden olabilir, kodu okumak zor olabilir

NO Artıları:

• ?

NO Eksileri:

• İşlem sırası gizlidir
• Kod, işlem sırası iyi bir şekilde anlaşılmadan geliştiriciler için daha az bakım gerektirebilir.

Yabancı parantezlerin dahil edilmesinde veya dışında herhangi bir argüman var mı? Pratik tecrübe onları okunabilirlik için dahil etmeye değer olduğunu gösteriyor mu? Yoksa bir geliştiricinin gerçekten oturması ve dillerinin temeline güvenmesi gerektiğinin bir işareti mi?

Eğer hiç kimse bir daha koduma bakmak zorunda kalmazsa, umurumda olacağını sanmıyorum.

Ancak deneyimlerime göre:

• Koduma tekrar tekrar bakıyorum (bazen yazdıktan yıllar sonra)
• Diğerleri bazen koduma bakar
  • Ya da genişletmek / düzeltmek zorundasınız!
• Ne kendim ne de diğeri tam olarak yazarken ne düşündüğümü hatırlıyor
• Kriptik yazma "karakter sayımı minize" kodunun okunması zarar veriyor

Neredeyse her zaman bunu yapıyorum çünkü çabucak okuma yeteneğime güveniyorum ve küçük hatalar yapmayı diğerlerinden çok daha fazla.

Senin durumunda, neredeyse kesin olarak şöyle bir şey yapardım:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Evet, daha fazla kod. Evet, süslü bool operatörleri yerine yapabilirim. Hayır, gelecekte 1 + yıl kodları gözden geçirme şansını beğenmedim, süslü bool operatörlerini yanlış anladım. Ya farklı AND / VEYA önceliği olan ve bunu düzeltmek için geri atlamak zorunda kalmış bir dilde kod yazıyorsam? Gidecek miyim, "aha! Yaptığım bu zekice küçük şeyi hatırlıyorum! Bunu geçen yıl yazarken parens'i dahil etmek zorunda değildim, şimdi hatırladığım iyi bir şey!" Eğer bu gerçekleşirse (veya daha kötüsü, bu zekanın farkında olmayan veya "en kısa zamanda düzelt" tipi bir duruma atılan başka biri)?

() İle ayırmak, daha sonra hızlı bir şekilde kayma ve anlama konusunda çok daha kolay ...

Genel dava

C # 'da çarpma ve bölme toplama ve çıkarma işlemine göre önceliklidir.

Yine de, kod üssü genelinde ortak bir stil uygulayan ve yeterince net olmayan kodla ortaya çıkan hata riskini azaltmak için ek bir amaç olan StyleCop, SA1407 kuralına sahiptir . Bu kural şöyle bir kod parçasına sahip bir uyarı üretecektir:

var a = 1 + 2 * 3;

Sonucun açık 7ve açık olduğu açıktır 9, ancak yine de, StyleCop parantez koymayı önerir:

var a = 1 + (2 * 3);

Senin özel durum

Özel bir durumda, kullandığınız belirli dilde VEYA ile karşılaştırıldığında VE'in önceliği vardır.

Her dilin davranışı böyle değil. Birçoğu, VE ve VEYA'ya eşit davranır.

Çoğunlukla C # ile çalışan bir geliştirici olarak, sorunuzu ilk kez gördüğümde ve daha önce yazdıklarınızı okumadan kod parçasını okuduğumda, ilk cazibem, iki ifadenin aynı olmadığını yorumlamaktı. Umarım, yorum yapmadan önce tüm soruyu tamamen okudum.

Bu özellik ve bazı geliştiricilerin AND ve OR'nin aynı önceliğe sahip olduğuna inanmaları riski, parantez eklemeyi daha da önemli kılmaktadır.

Akıllı olduğunuzu göstermek için kod yazmayın. Dilin her yönüne aşina olmayan kişiler de dahil olmak üzere okunabilirlik hedefiyle kod yazın.

Herkesin dediği gibi, ifadeyi daha okunaklı hale getiren her seferinde parantez kullanın. Ancak ifade karmaşıksa , alt ifadeler için yeni işlevler eklemenizi öneririm .

Yoksa bir geliştiricinin gerçekten oturması ve dillerinin temeline güvenmesi gerektiğinin bir işareti mi?

Eğer dili kesinlikle tekil olarak kullanıyorsanız, belki. Şimdi , eskiden en modernine, derlenmiş yazıdan SQL'e, geçen ay icat ettiğin kendi DSL'inize kadar bildiğiniz tüm dilleri alın .

Bakmadan, bu dillerin her biri için kesin öncelik kurallarını hatırlıyor musunuz?

"Gerekmiyorsa bile parantezleri mantıksal ifadelerde kullanmalı mıyım?"

Evet, çünkü iki kişi onlara yardımcı olacak:

• Bir sonraki programcı, bilgisi, yeterliliği veya tarzı farklı olabilir

• Bu koda geri dönen, daha sonraki bir tarihte!

Kompleks şartlandırmalar "boolean cebiri" dir, bazı şekillerde tam olarak cebir gibi görünmesini sağlayan ve kesinlikle cebir için parens kullanırsınız , yazıyorsunuz, değil mi?

Gerçekten yararlı olan kurallar olumsuzlama kuralları:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Veya biraz daha net bir biçimde:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

hangi gerçekten açıkça sadece cebir olduğu gibi yazılır:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

Ancak, cebirsel basitleştirme ve genişleme düşüncesini de uygulayabiliriz:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

kodda yazmanız gerekse de:

(A||C) && (B||C) && (A||D) && (B||D)

veya biraz daha net bir biçimde:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Temel olarak, bir koşullu hala sadece bir cebirsel ifadedir ve açıkça parantez kullanarak, "bu formülü basitleştirmek veya genişletmek" kavramını da dahil olmak üzere, ifadeye zaten bildiğiniz çeşitli cebirsel kuralları daha kolay uygulayabilirsiniz.

İsteğe bağlı olsa bile parantez kullanacağım, neden kodu daha iyi anlamaya yardımcı olacağı için, o kodu görmeye hazır olanlar için de. Sizin durumunuzda, boolean operatörleri bile ilk başta işe yarayabilir, ama her durumda size yardımcı olacağını söyleyemeyiz. bu yüzden kullanıcının parantezini, gerektirebileceği herhangi bir koşulda veya isteğe bağlı olarak tercih ederim.

Evet. Her durumda, kodunuzun daha net olacağını düşündüğünüzde kullanmalısınız. Kodunuzun yeterince açık olması gerektiğini unutmayın; böylece diğerleri kod içindeki yorumlarınızı okumadan anlayabilir. Bu yüzden parantez ve kaşlı ayraç kullanmak iyi bir uygulamadır. Ayrıca, şirketinizin / ekibinizin özel uygulamasına bağlı olabileceğini unutmayın. Sadece bir yaklaşımı sürdürün ve karıştırmayın.