Apakah boolean sebagai argumen metode tidak dapat diterima? [Tutup]


123

Seorang kolega saya menyatakan bahwa boolean sebagai argumen metode tidak dapat diterima . Mereka akan diganti dengan pencacahan. Awalnya saya tidak melihat ada manfaat, tapi dia memberi saya contoh.

Apa yang lebih mudah dimengerti?

file.writeData( data, true );

Atau

enum WriteMode {
  Append,
  Overwrite
};

file.writeData( data, Append );

Sekarang saya paham! ;-)
Ini jelas merupakan contoh di mana enumerasi sebagai parameter kedua membuat kode lebih mudah dibaca.

Jadi, apa pendapat Anda tentang topik ini?


7
Ini adalah bacaan yang sangat menarik, saya akan menerapkan metode ini lebih sering.
Sara Chipps

hrm, ive pernah melakukan ini sebelumnya, tetapi tidak pernah menyadari betapa bagusnya pola desain ini. jadi enum masuk ke file?
Shawn

Enum tentu lebih masuk akal dari pov semantik. Pada catatan lain, akan menarik untuk melihat apa yang telah dibuat oleh beberapa programmer untuk menangani logika fuzzy.
James P.

2
tanyakan saja kepada pria lemon di Adventure Time apakah ini tidak dapat diterima
ajax333221

Jawaban:


131

Boolean mewakili pilihan "ya / tidak". Jika Anda ingin merepresentasikan "ya / tidak", gunakan boolean, yang seharusnya sudah cukup jelas.

Tetapi jika itu adalah pilihan antara dua opsi, tidak ada yang jelas ya atau tidak, maka enum terkadang bisa lebih mudah dibaca.


3
Selain itu, nama metode harus jelas tentang apa yang dilakukan oleh argumen ya atau tidak, yaitu void turnLightOn (bool) secara jelas menyetel true atau yes akan menyalakan lampu.
simon

10
Meskipun dalam kasus ini saya mungkin lebih suka turnLightOn () dan turnLightOff (), tergantung pada situasinya.
Skaffman

14
"turnLightOn (false)" berarti "jangan nyalakan lampu"? Confusiong.
Jay Bazuzi

17
Bagaimana dengan setLightOn(bool).
Finbarr

10
Komentar terlambat, tetapi @Jay Bazuzi: Jika metode Anda disebut turnLightOn, dan Anda memberikan false, Anda mungkin juga tidak memanggil metode tersebut sama sekali, mengirimkan false mengatakan jangan nyalakan lampu. Jika lampunya sudah menyala, bukan berarti dimatikan, itu artinya jangan dinyalakan ... Jika Anda memiliki metode 'turnLight' dan enum dengan 'On' dan 'Off' masuk akal, turnLight ( On), turnLight (Off). Saya setuju dengan skaffman, saya lebih suka dua metode eksplisit yang berbeda, turnLightOn () dan turnLightOff (). (BTW: Hal ini dijelaskan dalam buku Paman Bobs "Kode Bersih")
Phill


32

Gunakan salah satu yang paling sesuai dengan masalah Anda. Dalam contoh yang Anda berikan, enum adalah pilihan yang lebih baik. Namun, ada kalanya boolean lebih baik. Mana yang lebih masuk akal bagi Anda:

lock.setIsLocked(True);

atau

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

Dalam hal ini, saya mungkin memilih opsi boolean karena menurut saya ini cukup jelas dan tidak ambigu, dan saya cukup yakin kunci saya tidak akan memiliki lebih dari dua status. Namun, pilihan kedua masih berlaku, tetapi tidak perlu rumit, IMHO.


2
dalam contoh Anda, saya lebih suka memiliki dua metode. lock.lock () lock.release () dan lock.IsSet, tetapi semuanya tergantung pada apa yang paling masuk akal untuk kode konsumsi.
Robert Paulson

3
Itu adalah komentar yang adil, tetapi saya pikir itu juga menggambarkan poin yang lebih besar bahwa ada banyak cara untuk mencontoh masalah yang diberikan. Anda harus menggunakan model terbaik untuk keadaan Anda, dan Anda juga harus menggunakan alat terbaik yang disediakan lingkungan pemrograman agar sesuai dengan model Anda.
Jeremy Bourque

Saya sangat setuju :), saya baru saja mengomentari penawaran pseudocode tertentu lagi. Saya setuju dengan jawaban anda
Robert Paulson

14

