Gunakan string kosong, nol, atau hapus properti kosong di permintaan / respons API


25

Saat mentransfer objek melalui API, seperti dalam format JSON schemaless, apa cara ideal untuk mengembalikan properti string yang tidak ada? Saya tahu bahwa ada berbagai cara untuk melakukan ini seperti dalam contoh di tautan yang tercantum di bawah ini.

Saya yakin saya telah menggunakan null di masa lalu tetapi tidak memiliki alasan yang baik untuk melakukan itu. Tampaknya lurus ke depan untuk menggunakan null ketika berhadapan dengan database. Tetapi basis data tampak seperti detail implementasi yang tidak seharusnya menjadi perhatian pihak di sisi lain API. Misalnya mereka mungkin menggunakan datastore schemaless yang hanya menyimpan properti dengan nilai (non-null).

Dari sudut pandang kode, membatasi fungsi string hanya berfungsi dengan satu jenis, yaitu string(bukan nol), membuatnya lebih mudah untuk dibuktikan; menghindari nol juga merupakan alasan untuk memiliki Optionobjek. Jadi, jika kode yang menghasilkan permintaan / respons tidak menggunakan null, tebakan saya adalah kode di sisi lain API tidak akan dipaksa untuk menggunakan null juga.

Saya lebih suka ide menggunakan string kosong sebagai cara mudah untuk menghindari menggunakan null. Satu argumen yang saya dengar untuk menggunakan null dan terhadap string kosong adalah bahwa string kosong berarti properti itu ada. Meskipun saya memahami perbedaannya, saya juga bertanya-tanya apakah itu hanya detail implementasi dan apakah menggunakan string kosong atau kosong akan membuat perbedaan nyata. Saya juga bertanya-tanya apakah string kosong analog dengan array kosong.

Jadi, mana cara terbaik untuk melakukannya yang mengatasi masalah itu? Apakah itu tergantung pada format objek yang ditransfer (skema / skema)?


2
Perhatikan juga bahwa Oracle memperlakukan string kosong dan string kosong dengan cara yang sama. Dan di sana adalah: pada kertas kuesioner, bagaimana Anda bisa membedakan antara tidak ada jawaban yang diberikan dan jawaban yang terdiri dari string kosong?
Bernhard Hiller

Jika Anda menggunakan warisan, mudah untuk mengatakan. if( value === null) { use parent value; } Namun, jika Anda menetapkan nilai anak, bahkan ke string kosong (mis. Menimpa nilai induk default dengan kosong), lalu bagaimana Anda "mewarisi kembali" nilainya? Bagi saya, menetapkannya sebagai null berarti "setel nilai ini sehingga kami tahu untuk menggunakan nilai induk."
Frank Forte

Karena "Hapus properti kosong" juga merupakan alasan untuk "menghindari" a null(memang benar yang nulldihindari seperti itu), si penanya berarti "Kembalikan bukan-nol" [Objek] (yaitu: String kosong, Array kosong, dll.) Ketika mereka tulis "hindari".
cellepo

Jawaban:


18

TLDR; Hapus properti nol

Hal pertama yang perlu diingat adalah bahwa aplikasi di tepi mereka tidak berorientasi objek (atau fungsional jika pemrograman dalam paradigma itu). JSON yang Anda terima bukan objek dan tidak boleh diperlakukan seperti itu. Itu hanya data terstruktur yang dapat (atau mungkin tidak) dikonversi menjadi objek. Secara umum, JSON yang masuk tidak boleh dipercaya sebagai objek bisnis hingga validasi. Hanya fakta bahwa itu deserialized tidak membuatnya valid. Karena JSON juga memiliki primitif terbatas dibandingkan dengan bahasa back-end, sering layak untuk membuat DTO yang selaras JSON untuk data yang masuk. Kemudian gunakan DTO untuk membangun objek bisnis (atau kesalahan mencoba) untuk menjalankan operasi API.

