Boole'lar yöntem argümanları olarak kabul edilemez mi? [kapalı]

Bir meslektaşım, booleanların yöntem argümanları olarak kabul edilemez olduğunu belirtiyor . Numaralandırmalar ile değiştirilecektir. İlk başta bir fayda görmedim ama bana bir örnek verdi.

Anlaşılması daha kolay olan nedir?

file.writeData( data, true );

Veya

enum WriteMode {
  Append,
  Overwrite
};

file.writeData( data, Append );

Şimdi anladım! ;-)
Bu kesinlikle ikinci parametre olarak bir numaralandırmanın kodu daha okunaklı hale getirdiği bir örnektir.

Peki bu konudaki fikriniz nedir?

Boolean, "evet / hayır" seçeneklerini temsil eder. Bir "evet / hayır" ı temsil etmek istiyorsanız, o zaman bir boole kullanın, kendini açıklayıcı olmalıdır.

Ancak, ikisi de açıkça evet veya hayır olmayan iki seçenek arasında bir seçim ise, o zaman bir sıralama bazen daha okunaklı olabilir.

Numaralandırmalar ayrıca, şimdi üçüncü bir seçenek (veya daha fazlasını) istediğinizde gelecekteki değişikliklere izin verir.

Sorununuza en iyi model olanı kullanın. Verdiğiniz örnekte, sıralama daha iyi bir seçimdir. Bununla birlikte, bir boole'nin daha iyi olduğu başka zamanlar da olabilir. Hangisi size daha mantıklı geliyor:

lock.setIsLocked(True);

veya

enum LockState { Locked, Unlocked };
lock.setLockState(Locked);

Bu durumda, oldukça açık ve net olduğunu düşündüğüm için boole seçeneğini seçebilirim ve kilidimin ikiden fazla duruma sahip olmayacağından oldukça eminim. Yine de ikinci seçenek geçerli, ancak gereksiz yere karmaşık, IMHO.

Bana göre, ne boole ne de sayım kullanmak iyi bir yaklaşımdır. Robert C. Martin bunu Temiz Kod İpucu # 12: Boolean Argümanlarını Ortadan Kaldır'da çok net bir şekilde ifade ediyor :

Boolean argümanları, işlevin birden fazla şey yaptığını yüksek sesle bildirir. Kafa karıştırıcıdırlar ve ortadan kaldırılmaları gerekir.

Bir yöntem birden fazla şey yaparsa, iki farklı yöntem yazmayı tercih etmelisiniz, örneğin sizin durumunuzda: file.append(data)ve file.overwrite(data).

Bir numaralandırma kullanmak işleri daha net hale getirmez. Hiçbir şeyi değiştirmez, hala bir bayrak tartışmasıdır.

Sanırım bunu neredeyse kendin yanıtladın, bence son amaç kodu daha okunaklı hale getirmek ve bu durumda enum bunu yaptı, IMO her zaman genel kurallardan ziyade nihai amaca bakmak en iyisidir, belki biraz daha düşün bir kılavuz olarak, yani numaralandırmalar genellikle kodda genel bools, ints vb. şeylerden daha okunabilirdir, ancak kuralın her zaman istisnaları olacaktır.

Adlai Stevenson'ın Küba füze krizi sırasında BM Büyükelçisi Zorin'e sorduğu soruyu hatırlıyor musunuz?

"Şu anda dünya görüşü mahkemesindesiniz ve evet ya da hayır olarak yanıtlayabilirsiniz . [Füzelerin] var olduğunu reddettiniz ve sizi doğru anladığımı bilmek istiyorum .... Beklemeye hazırım Cevabım için cehennem donana kadar, eğer kararın buysa. "

Yönteminizde sahip olduğunuz bayrak, onu ikili bir karara bağlayabileceğiniz bir yapıya sahipse ve bu karar asla üç yönlü veya n yönlü bir karara dönüşmeyecekse, boole'ye gidin. Göstergeler: bayrağınıza isXXX denir .

Mod anahtarı olan bir şey olması durumunda bunu boole yapmayın . Yöntemi yazarken her zaman düşündüğünüzden daha fazla mod vardır .

Bir-daha-mod ikilemi, örneğin bir dosya veya dizinin olası izin modlarının bugün dosya türü, sahiplik vb.

Bunun kötü bir şey olduğunu düşünmemin iki nedeni var:

1. Çünkü bazı insanlar şöyle yöntemler yazacak:

   ProcessBatch(true, false, false, true, false, false, true);
   

   Bu açıkça kötü çünkü parametreleri karıştırmak çok kolay ve ne belirttiğinize bakarak hiçbir fikriniz yok. Yine de sadece bir bool fena değil.

2. Çünkü program akışını basit bir evet / hayır dalıyla kontrol etmek, garip bir şekilde bir araya getirilmiş tamamen farklı iki işleve sahip olduğunuz anlamına gelebilir. Örneğin:

   public void Write(bool toOptical);
   

   Gerçekten, bu iki yöntem olmalı

   public void WriteOptical();
   public void WriteMagnetic();
   

   çünkü bunlardaki kod tamamen farklı olabilir; her türlü farklı hata işleme ve doğrulama yapmaları gerekebilir veya hatta giden verileri farklı şekilde biçimlendirmeleri gerekebilir. Bunu sadece kullanarak Write()veya hatta kullanarak söyleyemezsiniz Write(Enum.Optical)(tabii ki bu yöntemlerden herhangi birine sahip olabilirsiniz, isterseniz sadece iç yöntemleri WriteOptical / Mag çağırabilirsiniz).

Sanırım duruma göre değişir. 1 numara dışında bu konuda çok büyük bir anlaşma yapmam.

Numaralandırmalar daha iyidir, ancak ben mantıksal paramlara "kabul edilemez" demezdim. Bazen küçük bir boole atıp devam etmek daha kolaydır (özel yöntemleri düşünün vb.)

Booleanlar, Python ve Objective-C gibi adlandırılmış parametrelere sahip dillerde uygun olabilir, çünkü ad, parametrenin ne yaptığını açıklayabilir:

file.writeData(data, overwrite=true)

veya:

[file writeData:data overwrite:YES]

Bunun iyi bir kural olduğuna katılmıyorum . Açıkçası, Enum bazı durumlarda daha iyi açık veya ayrıntılı bir kod yapar, ancak bir kural olarak ulaşmanın çok ötesinde görünür.

Öncelikle örneğinizi ele alayım: Programcıların sorumluluğu (ve iyi kod yazma yeteneği) bir Boole parametresine sahip olarak gerçekten tehlikeye atılmaz. Örneğinizde, programcı aşağıdakileri yazarak ayrıntılı kod yazabilirdi:

dim append as boolean = true
file.writeData( data, append );

ya da daha genel tercih ederim

dim shouldAppend as boolean = true
file.writeData( data, shouldAppend );

İkincisi: Verdiğiniz Enum örneği yalnızca "daha iyi" çünkü bir CONST'u geçiyorsunuz. Büyük olasılıkla çoğu uygulamada, fonksiyonlara aktarılan zaman parametrelerinin çoğu değilse de en azından bazıları DEĞİŞKENLER'dir. bu durumda ikinci örneğim (iyi isimlere sahip değişkenler vermek) çok daha iyidir ve Enum size çok az fayda sağlardı.

Numaralandırmaların kesin bir yararı vardır, ancak tüm boole'lerinizi numaralandırmalarla değiştirmemelisiniz. Doğru / yanlışın gerçekte neler olup bittiğini temsil etmenin en iyi yolu olduğu birçok yer vardır.

Bununla birlikte, onları yöntem argümanları olarak kullanmak biraz şüphelidir, çünkü doğru / yanlışın gerçekte ne anlama geldiğini görmenize izin verdiklerinden, yapmaları gereken şeyleri araştırmadan göremezsiniz.