Bagi saya, penggunaan boolean atau enumerasi bukanlah pendekatan yang baik. Robert C. Martin menangkap ini dengan sangat jelas dalam Tip Kode Bersih # 12: Hilangkan Argumen Boolean :

Argumen Boolean dengan lantang menyatakan bahwa fungsi tersebut melakukan lebih dari satu hal. Mereka membingungkan dan harus disingkirkan.

Jika sebuah metode melakukan lebih dari satu hal, Anda sebaiknya menulis dua metode berbeda, misalnya dalam kasus Anda: file.append(data)danfile.overwrite(data) .

Menggunakan enumerasi tidak membuat segalanya lebih jelas. Itu tidak mengubah apa pun, itu masih argumen bendera.


7
Bukankah itu berarti bahwa fungsi yang menerima string ASCII dengan panjang N melakukan 128 ^ N hal?
detly

@delty Apakah ini komentar yang serius? Jika ya, apakah Anda sering membuat kode if pada semua nilai yang mungkin dari sebuah String? Apakah ada kemungkinan perbandingan dengan kasus argumen boolean?
Pascal Thivent

Saya percaya mereka dapat diterima ketika Anda menetapkan nilai boolean di dalam suatu objek. Contoh yang sempurna adalah setVisible(boolean visible) { mVisible = visible; }. Alternatif apa yang Anda sarankan?
Brad

2
@Brad show () {mVisible = true} hide () {mVisible = false}
Oswaldo Acauan

@Oswaldo, meskipun masih benar, menurut saya tidak masuk akal untuk memiliki dua metode berbeda untuk menetapkan boolean ke nilai yang berbeda. Anda tidak memiliki setIntToOne (), setIntToTwo () setIntToThree () kan? Ini sedikit lebih ambigu ketika Anda hanya dapat memiliki dua nilai yang mungkin tetapi demi kebersihan gunakan boolean dalam kasus itu.
Brad

13

Saya pikir Anda hampir menjawab ini sendiri, saya pikir tujuan akhirnya adalah membuat kode lebih mudah dibaca, dan dalam hal ini enum melakukan itu, IMO selalu yang terbaik untuk melihat tujuan akhir daripada aturan selimut, mungkin lebih memikirkannya sebagai pedoman yaitu enum seringkali lebih dapat dibaca dalam kode daripada bools generik, ints dll tetapi akan selalu ada pengecualian untuk aturan tersebut.


13

Ingat pertanyaan yang diajukan Adlai Stevenson kepada duta besar Zorin di PBB selama krisis rudal Kuba ?

"Anda berada di ruang sidang opini dunia sekarang, dan Anda dapat menjawab ya atau tidak . Anda telah menyangkal bahwa [misil] itu ada, dan saya ingin tahu apakah saya telah memahami Anda dengan benar .... Saya siap menunggu untuk jawaban saya sampai neraka membeku, jika itu keputusan Anda. "

Jika flag yang Anda miliki dalam metode Anda bersifat sedemikian rupa sehingga Anda dapat menjepitnya menjadi keputusan biner , dan keputusan itu tidak akan pernah berubah menjadi keputusan tiga arah atau n, gunakan boolean. Indikasi: bendera Anda disebut isXXX .

Jangan membuatnya menjadi boolean jika terjadi sesuatu yang merupakan sakelar mode . Selalu ada satu mode lagi dari yang Anda pikirkan saat menulis metode di tempat pertama.

Dilema satu mode lainnya misalnya menghantui Unix, di mana mode izin yang mungkin dimiliki file atau direktori saat ini menghasilkan makna ganda yang aneh dari mode tergantung pada jenis file, kepemilikan, dll.


13

Ada dua alasan mengapa saya menganggap ini hal yang buruk:

  1. Karena beberapa orang akan menulis metode seperti:

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

    Ini jelas buruk karena terlalu mudah untuk mencampur parameter, dan Anda tidak tahu dengan melihatnya apa yang Anda tentukan. Hanya satu bool tidak terlalu buruk.

  2. Karena mengontrol aliran program dengan cabang ya / tidak sederhana mungkin berarti Anda memiliki dua fungsi yang sama sekali berbeda yang digabungkan menjadi satu dengan cara yang canggung. Misalnya:

    public void Write(bool toOptical);
    

    Sungguh, ini harus menjadi dua metode

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

    karena kode di dalamnya mungkin sama sekali berbeda; mereka mungkin harus melakukan semua jenis penanganan kesalahan dan validasi yang berbeda, atau bahkan mungkin harus memformat data keluar secara berbeda. Anda tidak dapat mengatakannya hanya dengan menggunakan Write()atau bahkan Write(Enum.Optical)(meskipun tentu saja Anda dapat memiliki salah satu dari metode tersebut, cukup panggil metode internal WriteOptical / Mag jika Anda mau).