Ketika Anda melihat JSON hanya sebagai format transmisi, lebih masuk akal untuk menghilangkan properti yang tidak disetel. Lebih sedikit mengirim melalui kawat. Jika bahasa back-end Anda tidak menggunakan nulls secara default, Anda mungkin dapat mengkonfigurasi deserializer Anda untuk memberikan kesalahan. Sebagai contoh, pengaturan umum saya untuk Newtonsoft.Json menerjemahkan properti null / missing hanya ke / dari optiontipe F # dan jika tidak akan terjadi kesalahan. Ini memberikan representasi alami bidang mana yang opsional (yang optionbertipe).

Seperti biasa, generalisasi hanya membuat Anda sejauh ini. Mungkin ada kasus di mana properti default atau null lebih cocok. Tetapi kuncinya adalah tidak melihat struktur data di tepi sistem Anda sebagai objek bisnis. Objek bisnis harus membawa jaminan bisnis (mis. Nama setidaknya 3 karakter) ketika berhasil dibuat. Tetapi struktur data yang ditarik dari kawat tidak memiliki jaminan nyata.


3
Walaupun sebagian besar serialis modern memiliki bidang opsional, menghilangkan null dari respons tidak selalu merupakan ide yang baik, karena menghilangkan kompleksitas tambahan untuk menangani bidang nullable. Jadi, ini benar - benar tergantung pada huruf besar-kecil , tergantung pada bagaimana pustaka serialisasi Anda menangani nullables, dan apakah kompleksitas potensial (atau tidak) dari penanganan nullables tersebut benar - benar layak disimpan beberapa byte per permintaan. Anda harus bekerja keras untuk menganalisis kasus bisnis Anda.
Chris Cirefice

@ ChrisCirefice Ya, saya percaya paragraf terakhir membahasnya. Ada kasus di mana akan lebih baik untuk menggunakan strategi yang berbeda.
Kasey Speakman

Saya setuju bahwa JSON hanya digunakan sebagai format transmisi, JSON tidak mengirimkan objek melalui kabel seperti CORBA. Saya juga setuju bahwa properti dapat ditambahkan dan dihapus; representasi dapat berubah, kontrol dapat berubah, terutama di web.
imel96

15

Pembaruan: Saya telah mengedit jawabannya sedikit, karena mungkin menyebabkan kebingungan.


Pergi dengan string kosong adalah tidak pasti. String kosong masih merupakan nilai, itu hanya kosong. Tidak ada nilai yang harus ditunjukkan menggunakan konstruk yang tidak mewakili apa pun null,.

