Haruskah server “bersikap lunak” dalam apa yang diterimanya dan “membuang input yang salah secara diam-diam”?


27

Saya mendapat kesan bahwa sekarang semua orang setuju bahwa pepatah ini adalah kesalahan. Tetapi saya baru-baru ini melihat jawaban ini yang memiliki komentar "bersikap lunak" terangkat 137 kali (pada hari ini).

Menurut pendapat saya, keringanan hukuman dalam apa yang diterima browser adalah penyebab langsung dari kekacauan total yang HTML dan beberapa standar web lainnya beberapa tahun yang lalu, dan baru-baru ini mulai mengkristal dengan baik dari kekacauan itu. Cara saya melihatnya, bersikap lunak dalam apa yang Anda terima akan mengarah ke ini.

Bagian kedua dari pepatah adalah "membuang input yang salah secara diam-diam, tanpa mengembalikan pesan kesalahan kecuali ini diminta oleh spesifikasi" , dan ini terasa ofensif garis batas. Setiap programmer yang telah membenturkan kepalanya ke dinding ketika sesuatu gagal diam-diam akan tahu apa yang saya maksud.

Jadi, apakah saya benar-benar salah tentang ini? Haruskah program saya lunak dalam menerima dan menelan kesalahan secara diam-diam? Atau apakah saya salah menafsirkan apa artinya ini?


Pertanyaan aslinya mengatakan "program", dan saya mengambil poin semua orang tentang itu. Masuk akal jika program bersikap lunak. Apa yang sebenarnya saya maksudkan adalah API: antarmuka yang terpapar ke program lain , bukan orang. HTTP adalah contohnya. Protokol adalah antarmuka yang hanya digunakan oleh program lain. Orang tidak pernah secara langsung memberikan tanggal yang masuk ke tajuk seperti "Jika-Dimodifikasi-Sejak".

Jadi, pertanyaannya adalah: haruskah server menerapkan standar lebih lunak dan memungkinkan tanggal dalam beberapa format lain, selain yang sebenarnya diperlukan oleh standar? Saya percaya "bersikap lunak" seharusnya berlaku untuk situasi ini, bukan antarmuka manusia.

Jika server lunak, mungkin tampak seperti perbaikan keseluruhan, tapi saya pikir dalam praktiknya hanya mengarah pada implementasi klien yang akhirnya bergantung pada keringanan hukuman dan dengan demikian gagal bekerja dengan server lain yang lunak dengan cara yang sedikit berbeda.

Jadi, haruskah server yang mengekspos beberapa API bersikap lunak atau apakah itu ide yang sangat buruk?


Sekarang ke penanganan input pengguna yang lunak. Pertimbangkan YouTrack (perangkat lunak pelacakan bug). Ini menggunakan bahasa untuk entri teks yang mengingatkan pada penurunan harga. Kecuali bahwa itu "lunak". Misalnya menulis

- foo
- bar
- baz

adalah tidak cara didokumentasikan membuat daftar bullet, namun itu bekerja. Akibatnya, akhirnya banyak digunakan di seluruh bugtracker internal kami. Versi berikutnya keluar, dan fitur ringan ini mulai bekerja sedikit berbeda, mematahkan banyak daftar yang (salah) menggunakan fitur (non) ini. Cara terdokumentasi untuk membuat daftar berpoin masih bekerja, tentu saja.

Jadi, haruskah perangkat lunak saya lunak dalam input pengguna apa yang diterima?


4
Mengenai "buang input yang salah secara diam-diam," Saya akan menanyakan setiap kasus apa yang harus dianggap sebagai input yang salah. Jika Anda mengajukan pertanyaan kepada pengguna dan mengharapkan "ya" atau "tidak", apakah input "YA" salah? Bagaimana dengan "y"? Bagaimana dengan "oui"? Secara umum, jangan malu memberi tahu pengguna bahwa input mereka tidak seperti yang Anda harapkan. Namun pastikan Anda sudah inklusif mungkin - dalam pikiran saya, itulah yang dimaksud dengan "bersikap lunak".

3
Jika Anda berbicara tentang input pengguna akhir - yang terkait dengan friendlines pengguna aplikasi Anda, maka Anda harus memimpin; untuk input yang dihasilkan mesin otomatis (dari API), Anda harus bertele-tele (ketat).
Burhan Khalid

2
Sebenarnya keringanan HTML adalah mengapa ia menjadi sangat populer (dan ketatnya XHTML mengapa ia dijatuhkan).
Oliver Weiler