Saya kira itu tergantung. Saya tidak akan terlalu mempermasalahkannya kecuali untuk # 1.


Poin yang sangat bagus! Dua parameter boolean dalam satu metode memang terlihat buruk (kecuali jika Anda beruntung memiliki parameter bernama, tentunya).
Yarik

Jawaban ini mungkin mendapat manfaat dari beberapa format ulang! ;-)
Yarik

7

Enum lebih baik tetapi saya tidak akan menyebut parameter boolean sebagai "tidak dapat diterima". Terkadang lebih mudah untuk memasukkan satu boolean kecil dan melanjutkan (pikirkan metode pribadi, dll.)


buat saja metodenya sangat deskriptif sehingga jelas apa artinya benar atau ya.
simon

6

Boolean mungkin baik-baik saja dalam bahasa yang memiliki parameter bernama, seperti Python dan Objective-C, karena namanya dapat menjelaskan fungsi parameter:

file.writeData(data, overwrite=true)

atau:

[file writeData:data overwrite:YES]

1
IMHO, writeData () adalah contoh buruk penggunaan parameter boolean, terlepas dari apakah parameter bernama didukung atau tidak. Tidak peduli bagaimana Anda menamai parameternya, arti nilai False tidak jelas!
Yarik

4

Saya tidak setuju bahwa itu adalah aturan yang baik . Jelas, Enum membuat kode eksplisit atau verbose yang lebih baik di beberapa kasus, tetapi sebagai aturan tampaknya jauh melebihi jangkauan.

Pertama izinkan saya mengambil contoh Anda: Tanggung jawab programmer (dan kemampuan) untuk menulis kode yang baik tidak benar-benar terancam dengan memiliki parameter Boolean. Dalam contoh Anda, pemrogram dapat menulis kode verbose dengan menulis:

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

atau saya lebih suka yang lebih umum

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

Kedua: Contoh Enum yang Anda berikan hanya "lebih baik" karena Anda melewati CONST. Kemungkinan besar di sebagian besar aplikasi setidaknya beberapa jika tidak sebagian besar parameter waktu yang diteruskan ke fungsi adalah VARIABEL. dalam hal ini contoh kedua saya (memberikan variabel dengan nama yang bagus) jauh lebih baik dan Enum akan memberi Anda sedikit manfaat.


1
Meskipun saya setuju bahwa parameter boolean dapat diterima dalam banyak kasus, dalam kasus contoh writeData () ini, parameter boolean seperti shouldAppend sangat tidak sesuai. Alasannya sederhana: tidak langsung jelas apa artinya Salah.
Yarik

4

Enum memiliki manfaat yang pasti, tetapi Anda tidak boleh hanya mengganti semua boolean Anda dengan enum. Ada banyak tempat di mana benar / salah sebenarnya adalah cara terbaik untuk merepresentasikan apa yang sedang terjadi.

Namun, menggunakannya sebagai argumen metode agak mencurigakan, hanya karena Anda tidak dapat melihat tanpa menggali hal-hal apa yang seharusnya mereka lakukan, karena mereka membiarkan Anda melihat apa yang benar / salah. sebenarnya berarti

