“Eğer (0 == değer)…” iyiden daha fazla zarar vermez mi? [kapalı]

Bu, başka birinin kodunda gördüğümde en çok nefret ettiğim şeylerden biri. Bunun ne anlama geldiğini ve neden bazılarının bu şekilde yaptığını biliyorum ("yanlışlıkla '=' yerine ne koyarsam?"). Benim için bir çocuk merdivenlerden inerken, merdivenleri yüksek sesle sayarken olduğu gibi.

Her neyse, işte benim karşı olan argümanlarım:

• Program kodunu okumanın doğal akışını bozar. Biz insanlar, "eğer sıfır ise" diyoruz ve "sıfır ise" diyoruz.
• Modern derleyiciler, durumunuzda bir göreviniz olduğunda veya durumunuz sadece evet, yine de şüpheli görünen görevden oluştuğunda sizi uyarır.
• Bir programcıysanız değerleri karşılaştırırken double = '=' koymayı unutmamalısınız. "!" Yazmayı da unutabilirsiniz. Eşitsizliği test ederken.

Ah, evet, "Yoda conditionals" ("Eğer sıfır ise, bu kodu çalıştırmanız gerekir!"). Tüysüz (1) gibi aletlerde "daha iyi" olduğunu iddia eden herkesi her zaman işaret ederim. Bu özel sorun 70'lerin sonlarından beri çözüldü. Çoğu modern dil, if(x = 10)bir boole atamasının sonucunu zorlamayı reddettiği için gibi bir ifadeyi bile derlemeyecektir .

Diğerlerinin dediği gibi, kesinlikle bir sorun değil, ancak bilişsel uyumsuzluğu biraz tetikliyor.

İğrenç çünkü küçük ama göze çarpan bir zihinsel vergi uygular.

İnsanlar neredeyse tüm programlama dillerinde (ve çoğu doğal dilde) soldan sağa okurlar.

Ben görürsem 123 == x, ben zihinsel ayrıştırmak yoludur:

• 123- ne olmuş yani? eksik bilgi
• == - 123, 123, neden test ettin?
• x- Tamam, işte endişelendiğimiz şey bu. Sadece şimdi içeriğim var.
• Yeniden düşünmeye geri dönün 123ve x'in neden bununla karşılaştırıldığını öğrenin .

x == 123Zihinsel ayrıştırmayı gördüğümde :

• x- Bağlam sağlar, durumun ne hakkında olduğunu biliyorum. Gerisini görmezden gelmeyi seçebilirim. Önceki akıştan yola çıkarak neden ve neyin geleceği konusunda iyi bir fikrim var (ve eğer farklıysa şaşırın).
• == - Ben de öyle düşünmüştüm.
• 123 - Evet.

Kesinti küçüktür (basit bir örnekte), ancak her zaman bunu fark ettim.

Önce değeri koymak , örneğin dikkat çekmek istiyorsanız iyi bir fikir olabilir if (LAUNCH_NUKES == cmd). Normalde amaç bu değildir.

Zararlı? Hayır. Her iki şekilde de çalışır.

Kötü Alıştırma? Borçlu, en iyi ihtimalle. Basit savunma programlaması.

Uykuya dalmaya değer mi? Hayır.

Bu temelde flaimbait.

Hayır, iyiden daha fazla zarar vermez. Basit.

Daha fazla kelime?

Derleyici argümanı? Şey, belki de - seni kendinden kurtarmak için derleyiciye çok fazla güvenme.

İyi - "Sen unutmamak gerekir" duh yapamıyor, hiçbir tabii ki bu arada ben yorgun, ben iki farklı dil kullanmak zorunda kaldı ve bazen, sadece bazen onca gün kodlama oldum ediyorum olmamalı insanı - bir hata.

Bu tür davranışların amacı, savunuculuğu, orada olmamasıdır, çünkü sigorta yaptırmaktan daha fazla hata yapmayı beklemiyorsunuzdur, çünkü kaza yapmayı umuyorsunuz ... ama kapsanmayı seversiniz.