Özellikler (özellikle C # 3 nesne başlatıcıları ile) veya anahtar kelime argümanları (a la ruby ​​veya python), aksi takdirde bir boole argümanı kullanacağınız yere gitmenin çok daha iyi bir yoludur.

C # örneği:

var worker = new BackgroundWorker { WorkerReportsProgress = true };

Ruby örneği

validates_presence_of :name, :allow_nil => true

Python örneği

connect_to_database( persistent=true )

Bir boole yöntemi argümanının yapılması gereken doğru şeyin nerede olduğunu düşünebildiğim tek şey, özelliklere veya anahtar kelime argümanlarına sahip olmadığınız java'da. Java'dan nefret etmemin nedenlerinden biri bu :-(

Çoğu durumda numaralandırmaların boolean'lardan daha okunabilir ve genişletilebilir olduğu doğru olsa da, "booleanların kabul edilemez" şeklindeki mutlak bir kural saçmadır. Esnek değildir ve verimsizdir - insan yargısına yer bırakmaz. Çoğu dilde temel bir yerleşik türdür çünkü yararlıdırlar - diğer yerleşik türlere uygulamayı düşünün: örneğin "parametre olarak asla int kullanma" demek çılgınlık olur.

Bu kural, hatalar veya çalışma zamanı performansı potansiyeli değil, sadece bir stil sorunudur. Daha iyi bir kural, "okunabilirlik nedeniyle numaralandırmaları boolelere tercih et" olacaktır.

.Net çerçevesine bakın. Booleanlar, epeyce yöntemde parametre olarak kullanılır. .Net API mükemmel değil, ancak boolean'ın parametre olarak kullanılmasının büyük bir sorun olduğunu düşünmüyorum. Araç ipucu her zaman size parametrenin adını verir ve bu tür bir rehberlik de oluşturabilirsiniz - yöntem parametreleriyle ilgili XML yorumlarınızı doldurun, bunlar araç ipucunda görünecektir.

Ayrıca, booleanları bir numaralandırma için açıkça yeniden düzenlemeniz gereken bir durum olduğunu da eklemeliyim - sınıfınızda veya yöntem parametrelerinizde iki veya daha fazla boole varsa ve tüm durumlar geçerli değilse (örneğin, bunlara sahip olmak geçerli değildir) her ikisi de doğru ayarlanmış).

Örneğin, sınıfınız aşağıdaki gibi özelliklere sahipse

public bool IsFoo
public bool IsBar

Ve her ikisinin de aynı anda doğru olması bir hata, aslında sahip olduğunuz şey üç geçerli durum, daha iyi bir şekilde şöyle ifade edilir:

enum FooBarType { IsFoo, IsBar, IsNeither };

Meslektaşınızın daha iyi bağlı kalabileceği bazı kurallar şunlardır:

• Tasarımınızla dogmatik olmayın.
• Kodunuzun kullanıcıları için en uygun olanı seçin.
• Bu ayki şekli beğendiğiniz için yıldız şeklindeki mandalları her deliğe sokmaya çalışmayın!

Bir Boole, yalnızca çerçevenin işlevselliğini genişletmek istemiyorsanız kabul edilebilir. Enum tercih edilir çünkü numaralandırmayı genişletebilir ve işlev çağrısının önceki uygulamalarını kesemezsiniz.

Enum'un diğer avantajı, okunmasının daha kolay olmasıdır.

Yöntem aşağıdaki gibi bir soru sorarsa:

KeepWritingData (DataAvailable());

nerede

bool DataAvailable()
{
    return true; //data is ALWAYS available!
}

void KeepWritingData (bool keepGoing)
{
   if (keepGoing)
   {
       ...
   }
}

Boole yöntemi argümanları tamamen mantıklı görünüyor.

Yönteme bağlıdır. Eğer yöntem, açıkça doğru / yanlış olan bir şey yaparsa, o zaman iyidir, örneğin aşağıda [bunun bu yöntem için en iyi tasarım olduğunu söylemiyorum, bu sadece kullanımın açık olduğu bir örnek].

CommentService.SetApprovalStatus(commentId, false);

Ancak, bahsettiğiniz örnek gibi çoğu durumda, bir numaralandırma kullanmak daha iyidir. .NET Framework'ün kendisinde bu kurala uyulmayan birçok örnek vardır, ancak bunun nedeni bu tasarım kılavuzunu döngüde oldukça geç tanıtmış olmalarıdır.

İşleri biraz daha açık hale getiriyor, ancak arayüzlerinizin karmaşıklığını büyük ölçüde genişletmeye başlıyor - ekleme / üzerine yazma gibi katıksız bir boole seçiminde aşırıya kaçmış gibi görünüyor. Başka bir seçenek eklemeniz gerekirse (bu durumda düşünemiyorum), her zaman bir refactor (dile bağlı olarak) gerçekleştirebilirsiniz.

Numaralandırmalar kesinlikle kodu daha okunaklı hale getirebilir. Hala dikkat edilmesi gereken birkaç şey var (en azından .net içinde)

Bir numaralamanın temelindeki depolama bir int olduğundan, varsayılan değer sıfır olacaktır, bu nedenle 0'ın mantıklı bir varsayılan olduğundan emin olmalısınız. (Örneğin, yapıların tüm alanları oluşturulduklarında sıfıra ayarlanmıştır, bu nedenle 0 dışında bir varsayılan belirtmenin bir yolu yoktur. 0 değeriniz yoksa, int'e çevrim yapmadan sıralamayı bile test edemezsiniz. kötü stil.)