Properti (terutama dengan penginisialisasi objek C # 3) atau argumen kata kunci (a la ruby ​​atau python) adalah cara yang jauh lebih baik untuk pergi ke tempat Anda menggunakan argumen boolean.

C # contoh:

var worker = new BackgroundWorker { WorkerReportsProgress = true };

Contoh Ruby

validates_presence_of :name, :allow_nil => true

Contoh Python

connect_to_database( persistent=true )

Satu-satunya hal yang dapat saya pikirkan di mana argumen metode boolean adalah hal yang benar untuk dilakukan adalah di java, di mana Anda tidak memiliki properti atau argumen kata kunci. Inilah salah satu alasan saya benci java :-(


4

Memang benar bahwa dalam banyak kasus enum lebih dapat dibaca dan lebih dapat diperluas daripada boolean, aturan mutlak bahwa "boolean tidak dapat diterima" adalah konyol. Itu tidak fleksibel dan kontraproduktif - tidak meninggalkan ruang untuk penilaian manusia. Mereka adalah tipe bawaan yang mendasar di sebagian besar bahasa karena berguna - pertimbangkan untuk menerapkannya ke tipe bawaan lainnya: mengatakan misalnya "jangan pernah menggunakan int sebagai parameter" akan gila.

Aturan ini hanyalah masalah gaya, bukan potensi bug atau kinerja waktu proses. Aturan yang lebih baik adalah "lebih memilih enum daripada boolean karena alasan keterbacaan".

Lihatlah kerangka .Net. Boolean digunakan sebagai parameter pada beberapa metode. .Net API tidak sempurna, tetapi menurut saya penggunaan boolean sebagai parameter bukanlah masalah besar. Tooltip selalu memberi Anda nama parameter, dan Anda juga dapat membuat panduan semacam ini - isi komentar XML Anda pada parameter metode, mereka akan muncul di tooltip.

Saya juga harus menambahkan bahwa ada kasus ketika Anda harus merefaktor boolean dengan jelas ke enumerasi - ketika Anda memiliki dua atau lebih boolean di kelas Anda, atau di parameter metode Anda, dan tidak semua status valid (misalnya tidak valid untuk memilikinya keduanya benar).

Misalnya, jika kelas Anda memiliki properti seperti

public bool IsFoo
public bool IsBar

Dan itu adalah kesalahan jika keduanya benar pada saat yang sama, apa yang sebenarnya Anda dapatkan adalah tiga keadaan yang valid, lebih baik dinyatakan sebagai sesuatu seperti:

enum FooBarType { IsFoo, IsBar, IsNeither };

4

Beberapa aturan yang mungkin lebih baik dipatuhi oleh kolega Anda adalah:

  • Jangan dogmatis dengan desain Anda.
  • Pilih apa yang paling sesuai untuk pengguna kode Anda.
  • Jangan mencoba menampar pasak berbentuk bintang ke setiap lubang hanya karena Anda menyukai bentuk bulan ini!

3

Boolean hanya dapat diterima jika Anda tidak bermaksud memperluas fungsionalitas kerangka kerja. Enum lebih disukai karena Anda dapat memperpanjang enum dan tidak merusak implementasi pemanggilan fungsi sebelumnya.

Keuntungan lain dari Enum adalah lebih mudah dibaca.


2

Jika metode menanyakan pertanyaan seperti:

KeepWritingData (DataAvailable());

dimana

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

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

Argumen metode boolean tampaknya sangat masuk akal.


Suatu hari Anda akan perlu menambahkan "terus menulis jika Anda memiliki ruang kosong", dan kemudian Anda akan beralih dari bool ke enum.
Ilya Ryzhenkov

Dan kemudian Anda akan mengalami perubahan yang merusak, atau memiliki kelebihan beban yang usang, atau mungkin sesuatu seperti KeppWritingDataEx :)
Ilya Ryzhenkov

1
@Ilya atau mungkin tidak! Menciptakan situasi yang mungkin di mana tidak ada satupun saat ini tidak meniadakan solusi.
Jesse C. Slicer

1
Jesse benar. Merencanakan perubahan seperti itu konyol. Lakukan apa yang masuk akal. Dalam hal ini, boolean bersifat intuitif dan jelas. c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
Derek Park

@ Derek, dalam hal ini, boolean bahkan tidak diperlukan, karena DataAvailable selalu mengembalikan nilai true :)
Ilya Ryzhenkov

2

Itu tergantung pada metodenya. Jika metode melakukan sesuatu yang sangat jelas benar / salah maka itu baik-baik saja, misalnya di bawah [meskipun saya tidak mengatakan ini adalah desain terbaik untuk metode ini, ini hanya contoh di mana penggunaannya jelas].

CommentService.SetApprovalStatus(commentId, false);

Namun dalam banyak kasus, seperti contoh yang Anda sebutkan, lebih baik menggunakan pencacahan. Ada banyak contoh di .NETFramework itu sendiri di mana konvensi ini tidak diikuti, tetapi itu karena mereka memperkenalkan pedoman desain ini cukup terlambat dalam siklus.


2

Itu memang membuat hal-hal sedikit lebih eksplisit, tetapi mulai memperluas kompleksitas antarmuka Anda secara besar-besaran - dalam pilihan boolean belaka seperti menambahkan / menimpa sepertinya berlebihan. Jika Anda perlu menambahkan opsi lebih lanjut (yang tidak dapat saya pikirkan dalam kasus ini), Anda selalu dapat melakukan refactor (tergantung pada bahasanya)