1
Saya pikir kuncinya adalah bahwa jika itu adalah skenario di mana Anda dapat membiarkannya gagal dengan anggun adalah Anda setidaknya mencatat acara tersebut.
Rig

2
@ OliverWeiler Saya merasa kegagalan XHTML ada hubungannya dengan fakta bahwa itu sepenuhnya tidak diperlukan. HTML sudah ada dan agak berfungsi. Juga, sementara HTML tentu saja sangat populer, agak menyedihkan bahwa kami menyebut teknologi ini sukses. Itu memenuhi permintaan, tetapi itu tentang Symbian memenuhi permintaan untuk smartphone.
Roman Starkov

Jawaban:


9

Tentu saja Anda sepenuhnya benar. Program tidak boleh “lunak” karena hal itu hanya berfungsi untuk menutupi masalah. Masalah harus disorot, bukan disapu di bawah karpet. Pesan kesalahan yang informatif adalah suatu keharusan mutlak bagi suatu program untuk membantu pengguna.

Sebagian besar waktu ketika data yang salah / tidak valid disediakan, penyedia data itu (apakah itu pengguna atau output dari beberapa program lain) mungkin tidak tahu itu tidak valid. Menelan kesalahan akan membuat mereka tetap percaya bahwa itu (atau mungkin) valid, yang memperbanyak data yang tidak valid.

Satu-satunya cara bagi sistem untuk beroperasi adalah agar interoperasinya dapat sepenuhnya dan tidak ambigu. Sebuah program yang menerima data di luar spesifikasi membuat data secara de facto diterima bahkan jika itu tidak valid oleh spesifikasi, yang tidak hanya membuat kompatibilitas menjadi beban yang lebih besar lebih sulit, tetapi juga berarti itu tidak lagi didefinisikan secara formal. Program itu sendiri sekarang menjadi standar de facto . Dengan demikian, program lunak tidak mungkin untuk dikembangkan lebih lanjut atau untuk diganti karena Anda tidak dapat membuat perubahan terkecil pada cara kerjanya.


25

Saya pikir itu semua tergantung pada siapa target demografis Anda. Jika itu programmer, maka sama sekali tidak. Program Anda harus gagal dan menjerit pembunuhan berdarah. Namun, jika audiens target Anda bukan programmer, maka program Anda harus lunak di mana ia dapat menangani pengecualian dengan anggun, jika tidak, berbisik pembunuhan berdarah manis.

Sebagai studi kasus, gunakan NPAPI Flash player. Ada versi "rilis" untuk mereka yang tidak benar-benar peduli tentang 99% kesalahan yang dapat terjadi, tetapi ada juga versi "debug" yang dapat digunakan yang menjerit pembunuhan berdarah saat ada yang tidak beres. Setiap dukungan memutar konten Flash jelas, tetapi ditargetkan untuk dua demografi yang sama sekali berbeda.

Pada akhirnya, saya pikir yang penting adalah: Apa yang diperhatikan pengguna Anda?


4
Sebagian besar alat baris perintah Unixy yang mengklaim memiliki target audiens di luar programmer tetap tidak berguna bagi pengguna yang melakukan kesalahan. Bahkan jika Anda bukan seorang programmer, biasanya suatu program lebih baik untuk menjelaskan masalah daripada melakukan sesuatu yang tidak masuk akal atau tidak disengaja.
Timwi

2
@romkyns: Tidak sepenuhnya, saya katakan bahwa aplikasi Anda harus menangani kesalahan dengan cara yang masuk akal bagi pengguna yang ditargetkan.
Demian Brecht

@Timwi: Dalam hal ini, alat-alat baris perintah Unixy tidak dirancang dengan baik;)
Demian Brecht

3
@romkyns - Saya pikir contoh yang baik adalah: Dalam mode debug, Anda ingin sebuah program berhenti pada masalah apa pun dan memberi tahu Anda apa yang salah. Dalam mode produksi, Anda ingin program Anda terus bekerja sebaik mungkin, dan mencatat semua masalah yang dapat ditangani. Dengan cara ini, programmer dapat melihat apa yang mereka lakukan salah dan memperbaikinya, tetapi pengguna tidak akan terganggu dengan hal-hal yang tidak dapat mereka perbaiki. Beberapa masalah jelas tidak dapat diperbaiki, tetapi contoh yang baik adalah aturan gaya CSS, di mana Anda masih dapat merender situs, bahkan jika Anda tidak memahami salah satu aturan gaya.
Pasang kembali Monica

