Bagaimana cara menangani fungsi yang salah nama dalam kode produksi?


28

Saya baru saja menemukan perpustakaan Python di GitHub. Pustaka hebat, tetapi berisi satu kesalahan ketik mencolok dalam nama fungsi. Sebut saja dummy_fuction()selagi seharusnya dummy_function(). Fungsi ini pasti "di alam liar" dan kemungkinan besar digunakan dalam sistem embedded.

Hal pertama yang muncul dalam pikiran adalah menambahkan versi kedua dari fungsi dengan nama yang benar dan menambahkan peringatan penghentian ke versi pertama untuk rilis berikutnya.

Tiga pertanyaan:

  1. Bisakah pendekatan di atas memiliki konsekuensi yang tidak diinginkan?
  2. Apakah ada pendekatan standar untuk masalah seperti ini?
  3. Berapa lama peringatan pelecehan ditinggalkan?

1
Ini adalah situasi (meskipun bukan yang sangat sering) di mana bahasa statis jauh lebih kuat daripada yang dinamis: kompilator dapat memeriksa apakah fungsi yang diubah namanya sudah ada.
Giorgio

7
lihat juga HTTP referer [sic]
AakashM

2
Saya juga akan menunjukkan mod_speling Apache , tapi itu mungkin disengaja.
Pasang kembali Monica iamnotmaynard

1
@AakashM: Saya suka artikel Wikipedia sekarang menggunakan ejaan yang salah dan benar di seluruh halaman itu (bahkan ketika merujuk ke objek, bukan istilah), dengan versi yang salah eja lebih umum!
Martijn Pieters

Sedikit hal baik lainnya tentang http_referer- "Seperti ketika saya mengerjakan bidang referensi. Saya tidak punya apa-apa selain kesedihan karena pilihan pengejaan saya. Saya sekarang sedang mencoba untuk memperbaiki pengejaan dalam OED karena ejaan saya digunakan beberapa miliar kali dalam satu menit lebih banyak dari milik mereka. " - Phillip Hallam-Baker
Jamie Bull

Jawaban:


29

Pertama dan terpenting, kebijakan tergantung pada pengelola.

Saya pikir pertanyaan Anda menarik, tetapi sebagian besar berdasarkan pendapat.

Menurut pendapat pribadi saya, pendekatan Anda bagus - ubah nama fungsinya dan biarkan versi yang salah eja sebagai artefak yang sudah usang, arahkan ke yang benar.

Bisakah pendekatan di atas memiliki konsekuensi yang tidak diinginkan?

Itu bisa memecahkan kode misalnya. jika seseorang tidak tahan terhadap kesalahan ejaan dan menerapkan versi yang diubah namanya sendiri. Sekarang akan ada bentrokan nama setelah mereka memperbarui perpustakaan.

Apakah ada pendekatan standar untuk masalah seperti ini?

Jangan membuat kesalahan pengejaan saat menulis perpustakaan;)

Berapa lama peringatan pelecehan ditinggalkan?

Saya percaya penghentian itu harus dibiarkan di tempat sampai rilis utama berikutnya (ketika digit pertama dalam nomor versi meningkat).

Inilah saat beberapa - kompatibilitas dibelokkan melanggar dapat ditoleransi, dan terserah pengguna perpustakaan untuk memastikan kode mereka masih membangun dengan baik.

Pastikan untuk menunjukkannya di changelog: kawan, jika Anda menggunakannya dummy_fuction, gantikan dengan dummy_functionmana - mana dan Anda siap melakukannya.

Jika pustaka tidak berversi, mungkin - itu merupakan kasus yang baik untuk mulai memversi versi itu.


1
Senang mendengarnya. Pustaka diversi sehingga pendekatan ke kontrol versi terdengar bagus. Ini sebenarnya memiliki IDE sendiri sehingga versi yang salah eja dapat disembunyikan dari alat penyelesaian kode yang harus menghentikan pengguna baru menggunakannya. Jika saya bisa memberi Anda +1 lagi untuk jawaban ke Q2 saya akan!
Jamie Bull

2
Ini adalah pendekatan yang saya lihat di perangkat lunak lain juga. Saya menggunakan API pihak ke-3 untuk perangkat lunak yang saya kembangkan, dan API mereka berisi metode pengambil yang berisi kesalahan ketik. Masalah telah diperbaiki dengan mengganti nama metode, dan membuat metode dummy dengan ejaan lama (salah) yang hanya memanggil versi yang benar. Metode dummy tidak mengandung dokumentasi selain menyebutkan itu sudah usang dan tautan ke versi yang benar. Metode itu telah ada di sana selama bertahun - tahun sekarang, untuk menghindari kerusakan kompatibilitas ke belakang.
Karl Nicoll
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.