1
Bagaimana dengan prapenjualan sebagai opsi ketiga yang memungkinkan? ;-))
Yarik

2

Enum tentu bisa membuat kodenya lebih mudah dibaca. Masih ada beberapa hal yang harus diperhatikan (setidaknya dalam .net)

Karena penyimpanan yang mendasari enum adalah int, nilai default-nya adalah nol, jadi Anda harus memastikan bahwa 0 adalah default yang masuk akal. (Misalnya, struct memiliki semua bidang disetel ke nol saat dibuat, jadi tidak ada cara untuk menetapkan default selain 0. Jika Anda tidak memiliki nilai 0, Anda bahkan tidak dapat menguji enum tanpa mentransmisikan ke int, yang akan menjadi gaya buruk.)

Jika enum Anda bersifat pribadi untuk kode Anda (tidak pernah diungkapkan secara publik) maka Anda dapat berhenti membaca di sini.

Jika enum Anda diterbitkan dengan cara apa pun ke kode eksternal dan / atau disimpan di luar program, pertimbangkan untuk menomori mereka secara eksplisit. Kompilator secara otomatis menomori mereka dari 0, tetapi jika Anda mengatur ulang enum Anda tanpa memberinya nilai, Anda dapat berakhir dengan cacat.

Saya bisa menulis secara legal

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

Untuk mengatasi hal ini, kode apa pun yang menggunakan enum yang tidak dapat Anda yakini (mis. API publik) perlu memeriksa apakah enum tersebut valid. Anda melakukan ini melalui

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

Satu-satunya peringatan Enum.IsDefinedadalah bahwa ia menggunakan refleksi dan lebih lambat. Itu juga mengalami masalah versi. Jika Anda perlu sering memeriksa nilai enum, sebaiknya Anda melakukan hal berikut:

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;
}

Masalah pembuatan versi adalah bahwa kode lama mungkin hanya tahu bagaimana menangani 2 enum yang Anda miliki. Jika Anda menambahkan nilai ketiga, Enum.IsDefined akan menjadi true, tetapi kode lama belum tentu dapat menanganinya. Ups.

Ada lebih banyak kesenangan yang bisa Anda lakukan [Flags] enum, dan kode validasinya sedikit berbeda.

Saya juga akan mencatat bahwa untuk portabilitas, Anda harus menggunakan panggilan ToString()pada enum, dan menggunakannya Enum.Parse()saat membacanya kembali. Keduanya ToString()dan Enum.Parse()dapat menangani[Flags] enum, jadi tidak ada alasan untuk tidak menggunakannya. Pikiran Anda, itu adalah kesalahan lain, karena sekarang Anda bahkan tidak dapat mengubah nama enum tanpa mungkin memecahkan kode.

Jadi, terkadang Anda perlu menimbang semua hal di atas ketika Anda bertanya pada diri sendiri Bisakah saya lolos hanya dengan bool?


1

IMHO sepertinya enum akan menjadi pilihan yang jelas untuk situasi apa pun di mana lebih dari dua opsi dimungkinkan. Tapi pasti ADA situasi di mana boolean adalah semua yang Anda butuhkan. Dalam hal ini saya akan mengatakan bahwa menggunakan enum di mana bool akan bekerja akan menjadi contoh penggunaan 7 kata ketika 4 sudah cukup.


0

Boolean masuk akal bila Anda memiliki toggle yang jelas yang hanya bisa menjadi salah satu dari dua hal (yaitu keadaan bola lampu, hidup atau mati). Selain itu, ada baiknya untuk menulisnya sedemikian rupa sehingga jelas apa yang Anda lewati - misalnya penulisan disk - unbuffered, line-buffered, atau synchronous - harus diteruskan seperti itu. Bahkan jika Anda tidak ingin mengizinkan penulisan sinkron sekarang (dan Anda dibatasi pada dua opsi), ada baiknya mempertimbangkan untuk membuatnya lebih bertele-tele untuk tujuan mengetahui apa yang mereka lakukan pada pandangan pertama.

Yang mengatakan, Anda juga dapat menggunakan False dan True (boolean 0 dan 1) dan kemudian jika Anda membutuhkan lebih banyak nilai nanti, perluas fungsi untuk mendukung nilai yang ditentukan pengguna (katakanlah, 2 dan 3), dan nilai 0/1 lama Anda akan porting dengan baik, sehingga kode Anda tidak akan rusak.