1
Komentar @ BrendanLong cukup banyak menyentuh kepala - terkadang menghasilkan output lebih penting daripada benar. Beberapa kesalahan (atau peringatan) dapat dipulihkan dengan anggun dari, tanpa masukan dari pengguna; Terserah Anda untuk memutuskan apa yang Anda ingin aplikasi Anda lakukan dalam kasus ini.
Daniel B

7

Ada dua jenis "lunak": Yang pertama adalah menerima input yang salah dan mencoba memahaminya, dan yang lain adalah menerima berbagai jenis input yang berbeda.

Secara umum, Anda selalu menginginkan yang kedua jika memungkinkan. Yang pertama adalah ketika Anda mati dengan cepat dan keras. Contoh: Tanggal.

Berikut beberapa contoh input, termasuk yang valid, tidak valid, dan ambigu.

  • 2011-01-02
  • 01/02/2011
  • Jan 2, 2011
  • 2-Jan-2011
  • Green

Hanya ada satu input tidak valid di sini: Green. Jangan mencoba menerimanya sebagai kencan. Karena Greenjelas bukan kencan, ini adalah kasus di mana kegagalan diam dapat diterima.

01/02/2011valid, tetapi ambigu. Anda tidak perlu tahu apakah ini dimasukkan sebagai tanggal AS (2 Jan) atau tidak (1 Februari). Di sini, mungkin yang terbaik untuk gagal dengan keras, dan meminta tanggal yang jelas bagi pengguna.

2011-01-02biasanya dianggap tidak ambigu, jadi sering kali baik untuk melanjutkan dan menganggap itu format "YYYY-MM-DD", dan hanya gagal lebih jauh di telepon. Ini sedikit panggilan penilaian, ketika berhadapan dengan input pengguna.

Jan 2, 2011dan 2-Jan-2011valid dan tidak ambigu, mereka harus diterima. Namun, The Second of January of the year 2011ini juga berlaku dan tidak ambigu, tapi akan jauh demi kelonggaran berlebihan. Silakan gagal secara diam-diam, sama seperti Green.

Singkatnya , jawabannya adalah "itu tergantung". Lihatlah apa yang bisa dimasukkan, dan pastikan Anda tidak pernah menerima jenis input yang bertentangan (seperti DD/MM/YYYYvs MM/DD/YYYY).

Dalam konteks pertanyaan / komentar terkait , Itu adalah kasus 2011-01-02. Input terlihat seperti JSON dan akan divalidasi seperti JSON bahkan jika mimetype salah; lanjutkan dan cobalah untuk menggunakannya bahkan jika gagal di beberapa titik lebih jauh di telepon.


1
Ada satu hal yang tidak Anda pertimbangkan di sini. Jika pengguna mengetik string itu maka ya, saya harus menerima berbagai format, tidak diragukan lagi. Tapi kita berbicara tentang API. Klien API adalah program lain. Jika lunak dalam format tanggalnya, setiap server di masa depan yang mengekspos API ini harus lunak dengan cara yang sama persis atau risiko ketidakcocokan. Kelonggaran akhirnya menjadi merugikan daripada membantu, bukan begitu?
Roman Starkov

1
@romkyns Saya pikir Anda salah paham di mana keringanan hukuman terletak. API harus lunak dalam apa yang menerima (itu harus memahami semua 2011-01-02, Jan 2, 2011, dan 2-Jan-2011, jika itu tidak terlalu sulit untuk menerapkan), tidak dalam apa output . Klien masa depan untuk API itu bahkan tidak perlu tahu tentang yang diberikan, selama mereka memasukkan salah satu dari mereka dengan benar. Idealnya, lapisan API akan mengonversi semua ini ke representasi internal yang sama yang digunakan kode sebelum meneruskannya.
Izkata

@romkyns Output dapat, misalnya, selalu dalam 2011-01-02format, dan itulah yang Anda masukkan ke dalam dokumentasi Anda. Saya tidak melihat efek yang merugikan sama sekali.
Izkata

4
@Izkata: Anda salah paham. Bayangkan ada program lama yang hanya tersedia sebagai biner. Anda harus menulis program baru yang menerima input yang sama dengan yang lama. Jika program lama didefinisikan dengan baik dalam apa yang diterimanya, pekerjaan Anda didefinisikan dengan baik. Jika ringan, maka pekerjaan Anda tidak mungkin.
Timwi