Numaranız kodunuza özelse (asla halka açık değilse), burada okumayı bırakabilirsiniz.

Senin Çeteleler ise yayınlanan harici koda hiçbir şekilde ve / veya programın dışında kaydedilir bunları açıkça numaralandırma düşünün. Derleyici bunları otomatik olarak 0'dan numaralandırır, ancak numaralandırmalarınızı değer vermeden yeniden düzenlerseniz, hatalarla sonuçlanabilirsiniz.

Yasal olarak yazabilirim

WriteMode illegalButWorks = (WriteMode)1000000;
file.Write( data, illegalButWorks );

Bununla mücadele etmek için, emin olamadığınız bir numaralandırmayı kullanan herhangi bir kodun (örneğin, genel API) numaralandırmanın geçerli olup olmadığını kontrol etmesi gerekir. Bunu şu yolla yaparsın

if (!Enum.IsDefined(typeof(WriteMode), userValue))
    throw new ArgumentException("userValue");

Tek uyarı, Enum.IsDefinedyansımayı kullanması ve daha yavaş olmasıdır. Ayrıca bir sürüm oluşturma sorunu da yaşıyor. Enum değerini sık sık kontrol etmeniz gerekiyorsa, aşağıdakilerden daha iyi olursunuz:

public static bool CheckWriteModeEnumValue(WriteMode writeMode)
{
  switch( writeMode )
  {
    case WriteMode.Append:
    case WriteMode.OverWrite:
      break;
    default:
      Debug.Assert(false, "The WriteMode '" + writeMode + "' is not valid.");
      return false;
  }
  return true;
}

Sürüm oluşturma sorunu, eski kodun yalnızca sahip olduğunuz 2 numaralandırmayı nasıl işleyeceğini bilmesidir. Üçüncü bir değer eklerseniz, Enum.IsDefined doğru olacaktır, ancak eski kod bunu işleyemez. Whoops.

[Flags]Numaralandırmalarla yapabileceğiniz daha da fazla eğlence var ve bunun için doğrulama kodu biraz farklı.

Ayrıca taşınabilirlik için call ToString()on the enum kullanmanız Enum.Parse()gerektiğini ve bunları tekrar okurken kullanmanız gerektiğini de not edeceğim . Her ikisi de ToString()ve numaralandırmaları Enum.Parse()da işleyebilir [Flags], bu yüzden onları kullanmamanız için bir neden yoktur. Unutmayın, bu da başka bir tuzaktır, çünkü şimdi muhtemelen kodu kırmadan numaralamanın adını bile değiştiremezsiniz.

Bu yüzden, bazen kendinize sorduğunuzda yukarıdakilerin hepsini tartmanız gerekir. Sadece bir bool ile kurtulabilir miyim?

IMHO, ikiden fazla seçeneğin mümkün olduğu herhangi bir durum için bir numaralandırma açık bir seçim gibi görünüyor. Ama kesinlikle ihtiyacınız olan tek şeyin boole olduğu durumlar var. Bu durumda, bool'un işe yarayacağı bir enum kullanmanın, 4'ün işe yarayacağı 7 kelimeyi kullanmanın bir örneği olacağını söyleyebilirim.

Booleanlar, yalnızca iki şeyden biri (yani bir ampulün durumu, açık veya kapalı) olabilen açık bir geçişe sahip olduğunuzda anlamlıdır. Bunun dışında, neyi aktardığınızın aşikar olduğu bir şekilde yazmak iyidir - örneğin, disk yazmaları - arabelleğe alınmamış, satır arabelleğe alınmış veya eşzamanlı - bu şekilde geçirilmelidir. Şimdi eşzamanlı yazımlara izin vermek istemeseniz bile (ve bu nedenle iki seçenekle sınırlıysanız), ilk bakışta ne yaptıklarını bilmek amacıyla onları daha ayrıntılı yapmayı düşünmeye değer.

Bununla birlikte, Yanlış ve Doğru (boolean 0 ve 1) de kullanabilirsiniz ve daha sonra daha fazla değere ihtiyacınız olursa, işlevi kullanıcı tanımlı değerleri (örneğin, 2 ve 3) ve eski 0/1 değerlerinizi desteklemek için genişletin. hoş bir şekilde taşınacak, bu yüzden kodunuz kırılmamalıdır.