0

Terkadang lebih mudah untuk memodelkan perilaku yang berbeda dengan kelebihan beban. Untuk melanjutkan dari contoh Anda adalah:

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

Pendekatan ini menurun jika Anda memiliki beberapa parameter, masing-masing memungkinkan sekumpulan opsi tetap. Misalnya, metode yang membuka file mungkin memiliki beberapa permutasi mode file (buka / buat), akses file (baca / tulis), mode berbagi (tidak ada / baca / tulis). Jumlah total konfigurasi sama dengan produk Cartesian dari masing-masing opsi. Biasanya dalam kasus seperti itu kelebihan beban ganda tidak sesuai.

Enum dapat, dalam beberapa kasus membuat kode lebih mudah dibaca, meskipun memvalidasi nilai enum yang tepat dalam beberapa bahasa (misalnya C #) bisa jadi sulit.

Seringkali parameter boolean ditambahkan ke daftar parameter sebagai beban berlebih baru. Salah satu contoh di .NET adalah:

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

Kelebihan yang terakhir menjadi tersedia di versi yang lebih baru dari kerangka .NET daripada yang pertama.

Jika Anda tahu bahwa hanya akan ada dua pilihan, boolean mungkin baik-baik saja. Enum dapat dikembangkan dengan cara yang tidak akan merusak kode lama, meskipun pustaka lama mungkin tidak mendukung nilai enum baru sehingga pembuatan versi tidak dapat sepenuhnya diabaikan.


EDIT

Dalam versi C # yang lebih baru, dimungkinkan untuk menggunakan argumen bernama yang, IMO, dapat membuat kode panggilan lebih jelas dengan cara yang sama seperti enum. Menggunakan contoh yang sama seperti di atas:

Enum.Parse(str, ignoreCase: true);

0

Di mana saya setuju bahwa Enum adalah cara yang baik untuk digunakan, dalam metode di mana Anda memiliki 2 opsi (dan hanya dua opsi Anda dapat memiliki keterbacaan tanpa enum.)

misalnya

public void writeData(Stream data, boolean is_overwrite)

Suka Enum, tetapi boolean juga berguna.


0

Ini adalah entri terlambat pada posting lama, dan sangat jauh di bawah halaman sehingga tidak ada yang akan membacanya, tetapi karena tidak ada yang mengatakannya ....

Komentar sebaris sangat membantu memecahkan masalah yang tidak terduga bool. Contoh aslinya sangat keji: bayangkan mencoba menamai variabel dalam dekelusi fungsi! Ini akan menjadi seperti itu

void writeData( DataObject data, bool use_append_mode );

Tapi, demi contoh, katakanlah itu deklarasi. Kemudian, untuk argumen boolean yang tidak dapat dijelaskan, saya memasukkan nama variabel dalam komentar sebaris. Membandingkan

file.writeData( data, true );

dengan

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

-1

Itu benar-benar tergantung pada sifat argumen yang tepat. Jika bukan ya / tidak atau benar / salah maka enum membuatnya lebih mudah dibaca. Tetapi dengan enum Anda perlu memeriksa argumen atau memiliki perilaku default yang dapat diterima karena nilai yang tidak ditentukan dari tipe yang mendasari dapat diteruskan.


-1

Penggunaan enum sebagai ganti boolean dalam contoh Anda memang membantu membuat pemanggilan metode lebih mudah dibaca. Namun, ini adalah pengganti item keinginan favorit saya di C #, bernama argumen dalam pemanggilan metode. Sintaks ini:

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

akan mudah dibaca, dan Anda kemudian dapat melakukan apa yang harus dilakukan oleh programmer, yaitu memilih jenis yang paling sesuai untuk setiap parameter dalam metode tanpa memperhatikan tampilannya di IDE.

C # 3.0 memungkinkan argumen bernama dalam konstruktor. Saya tidak tahu mengapa mereka tidak bisa melakukan ini dengan metode juga.


Ide yang menarik. Tetapi apakah Anda dapat menyusun ulang parameter? Abaikan parameter? Bagaimana kompilator mengetahui kelebihan beban yang Anda ikat jika ini opsional? Juga, apakah Anda harus memberi nama semua parameter dalam daftar?
Drew Noakes

-1

Nilai Boolean true/ falsesaja. Jadi tidak jelas apa yang diwakilinya. Enumdapat memiliki nama yang bermakna, misalnya OVERWRITE, APPEND, dll Jadi enum lebih baik.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.