1
A sangat tidak setuju. kecuali input yang dimasukkan pengguna, selalu ketat pada input dan output. Apa yang terjadi ketika layanan Anda perlu diimplementasikan kembali? Apakah Anda mendokumentasikan semua format tanggal yang mungkin? Anda harus menerapkan semuanya, karena Anda tidak ingin klien lama rusak. Silakan, gunakan ISO 8601 untuk semua instance dan periode tanggal yang dihasilkan mesin: ini ditentukan dengan baik dan tersedia secara luas di perpustakaan. Omong-omong, apa arti 2011-01-02 sebenarnya? Periode waktu dari jam 00:00 tanggal 2 hingga jam 00:00 tanggal 3? Di zona waktu apa?
Dibbeke

6

Gagal diam-diam adalah hal terburuk yang bisa Anda lakukan, selamanya. Sudahkah Anda mencoba men-debug API dengan kegagalan diam? Itu tidak mungkin .

Ada "Lakukan yang terbaik untuk memulihkan tetapi mengirim kesalahan terperinci" dan ada "Kegagalan sunyi".


3

Tampak bagi saya bahwa Hukum Postel - "Jadilah konservatif dalam apa yang Anda lakukan, menjadi liberal dalam apa yang Anda terima dari orang lain" adalah apa yang sedang dibahas untuk layanan JSON. Ini biasanya diterapkan pada layanan web dan bukan UI.

Untuk umpan balik pengguna konstruktif UI dan membatasi input pengguna adalah aturan praktis yang kami gunakan.


Tetapi jika Anda melihat jawabannya di sini, semua orang tampaknya setuju bahwa itu hanya masuk akal untuk UI, yaitu kebalikan dari hukum asli.
Roman Starkov

Saya mengerti apa yang Anda katakan, dan setuju dengan poster bahwa API / Layanan bersih yang ketat adalah tujuannya, tetapi untuk yang lebih baik atau lebih buruk, saya tahu saya telah menambahkan 'ketahanan' dalam satu atau lain bentuk pada layanan saya. Biasanya satu atau dua nilai terjemahan di perbatasan. Selama maknanya jelas, aplikasi tahu bagaimana memproses pesan dan tidak ada aturan bisnis yang dilanggar kemudian menambahkan kekokohan akan membantu interoperabilitas.
MarcLawrence

Sampai orang lain pergi dan mengimplementasikan spek Anda, hanya untuk menemukan bahwa "kekokohan", yang menjadi
andalan

3

Saya pikir ini tercakup dengan baik dalam bab 1, bagian 6 dari TAOUP. Secara khusus, aturan perbaikan , yang menyatakan bahwa suatu program harus melakukan apa yang dapat dilakukan dengan input, meneruskan data yang benar ke depan, dan jika respons yang benar adalah kegagalan maka lakukan ASAP.

Konsep serupa adalah pemrograman defensif . Anda tidak tahu input apa yang akan Anda terima, tetapi program Anda harus cukup kuat untuk mencakup semua kasus. Ini berarti harus ada diprogram dalam kasus pemulihan untuk masalah yang diketahui seperti input hancur, dan menangkap semua kasus untuk menangani yang tidak diketahui.

Jadi membuang masukan rusak diam-diam baik-baik saja, asalkan Anda yang menangani masukan itu. Anda seharusnya tidak menjatuhkannya begitu saja ke lantai.


Untuk API, saya pikir menjadi lunak sama dengan untuk sebuah program. Inputnya masih salah , tetapi Anda berusaha memperbaiki sebanyak mungkin. Perbedaannya adalah apa yang dianggap perbaikan yang valid . Seperti yang Anda tunjukkan, API lunak dapat menyebabkan masalah karena orang menggunakan "fitur" yang tidak ada.

Tentu saja, API hanyalah versi level rendah dari aturan komposisi . Dengan demikian, itu benar-benar tercakup dalam aturan yang paling tidak mengejutkan , karena itu adalah antarmuka.

Seperti kutipan dari Spencer mencatat, hindari kesamaan dangkal, yang dapat diperdebatkan tentang input "fuzzy". Di bawah kondisi ini, saya biasanya berpendapat bahwa semuanya menunjuk ke program yang tidak dapat diperbaiki, karena tidak akan tahu apa yang diinginkan, dan paling tidak mengejutkan untuk basis pengguna.