Bazen aşırı yüklenmelerle farklı davranışları modellemek daha kolaydır. Örneğinizden devam etmek için:

file.appendData( data );  
file.overwriteData( data );

Bu yaklaşım, her biri sabit bir seçenek kümesine izin veren birden çok parametreniz varsa bozulur. Örneğin, bir dosyayı açan bir yöntem, dosya modu (açma / oluşturma), dosya erişimi (okuma / yazma), paylaşım modu (yok / okuma / yazma) için birkaç permütasyona sahip olabilir. Toplam konfigürasyon sayısı, ayrı seçeneklerin Kartezyen ürünlerine eşittir. Doğal olarak bu gibi durumlarda çoklu aşırı yükler uygun değildir.

Numaralandırmalar, bazı durumlarda kodu daha okunaklı hale getirebilir, ancak bazı dillerde (örneğin C #) tam enum değerini doğrulamak zor olabilir.

Çoğunlukla bir boole parametresi, yeni bir aşırı yük olarak parametre listesine eklenir. .NET'teki bir örnek:

Enum.Parse(str);  
Enum.Parse(str, true); // ignore case

İkinci aşırı yükleme, .NET çerçevesinin ilk sürümünden daha sonraki bir sürümünde kullanılabilir hale geldi.

Yalnızca iki seçenek olacağını biliyorsanız, bir boole iyi olabilir. Numaralandırmalar eski kodu bozmayacak bir şekilde genişletilebilir, ancak eski kitaplıklar yeni numaralandırma değerlerini desteklemeyebilir, bu nedenle sürüm oluşturma tamamen göz ardı edilemez.

DÜZENLE

C # 'ın daha yeni sürümlerinde, adlandırılmış argümanlar kullanmak mümkündür, bu da, IMO, çağırma kodunu numaralandırmalarla aynı şekilde daha net hale getirebilir. Yukarıdaki ile aynı örneği kullanarak:

Enum.Parse(str, ignoreCase: true);

Enums'ün 2 seçeneğinizin olduğu yöntemlerde (ve numaralandırma olmadan okunabilirliğe sahip olabileceğiniz sadece iki seçenek) olduğu konusunda hemfikirim.

Örneğin

public void writeData(Stream data, boolean is_overwrite)

Enums'i sevin, ancak boole de kullanışlıdır.

Bu, eski bir gönderiye geç girilmiş bir giriş ve o kadar aşağısında ki kimse onu okumayacak, ama zaten kimse söylemediği için ...

Satır içi bir yorum, beklenmedik boolsorunu çözmek için uzun bir yol kat eder . Orijinal örnek özellikle iğrençtir: Değişkeni fonksiyon netleştirmesinde adlandırmaya çalıştığınızı hayal edin! Gibi bir şey olurdu

void writeData( DataObject data, bool use_append_mode );

Ancak, örnek olması için, bunun beyan olduğunu varsayalım. Ardından, başka türlü açıklanamayan bir boole argümanı için, değişken adını bir satır içi açıklamaya koyarım. Karşılaştırmak

file.writeData( data, true );

ile

file.writeData( data, true /* use_append_mode */);

Bu gerçekten argümanın kesin doğasına bağlıdır. Evet / hayır veya doğru / yanlış değilse, bir sıralama onu daha okunaklı hale getirir. Ancak bir numaralandırma ile bağımsız değişkeni kontrol etmeniz veya kabul edilebilir bir varsayılan davranışa sahip olmanız gerekir, çünkü temeldeki türün tanımsız değerleri aktarılabilir.

Örneğinizde boolean yerine numaralandırmaların kullanılması, yöntem çağrısının daha okunaklı olmasına yardımcı olur. Bununla birlikte, bu, yöntem çağrılarında argümanlar olarak adlandırılan, C #'daki favori istek öğemin yerine geçer. Bu sözdizimi:

var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);

mükemmel bir şekilde okunabilir ve daha sonra bir programcının yapması gerekeni yapabilirsiniz; bu, IDE'de nasıl göründüğüne bakılmaksızın yöntemdeki her parametre için en uygun türü seçmektir.

C # 3.0, yapıcılarda adlandırılmış bağımsız değişkenlere izin verir. Bunu neden yöntemlerle de yapamadıklarını bilmiyorum.

Boolean değerler true/ falsetek. Yani neyi temsil ettiği belli değil. Enumanlamlı bir ad, olabilir mesela OVERWRITE, APPENDvb Yani çeteleler iyidir.