Okunması zor? İyi bir programcının (= her türlü kötü varsayımı yapan) kablolu == kabloya sahip olması gerektiğinden ama aynı şekilde kendi kendine iyi bir programcının 0 == değerini okuyamadığından şikayet ediyorsunuz.

Zarar vermez, potansiyel faydaları vardır, saçma bir soru, başkalarının isterlerse ve devam etmeleri durumunda bunu yapmalarına izin verin.

Zarar vermezdim ama iğrenç. Yani hayır, öyle demezdim.

Bütün olarak 'ne bir = unutursam?' Diye düşünmedim. Gerçekten çok fazla ağırlık tuttum. Evet, bir yazım hatası yapabilir, ancak hepimiz yazım hatası yaparız, kodlama stilinizi değiştirmek aptalca görünür çünkü bir hata yapmaktan korkarsınız. Neden tüm değişkenlerinizi ve işlevlerinizi küçük harflerle noktalamadan küçük harf yapmazsınız, çünkü bir gün büyük harfle yazmayı ya da altını unutmayı unutabilirsiniz.

Bazı insanlar bir şartlı şeyin tam olarak ne yaptığını netleştirmek için kullanır. Örneğin:

1. Yol:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Yol 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Bazı insanlar ikinci örneğin daha özlü olduğunu ya da argümanların tersine çevrildiğini, testin kendisinden önceki bir testin (koşullu) noktasını gösterdiğini düşünüyor.

Aslında, iki şekilde de umursamıyorum. Stil hakkında evcil hayvanlarım var ve en büyüğü tutarsızlık. Yani, aynı şekilde yapın, sürekli olarak ve kodunuzu okumayı umursamıyorum.

Kendine özgü tarzı olan altı farklı insanın aynı anda üzerinde çalıştığı noktaya kadar karıştırın, biraz sinirleniyorum.

Bana göre basit bir şartlandırma. (90'lı yıllarda) C ve C ++ 'ı öğrenen biri olarak, buna alıştığım ve nedenleri derse alınmış olmasına rağmen kullanmaya başladım.

Bir kez "sabit" için sol tarafa bakmak için "şartlandırılmış" olduğunuzda, bu ikinci doğa olur.

Aynı zamanda sadece eşdeğerlik (veya olumsuzlanmış eşdeğerlik) için kullanıyorum, daha büyük / daha az değil.

Wonko'nun cevabı w / @ tamamen katılıyorum.

Yararlı bulduğum durumlardan biri if 'nin değişken kısmının oldukça uzun olduğu ve değerleri görmenin kodu okumayı kolaylaştırmasıdır. Noktalı ad alanı dilleri bunun en iyi örneklerine sahiptir.

Örneğin, tek oturum açma ile çalıştığım bir şey, belirli bir tür hata oluştuysa ve belirli bir yolla düzeltildiyse, iki eşzamanlı oturuma sahip olabileceğiniz bir durum vardı; böyle bir şey:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Kuşkusuz bu örnekte, bunu yapmanın başka yolları da var, ancak bu ilk sayı sürümünün potansiyel olarak daha okunaklı olduğu bir durum olacaktır.

Ve yine de hatalar meydana gelir. Ve bazen bir döngü operatöründe, eşitliği başka şekilde kontrol edebileceğiniz bir görev yapmak istersiniz ya da en azından kullanmak standart bir uygulamadır.

Biraz tuttum. Takip ettiğim tavsiyeler (büyük olasılıkla Kod Tamamlandı) karşılaştırmalarda solda daha düşük değerin ne olması gerektiğini korumaktır. Bunu daha önce bir meslektaşımla tartışıyordum ve biraz çılgınca olduğunu düşünüyordu ama buna çok alıştım.

Yani şunu söyleyebilirim:

if ( 0 <= value )

Ancak şunu da söyleyebilirim:

if ( value <= 100 )

Eşitlik soldaki değişkenle kontrol etme eğiliminde olacağım, sadece daha okunaklı.