Namun, Anda berurusan dengan tanggal yang memiliki banyak "standar". Kadang-kadang ini bahkan dicampur dalam satu program (rantai). Karena Anda tahu bahwa sebuah kencan diharapkan, berusaha mengenali tanggal hanyalah desain yang bagus. Terutama jika tanggalnya berasal dari beberapa program eksternal dan akan dilewatkan tanpa modifikasi melalui sedetik pun pada Anda.


2

Program yang digunakan untuk server, sebagian besar waktu, seharusnya mengambil ribuan permintaan setiap menit, atau kadang-kadang setiap detik. Jika program server menerima dan memperbaiki input yang salah dari klien, saya khawatir itu akan memiliki 2 kelemahan:

  1. Kehilangan waktu server yang berharga. Dengan 1000+ permintaan per detik, memeriksa kesalahan pada setiap permintaan dapat mencerminkan respons yang lambat untuk setiap klien.
  2. Tidak adil untuk klien / klien-program yang memberikan input yang benar. Selain itu, ketika programmer sisi server duduk pada kode server, ia harus memikirkan berbagai kasus dari apa input yang salah. Siapa yang akan memutuskan itu?

Program server tidak boleh menerima input yang salah, tetapi server harus mengembalikan pesan kesalahan ke klien, jika ada input yang salah.


2

Tingkah laku yang ideal, secara konseptual, adalah melakukan apa yang dapat dilakukan dengan aman, sementara secara bersamaan memastikan bahwa seseorang yang dapat memperbaiki masalah, entah bagaimana, diberitahu tentang mereka. Dalam praktiknya, tentu saja, kendala yang terakhir sering kali tidak mungkin dipenuhi secara langsung, sehingga pertanyaannya menjadi yang terbaik untuk berurusan dengan input yang meragukan.

Satu hal yang dapat sangat membantu dalam mendesain protokol, memformat spec, atau "bahasa" adalah memiliki alat untuk membedakan empat kategori item potensial yang tidak dipahami:

  1. Hal-hal yang harus disaring jika tidak dipahami.
  2. Hal-hal yang harus diabaikan jika tidak dipahami, tetapi tetap dipertahankan jika data perlu diteruskan (mungkin dalam semacam bungkus untuk menunjukkan bahwa ia telah melewati setidaknya satu tahap yang tidak memahaminya)
  3. Hal-hal yang seharusnya menghasilkan peringatan jika tidak dipahami, tetapi tidak boleh mencegah upaya pemulihan data (misalnya dalam halaman web, objek yang tipenya tidak diketahui, tetapi ujungnya di dalam file terdefinisi dengan baik, mungkin dirender sebagai warna merah "X" tanpa mencegah bagian halaman yang lain ditampilkan.)
  4. Hal-hal yang menunjukkan bahwa apa pun yang tidak dapat memahaminya cenderung memiliki masalah parah dan tidak dapat dipulihkan di tempat lain (misalnya indikator bahwa data yang tersisa dikompresi, dan apa pun yang akan dipahami oleh apa pun yang dapat melakukan kompresi yang diperlukan).

Memiliki konvensi yang terdefinisi dengan baik di mana aplikasi yang dapat membaca versi apa pun dari format data akan dapat mengenali kategori mana yang sesuai untuk apa pun yang dihasilkan sesuai dengan versi yang lebih baru adalah pendekatan yang jauh lebih baik daripada mencoba menyinggung langkah-langkah kompatibilitas ad-hoc kemudian. Misalnya, jika format file memiliki garis-garis bentuk "Tag: Nilai", orang dapat menentukan bahwa karakter pertama dari tag apa pun akan menunjukkan kategori di mana ia berada; untuk tag dari kategori abaikan-bisu, seseorang dapat memiliki karakter pertama juga menunjukkan versi standar yang tagnya diharapkan valid (sehingga jika tag "abaikan-abaikan" mengklaim ada di versi 3 dari standar, parser untuk versi akan diam-diam mengabaikannya, tetapi parser untuk versi 3 atau yang lebih baru akan mengomel jika tidak dapat menguraikannya).

Yang paling penting dalam setiap kasus adalah untuk menghindari konversi data yang ambigu atau disalahpahami menjadi data yang salah. Dalam beberapa kasus, mungkin lebih baik menolak untuk menyebarkan data yang ambigu sama sekali, meskipun dalam kasus lain mungkin lebih baik untuk menyebarkannya secara tepat seperti yang diterima jika penerima akan menganggapnya tidak ambigu. Apa yang benar-benar berbahaya jika tidak benar-benar jahat adalah konversi data menggunakan berbagai asumsi, misalnya mengonversi daftar tanggal seperti:

01/12/12
13/12/12
99/12/12

ke dalam daftar tanggal seperti

2012-01-12
2012-12-13
1999-12-12

Bahkan jika seseorang memiliki daftar dengan beberapa tanggal yang dimasukkan secara keliru, mungkin saja manusia diberi daftar dalam format asli untuk menentukan format mana yang benar, dan menandai nilai yang meragukan untuk penelitian lebih lanjut (memeriksa catatan lain, dll.) ) Namun, memberikan tanggal dalam format yang terakhir, akan sia-sia dan tidak dapat dipulihkan.


Kata baik. Saya suka bagaimana jawaban Anda sedikit lebih dalam. Saya tergoda untuk menerima ini, tetapi mengingat minat keseluruhan pertanyaan ini telah diterima, saya pikir saya akan meninggalkan ini sebentar.
Roman Starkov

1

Pengalaman UI saya sebagian besar berasal dari sistem desktop. Situs web berbeda, meskipun saya telah melihat beberapa situs yang dapat menantang sistem desktop. Tapi untuk apa nilainya:

Saya telah menemukan bahwa pesan kesalahan harus menjadi pilihan terakhir; sistem yang ideal tidak akan memilikinya sama sekali. Hal terbaik yang harus dilakukan adalah tidak mengizinkan entri yang buruk: pengguna tidak dapat memasukkan "hijau" jika dia memilih dari daftar dropdown bulan. Dia tidak bisa menekan tombol berwarna abu-abu.

Hal terbaik berikutnya yang harus dilakukan adalah menerima data yang buruk. Katakanlah Anda menampilkan histogram penjualan harian selama sebulan. Setelah input pengguna, grafik mencakup satu abad dan bilah satu abad keluar 10 kali lebih tinggi dari yang lain. Pengguna sekarang tahu dia melakukan sesuatu yang salah dan, lebih lanjut, tahu lebih banyak tentang apa yang dia lakukan salah daripada pesan apa pun yang bisa dia katakan. Ketika entri grafis - dengan menyeret mouse, misalnya - umpan balik semacam ini masih berfungsi dan tidak ternilai. Sejumlah input mungkin tidak valid, tetapi menggunakan metode ini pengguna mendapat umpan balik terperinci dan instan tentang hasil setiap posisi mouse.

Semua yang dikatakan, kadang-kadang pengguna perlu tahu mengapa tombolnya berwarna abu-abu sehingga dia tidak bisa menekannya. Maka tidak ada bantuan untuk itu (jika ada yang , beritahu saya) tetapi untuk ungray tombol dan, ketika ia mengklik itu, memberinya penjelasan yang baik mengapa tombol tidak bekerja saat ini.


0

Pernyataan tersebut adalah tentang mengirim informasi melalui internet. Salah satu hal dengan mengirimkan informasi melalui internet adalah bahwa hal itu tidak selalu akan mencapai target atau terfragmentasi.


0

Sesuatu yang sepertinya terlewatkan di sini - apa konsekuensi dari kegagalan?

Tampilkan halaman web? Anda harus melakukan semua yang Anda bisa untuk mentolerir masukan yang buruk. Pilihan Anda adalah menampilkan apa yang Anda bisa atau membuat kesalahan. Yang terakhir tentu saja tidak memberikan apa-apa kepada pengguna dan karenanya hanya akan menjadi pilihan terakhir karena memberikan hasil yang sama sekali tidak berguna bagi pengguna, itu akan sangat sulit untuk kesalahan lebih buruk dari ini.

Di sisi lain, jika meminta target Minuteman III, Anda menolak "Moskow" sebagai input karena berpotensi ambigu.


Jadi, bahkan jika Anda seorang programmer, dan Anda menulis beberapa kode bodoh, sistem harus terus maju dan melakukan yang terbaik untuk menunjukkan sesuatu, daripada hanya berhenti dan berteriak "oi, Anda mengacaukannya di sini (nomor baris)"? Tidakkah Anda pikir itu yang menyebabkan kode sangat buruk?
Roman Starkov

@romkyns: Anda memiliki mode debug untuk hal-hal yang ketat tentang kesalahan tentang kesalahan.
Loren Pechtel
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.