Dari sudut pandang pengembang API, hanya ada dua jenis properti:

  • wajib (ini HARUS memiliki nilai jenis spesifik mereka dan TIDAK HARUS kosong),
  • opsional (MUNGKIN ini mengandung nilai dari tipe spesifik mereka tetapi MUNGKIN juga mengandung null.

Ini membuatnya cukup jelas bahwa ketika sebuah properti wajib, yaitu. diperlukan, tidak pernah bisa null.

Di sisi lain, jika properti opsional dari suatu objek tidak disetel dan dibiarkan kosong, saya lebih suka menyimpannya dalam respon dengan nullnilai. Dari pengalaman saya, ini memudahkan klien API untuk mengimplementasikan parsing, karena mereka tidak diharuskan memeriksa apakah suatu properti benar-benar ada atau tidak, karena selalu ada di sana, dan mereka dapat dengan mudah mengonversi respons ke DTO khusus mereka, memperlakukan nullnilai-nilai sebagai opsional.

Termasuk / menghapus bidang secara dinamis dari kekuatan respons termasuk kondisi tambahan pada klien.


Apa pun caranya, apa pun yang Anda pilih, pastikan Anda tetap konsisten dan terdokumentasi dengan baik. Dengan begitu tidak masalah apa yang Anda gunakan untuk API Anda, selama perilakunya dapat diprediksi.


Ya, string kosong adalah nilai dan saya gunakan nulluntuk referensi. Memadukan nilai dengan referensi adalah salah satu perhatian saya. Bagaimana Anda membedakan bidang opsional dengan nullbidang string non-opsional yang memiliki nullnilai? Sedang parsing, bukankah menguji keberadaan properti membuat parser lebih rapuh?
imel96

2
@ imel96 Bidang non-opsional TIDAK PERNAH menjadi nol. Jika sesuatu bersifat non-opsional, HARUS selalu berisi nilai (dari jenis spesifiknya).
Andy

3
Ini. Sebagai konsumen API yang sering, saya benci ketika saya harus berurusan dengan struktur "dinamis" yang kembali kepada saya, bahkan jika itu dalam bentuk bidang opsional yang dihilangkan. (Juga banyak setuju bahwa ada perbedaan besar antara ZLS dan Null). Saya dengan senang hati menerima nilai nol sepanjang hari. Sebagai penulis API, salah satu tujuan saya adalah membuat konsumsi klien semudah mungkin, dan itu berarti memiliki struktur data yang diharapkan, selalu.
jleach

@ Davidvider jadi, jika saya mengerti benar, Anda gunakan nulluntuk menunjukkan nilai opsional. Jadi, ketika Anda mendefinisikan objek yang memiliki properti string non-opsional, dan konsumen tidak memiliki properti ini, itu harus mengirim string kosong untuk properti itu. Apakah itu benar?
imel96

2
@GregoryNisbet Jangan lakukan itu, kumohon. Itu tidak masuk akal.
Andy

3

null Penggunaan tergantung pada Aplikasi / Bahasa

Pada akhirnya pilihan untuk digunakan atau tidaknya nullnilai aplikasi yang valid sebagian besar ditentukan oleh aplikasi Anda dan bahasa pemrograman / antarmuka / tepi.

Pada level fundamental, saya sarankan mencoba menggunakan tipe yang berbeda jika ada kelas nilai yang berbeda. nullmungkin menjadi opsi jika antarmuka Anda mengizinkannya dan hanya ada dua kelas properti yang Anda coba wakili. Menghilangkan properti mungkin menjadi opsi jika antarmuka atau format Anda memungkinkannya. Tipe agregat baru (kelas, objek, tipe pesan) dapat menjadi pilihan lain.

Sebagai contoh string Anda, jika ini dalam bahasa pemrograman, saya akan bertanya pada diri sendiri beberapa pertanyaan.

  1. Apakah saya berencana menambahkan jenis nilai di masa mendatang? Jika demikian, Optionmungkin akan lebih baik untuk desain antarmuka Anda.
  2. Kapan saya perlu memvalidasi panggilan konsumen? Secara statis? Secara dinamis? Sebelum? Setelah? Sama sekali? Jika bahasa pemrograman Anda mendukungnya, gunakan manfaat pengetikan statis karena menghindari jumlah kode yang harus Anda buat untuk validasi. Optionmungkin mengisi kasus ini dengan baik jika string Anda tidak dapat dibatalkan. Namun, Anda mungkin harus memeriksa input pengguna untuk nullnilai string, jadi saya mungkin akan menunda kembali ke pertanyaan pertama: berapa banyak tipe nilai yang ingin / ingin saya wakili.
  3. Apakah nullindikasi kesalahan programmer dalam bahasa pemrograman saya? Sayangnya, nullsering kali nilai default untuk petunjuk atau referensi yang tidak diinisialisasi (atau tidak diinisialisasi secara eksplisit) dalam beberapa bahasa. Apakah nullsebagai nilai dapat diterima sebagai nilai default? Apakah aman sebagai nilai default? Kadang null- kadang merupakan indikasi nilai yang tidak dialokasikan. Haruskah saya memberi konsumen antarmuka saya indikasi tentang potensi manajemen memori ini atau masalah inisialisasi dalam program mereka? Apa modus kegagalan dari panggilan seperti itu dalam menghadapi masalah seperti itu? Apakah penelepon dalam proses yang sama atau utas dengan saya sehingga kesalahan seperti itu berisiko tinggi untuk aplikasi saya?

Bergantung pada jawaban Anda atas pertanyaan-pertanyaan ini, Anda mungkin dapat mengasah apakah nullantarmuka Anda cocok atau tidak .

Contoh 1

  1. Aplikasi Anda sangat penting untuk keselamatan
  2. Anda menggunakan beberapa jenis inisialisasi heap pada startup dan nullkemungkinan nilai string dikembalikan setelah kegagalan mengalokasikan ruang untuk string.
  3. Ada potensi string tersebut mengenai antarmuka Anda

Jawab: nullmungkin tidak tepat

Dasar Pemikiran: nulldalam hal ini sebenarnya digunakan untuk menunjukkan dua jenis nilai yang berbeda. Yang pertama mungkin merupakan nilai default yang ingin ditetapkan pengguna antarmuka Anda. Sayangnya, nilai kedua adalah tanda untuk menunjukkan bahwa sistem Anda tidak berfungsi dengan benar. Dalam kasus seperti itu, Anda mungkin ingin gagal seaman mungkin (apa pun artinya bagi sistem Anda).

Contoh 2

  1. Anda menggunakan struct C yang memiliki char *anggota.
  2. Sistem Anda tidak menggunakan alokasi tumpukan dan Anda menggunakan pemeriksaan MISRA.
  3. Antarmuka Anda menerima struct ini sebagai penunjuk dan memeriksa untuk memastikan bahwa struct tidak menunjuk ke NULL
  4. Nilai default dan aman char *anggota untuk API Anda dapat ditunjukkan dengan nilai tunggalNULL
  5. Setelah inisialisasi struct pengguna Anda, Anda ingin memberikan kemungkinan kepada pengguna untuk tidak menginisialisasi char *anggota secara eksplisit .

Jawab: NULLmungkin tepat

Dasar Pemikiran: Ada sedikit kemungkinan bahwa struct Anda melewati NULLpemeriksaan tetapi tidak diinisialisasi. Namun, API Anda mungkin tidak dapat menjelaskan hal ini kecuali Anda memiliki semacam checksum pada nilai struct dan / atau rentang memeriksa alamat struct. Linter MISRA-C dapat membantu pengguna API Anda dengan menandai penggunaan struct sebelum inisialisasi mereka. Namun, untuk char *anggota, jika penunjuk ke struct menunjuk ke struct yang diinisialisasi, NULLadalah nilai default dari anggota yang tidak ditentukan dalam penginisialisasi struct. Oleh karena itu, NULLdapat berfungsi sebagai nilai default aman untuk char *anggota struct di aplikasi Anda.

Jika itu pada antarmuka serialisasi, saya akan bertanya pada diri sendiri pertanyaan berikut tentang apakah akan menggunakan null pada string.

  1. Apakah nullindikasi potensi kesalahan sisi klien? Untuk JSON dalam JavaScript, ini mungkin tidak karena nulltidak selalu digunakan sebagai indikasi kegagalan alokasi. Dalam JavaScript, ini digunakan sebagai indikasi eksplisit tentang tidak adanya objek dari referensi yang akan ditetapkan bermasalah. Namun, ada parser dan serialis non-javascript di luar sana yang memetakan JSON nullke nulltipe asli . Jika ini masalahnya, ini meminta diskusi tentang apakah nullpenggunaan asli atau tidak cocok untuk kombinasi bahasa, parser, dan serializer tertentu.
  2. Apakah ketiadaan nilai properti secara eksplisit berdampak lebih dari nilai properti tunggal? Kadang-kadang a nullsebenarnya menunjukkan bahwa Anda memiliki tipe pesan baru seluruhnya. Mungkin lebih bersih bagi konsumen Anda dari format serialisasi untuk hanya menentukan jenis pesan yang sama sekali berbeda. Ini memastikan bahwa validasi dan logika aplikasi mereka dapat memiliki pemisahan yang bersih antara dua perbedaan pesan yang disediakan antarmuka web Anda.

Nasihat Umum

nulltidak dapat menjadi nilai di tepi atau antarmuka yang tidak mendukungnya. Jika Anda menggunakan sesuatu yang sifatnya sangat longgar pada pengetikan nilai properti (yaitu JSON), cobalah untuk mendorong beberapa bentuk skema atau validasi pada perangkat lunak edge konsumen (mis. Skema JSON ) jika Anda bisa. Jika itu adalah bahasa pemrograman API, validasikan input pengguna secara statis jika memungkinkan (melalui pengetikan) atau sekeras yang masuk akal dalam runtime (alias praktikkan pemrograman defensif pada antarmuka yang dihadapkan konsumen). Yang terpenting, dokumentasikan atau tentukan tepi sehingga tidak ada pertanyaan tentang:

  • Jenis nilai apa yang diterima properti yang diberikan
  • Rentang nilai apa yang valid untuk properti yang diberikan.
  • Bagaimana jenis agregat harus disusun. Properti apa yang harus / harus / dapat hadir dalam tipe agregat?
  • Jika itu adalah beberapa jenis wadah, berapa banyak barang yang dapat atau harus dimiliki oleh wadah tersebut, dan apa saja jenis nilai yang dimiliki wadah tersebut?
  • Bagaimana urutan, jika ada, properti atau instance dari wadah atau tipe agregat dikembalikan?
  • Apa efek samping dari penetapan nilai-nilai tertentu dan apa efek samping dari membaca nilai-nilai itu?

1

Berikut analisis pribadi saya terhadap pertanyaan-pertanyaan ini. Itu tidak didukung oleh buku, kertas, studi atau apa pun, hanya pengalaman pribadi saya.

String kosong sebagai null

Ini adalah jalan keluar bagi saya. Jangan mencampur semantik string kosong dengan yang tidak didefinisikan. Dalam banyak kasus, mereka dapat dipertukarkan dengan sempurna, tetapi Anda dapat mengalami kasus-kasus di mana yang tidak didefinisikan dan didefinisikan tetapi kosong berarti sesuatu yang berbeda.

Semacam contoh bodoh: katakanlah ada atribut yang menyimpan kunci asing, dan atribut itu tidak didefinisikan atau sedang null, itu berarti bahwa tidak ada hubungan yang didefinisikan, sedangkan string kosong ""dapat dipahami sebagai hubungan yang didefinisikan dan ID rekaman asing adalah string kosong itu.

Tidak didefinisikan vs null

Ini bukan topik hitam atau putih. Ada pro dan kontra untuk kedua pendekatan tersebut.

Dalam mendukung nullnilai-nilai yang mendefinisikan secara eksplisit , ada pro ini:

  • Pesan-pesannya lebih deskriptif diri sehingga Anda bisa mengetahui semua kunci hanya dengan melihat pesan apa pun
  • Terkait dengan poin sebelumnya, lebih mudah untuk membuat kode dan mendeteksi kesalahan pada konsumen data: lebih mudah untuk mendeteksi kesalahan jika Anda mengambil kunci yang salah (mungkin salah mengeja, mungkin API berubah, dll).

Dalam mendukung asumsi kunci tidak ada sama dengan semantik null:

  • Beberapa perubahan lebih mudah diakomodasi. Misalnya, jika versi baru dari skema pesan menyertakan kunci baru, Anda dapat mengkode konsumen informasi untuk bekerja dengan kunci masa depan ini, bahkan ketika produsen pesan belum diperbarui dan belum melayani informasi ini.
  • Pesan bisa kurang verbal atau lebih pendek

Seandainya API entah bagaimana stabil, dan Anda mendokumentasikannya dengan seksama, saya pikir sangat baik untuk menyatakan bahwa kunci yang tidak ada sama dengan arti null. Tetapi jika lebih berantakan dan kacau (seperti yang sering terjadi), saya pikir Anda dapat menghindari sakit kepala jika Anda secara eksplisit mendefinisikan setiap nilai dalam setiap pesan. Yaitu jika ragu, saya cenderung mengikuti pendekatan verbose.

Semua yang dikatakan, hal terpenting terpenting: nyatakan niat Anda dengan jelas dan konsisten. Jangan lakukan satu hal di sini dan yang lain di sana. Perangkat lunak yang dapat diprediksi adalah perangkat lunak yang lebih baik.


Contoh untuk menggunakan string kosong adalah apa yang saya maksud dengan detail implementasi, yaitu dengan asumsi API digunakan untuk mengekspos baris database. Apakah akan ada bedanya jika tidak ada database yang terlibat dan murni untuk mentransfer representasi objek?
imel96

Tidak harus detail implementasi. Contoh saya sebenarnya berbicara tentang PK yang terkait dengan DB, tetapi yang saya coba jelaskan adalah string kosong tidak nihil / tidak ada / null. Contoh lain: dalam permainan, ada objek karakter, dan memiliki atribut "mitra". Seorang nullpasangan jelas berarti bahwa tidak ada pasangan sama sekali, tetapi ""dapat dipahami karena ada pasangan yang namanya "".
bgusach

Saya baik-baik saja dengan referensi mitra nol berarti tidak ada mitra dan juga referensi bukan string. Tetapi nama mitra adalah string, bahkan jika Anda mengizinkan nol sebagai nama mitra, tidakkah Anda akan menangkap nol itu dan menggantinya dengan string kosong di beberapa titik?
imel96

Jika tidak ada mitra, saya tidak akan mengubah nulluntuk string kosong. Mungkin membuatnya dalam bentuk, tetapi tidak pernah dalam model data.
bgusach

Maksud saya bukan pasangan, pasangan akan menjadi objek. Itu mitra nameyang saya bicarakan, apakah Anda mengizinkan nama mitra menjadi nol?
imel96

1

Saya akan memasok string kosong dalam situasi di mana string hadir, dan itu terjadi menjadi string kosong. Saya akan memberikan nol dalam situasi di mana saya ingin secara eksplisit mengatakan "tidak, data ini tidak ada". Dan hilangkan kunci untuk mengatakan "tidak ada data di sana, jangan repot-repot".

Anda menilai situasi mana yang bisa terjadi. Apakah masuk akal jika aplikasi Anda memiliki string kosong? Apakah Anda ingin membedakan antara mengatakan "tidak ada data" secara eksplisit dengan menggunakan nol dan secara implisit dengan tidak memiliki nilai? Anda seharusnya hanya memiliki kedua kemungkinan (null dan tidak ada kunci sekarang) jika keduanya perlu dibedakan oleh klien.

Sekarang perlu diingat bahwa ini semua tentang pengiriman data. Apa yang penerima lakukan dengan data adalah urusan mereka, dan mereka akan melakukan apa yang paling nyaman bagi mereka. Penerima harus dapat menangani apa pun yang Anda lemparkan padanya (mungkin dengan menolak data) tanpa menabrak.

Jika tidak ada pertimbangan lain, maka saya akan mengirimkan apa yang paling nyaman bagi pengirim, dan mendokumentasikannya . Saya lebih suka untuk tidak mengirim nilai yang tidak ada sama sekali karena ini cenderung meningkatkan kecepatan penyandian, transmisi dan penguraian JSON.


Saya suka poin Anda dalam "jika perlu dibedakan oleh klien".
imel96

0

Meskipun saya tidak bisa mengatakan apa yang terbaik itu hampir pasti bukan detail implementasi yang sederhana , itu mengubah struktur bagaimana Anda dapat berinteraksi dengan variabel itu.

Jika sesuatu bisa menjadi nol Anda harus selalu memperlakukannya seolah-olah itu akan menjadi nol di beberapa titik , jadi Anda akan selalu memiliki dua alur kerja , satu untuk nol, satu untuk string yang valid. Split workflow tidak selalu merupakan hal yang buruk, karena ada sedikit penanganan kesalahan dan penggunaan case khusus yang dapat Anda manfaatkan, tetapi itu mengaburkan kode Anda.

Jika Anda selalu berinteraksi dengan string dengan cara yang sama , mungkin akan lebih mudah untuk fungsionalitas untuk tetap berada di kepala Anda .

Jadi seperti halnya dengan pertanyaan "apa yang terbaik", saya pergi dengan jawabannya: itu tergantung . Jika Anda ingin membagi alur kerja Anda dan menangkap secara lebih eksplisit ketika sesuatu tidak disetel, gunakan null. Jika Anda lebih suka program tetap seperti apa adanya, gunakan string kosong. Yang penting adalah Anda konsisten , pilih pengembalian bersama dan tetap dengan itu.

Mengingat Anda membuat API, saya akan merekomendasikan menempel pada string kosong karena ada lebih sedikit bagi pengguna untuk mengimbangi, karena sebagai pengguna API saya tidak akan tahu setiap alasan API Anda bisa memberi saya nilai nol kecuali jika Anda didokumentasikan dengan sangat baik, yang tidak akan dibaca oleh beberapa pengguna.


Memiliki "membagi alur kerja" itu buruk. Katakanlah di sisi produsen semuanya bersih, metode tipe string hanya mengembalikan strings, tidak pernah nol. Jika API menggunakan null, maka pada titik tertentu produsen perlu membuat ini nullagar sesuai dengan API. Maka konsumen perlu menangani nulljuga. Tapi saya pikir saya mengerti apa yang Anda katakan, hanya memutuskan dan mendefinisikan API dengan otoritas, bukan? Apakah itu berarti tidak ada yang salah dengan mereka?
imel96

Ya, apa pun yang Anda lakukan di API akan memengaruhi cara pengguna harus menyusun kode mereka, jadi dengan mempertimbangkan desain Anda dalam hal pengguna API, Anda harus dapat menentukan cara mana yang terbaik. Pada akhirnya itu adalah API Anda. Bersikaplah konsisten. Hanya Anda yang dapat memutuskan pro dan kontra untuk pendekatan tersebut.
Erdrik Ironrose

0

Dokumen!

TL; DR>

Lakukan sesuai keinginan Anda - terkadang konteks di mana ia digunakan penting. Contoh, Bind Variabel ke Oracle SQL: String Kosong ditafsirkan sebagai NULL.

Cukup saya katakan - Pastikan Anda mendokumentasikan setiap skenario yang disebutkan

  • BATAL
  • Kosong (kosong)
  • Tidak ada (dihapus)

Kode Anda mungkin bertindak dengan cara berbeda - mendokumentasikan bagaimana kode Anda bereaksi terhadapnya:

  • Gagal (Pengecualian dll), bahkan mungkin gagal validasi (mungkin pengecualian yang diperiksa) vs tidak dapat menangani situasi dengan benar (NullPointerException).
  • Berikan standar yang masuk akal
  • Kode berperilaku berbeda

Kemudian selain itu - terserah pada Anda untuk berperilaku secara konsisten, dan mungkin mengadopsi beberapa praktik terbaik Anda sendiri. Dokumentasikan perilaku yang konsisten. Contoh:

  • Perlakukan Null dan Missing sama
  • Perlakukan string kosong persis seperti itu. Hanya dalam kasus pengikat SQL, itu mungkin dianggap kosong. Pastikan SQL Anda berperilaku konsisten dan dengan cara yang diharapkan.

Masalahnya adalah, tanpa menyikapi keprihatinan, perselisihan cukup sering terjadi. Pertimbangkan dalam lingkungan tim, keputusan haruslah keputusan tim, sering kali itu berarti akan ada pertengkaran. Ketika Anda memiliki banyak tim, setiap tim berhak atas keputusan mereka sendiri. Saya telah melihat API yang hanya dapat saya duga API diimplementasikan oleh tim berbeda yang tidak setuju satu sama lain. Jika ada yang bisa menyetujui satu hal, mendokumentasikannya adalah hal sepele.
imel96

0

tl; dr - jika Anda menggunakannya: konsisten dalam artinya.

Jika Anda termasuk null, apa artinya? Ada alam semesta hal-hal yang bisa berarti. Satu nilai sama sekali tidak cukup untuk mewakili nilai yang hilang atau tidak diketahui (dan ini hanya dua dari segudang kemungkinan: misalnya Hilang - itu sudah diukur, tetapi kami belum mengetahuinya. Tidak diketahui - kami tidak mencoba mengukur saya t.)

Dalam contoh yang saya temui baru-baru ini, bidang dapat kosong karena tidak dilaporkan untuk melindungi privasi seseorang, tetapi bidang itu diketahui di sisi pengirim, tidak dikenal di sisi pengirim, tetapi diketahui oleh reporter asli atau tidak diketahui keduanya. Dan semua ini penting bagi penerima. Jadi biasanya satu nilai saja tidak cukup.

Dengan asumsi dunia terbuka (Anda benar-benar tidak tahu tentang hal-hal yang tidak disebutkan), Anda cukup meninggalkannya dan itu bisa apa saja. Dengan asumsi dunia tertutup (hal-hal yang tidak dinyatakan salah, misalnya dalam SQL) Anda sebaiknya memperjelas apa nullartinya dan konsisten dengan definisi itu karena Anda dapat ...

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.