Peringatan Kompiler

Banyak kompiler memiliki pesan peringatan untuk memperingatkan programmer tentang kemungkinan runtime, logika dan kesalahan kinerja, seringkali, Anda dengan cepat memperbaikinya, tetapi bagaimana dengan peringatan yang tidak dapat diperbaiki?

Bagaimana Anda menangani peringatan yang tidak bisa diperbaiki? Apakah Anda menulis ulang sebagian kode, atau menulis ulang dengan "panjang, tanpa hack" atau menonaktifkan peringatan secara bersamaan? Apa yang seharusnya menjadi praktik terbaik?

Bagaimana jika Anda mengedit kode orang lain dan kode itu memiliki peringatan?

Ini adalah contoh yang bagus: jQuery memiliki banyak peringatan JavaScript ketika browser kelas Mozilla terdeteksi, mengapa pengembang jQ tidak memperbaikinya? Jika Anda berkontribusi ke jQuery, apakah Anda akan memperbaikinya?

Beberapa peringatan biasanya aman untuk diabaikan tetapi jika Anda melakukannya maka seiring waktu mereka akan berlipat ganda sampai hari itu tiba ketika ada begitu banyak sehingga Anda kehilangan satu peringatan yang sangat penting karena tersembunyi dalam kebisingan.

Perbaiki peringatan segera (yang mungkin termasuk menonaktifkan aturan individu jika Anda merasa itu tidak pernah relevan untuk konteks Anda).

Pendapat saya adalah Anda harus tegas pada diri sendiri. Kompiler telah ditulis oleh ahli total dalam bahasa. Jika mereka melaporkan bahwa ada sesuatu yang agak aneh (pikirkan kode bau) maka kode tersebut harus ditinjau.

Sangat mungkin untuk menulis kode yang mengkompilasi tanpa kesalahan dan tanpa peringatan.

Ketika saya menulis dalam C dan C ++ saya akan mengaktifkan pengaturan ketat yang saya bisa karena saya ingin tahu ketika ada sesuatu yang tidak masuk akal untuk kompiler. Ketika saya selesai casting dan memeriksa nilai-nilai kembali saya akan senang karena kode itu benar karena saya bisa membuatnya.

Saya sesekali mendapatkan kode dari orang lain yang akan memuntahkan peringatan. Memeriksa sumber menunjukkan mereka mengabaikan hal-hal yang merupakan praktik pemrograman yang baik dalam C, membuat kode mereka rapuh.

Jadi, saya pikir ada alasan bagus untuk memungkinkan keketatan dan meluangkan waktu untuk memperbaiki keadaan. Melakukan sebaliknya adalah ceroboh. Jika saya memiliki rekan kerja yang mematikan peringatan saya akan menghabiskan waktu bersama mereka DAN manajer menjelaskan mengapa itu adalah hal yang sangat buruk.

Saya akan memperbaiki peringatan apa pun. Jika Anda mengabaikannya dan membiarkannya menumpuk, Anda mungkin benar-benar melewatkan sesuatu yang penting.

Secara umum Anda harus berusaha membuat kompiler diam, sehingga peringatan baru lebih banyak ditampilkan. Peringatan ini dapat menunjukkan bug halus dan harus ditangani dengan tepat.

Mengenai memperbaiki kode orang lain, itu sangat tergantung pada budaya tempat kerja Anda dan kondisi kode saat ini. Anda tidak bisa begitu saja mengubah kode jika memicu siklus pengujian ulang lengkap, seperti itu akan terjadi pada kode pada tahap akhir pengujian atau dalam produksi.

Tanyakan kepada atasan Anda, dan lakukan tindakan yang sesuai.

Setiap kali Anda melihat peringatan kompiler, Anda harus berhenti dan memikirkan apakah itu benar-benar masalah menunggu untuk meledak di wajah Anda di situs pelanggan, atau sesuatu yang dapat Anda abaikan. Lebih buruk lagi, hal-hal yang dapat Anda abaikan HARI INI mungkin adalah hal-hal yang akan meledak di situs pelanggan dalam beberapa tahun, setelah perubahan kode yang tampaknya tidak berhubungan dengan Somewhere Else.

Perbaiki peringatan. Titik. Itu adalah dokumen atau mendokumentasikan setiap satu dari mereka, dengan halaman penjelasan sebanyak yang diperlukan untuk membuktikan itu bukan risiko, disertai dengan pesanan penjualan yang ditandatangani pada pacar favorit Anda (atau simpanan porno) jika ternyata itu ADA risiko.

Secara umum, Anda ingin bangunan Anda bebas peringatan. Peringatan ada karena suatu alasan, dan seringkali mereka menunjukkan masalah yang sangat nyata. Jika Anda terbiasa mengabaikan peringatan kompiler, maka akhirnya bangunan Anda akan memiliki satu ton, dan Anda akan kehilangan satu peringatan yang disebabkan oleh masalah bencana yang akan sangat merugikan perusahaan Anda. Di sisi lain, jika program Anda biasanya mengkompilasi tanpa peringatan, maka setiap peringatan baru segera diperhatikan, dan dapat dengan cepat ditangani.

Karena itu, kadang-kadang kompiler dapat memiliki peringatan yang tidak masuk akal dan yang tidak dapat dengan mudah diperbaiki. Saya menghadapi situasi ini setiap hari di tempat kerja dengan TI CodeComposer, yang merupakan lingkungan pengembangan untuk DSP TI. Saya memiliki kode C ++ yang mengkompilasi tanpa peringatan di bawah Visual Studio, tetapi yang menghasilkan peringatan aneh di CodeComposer, hanya karena dukungan TI untuk standar C ++ bisa lebih baik. Untungnya, CodeComposer memungkinkan Anda menonaktifkan peringatan spesifik satu per satu, yang harus kita lakukan ketika tidak ada cara untuk memperbaiki kode yang menghasilkan peringatan.

Dalam kasus saya, peringatan datang dari alat PyLint dan saya dapat menonaktifkan peringatan pada baris tertentu dengan menambahkan teks khusus di komentar.

Dalam kebanyakan kasus, saya tidak melakukan itu. Dalam kebanyakan kasus, saya mengubah kode untuk mengikuti apa yang disarankan PyLint karena PyLint biasanya benar. Namun, dalam konstruksi tidak suka yang umumnya merupakan ide yang buruk, tetapi yang masuk akal dalam konteks tertentu. Misalnya, mengeluh jika saya menangkap semua kemungkinan pengecualian. Biasanya, itu benar, itu ide yang buruk. Namun, dalam beberapa kasus saya ingin menangkap semua pengecualian seperti mengirim sendiri laporan kesalahan dengan detailnya.

Jadi: Di ​​hampir semua kasus, singkirkan peretasan. Ketika peretasan benar-benar dibenarkan, tambahkan komentar yang mengatakan PyLint tidak apa-apa.

Beberapa manfaat dari ketegaran tidak secara jelas dinyatakan dalam jawaban lain:

1. Ketika semua peringatan yang mudah diperbaiki telah diperbaiki, sisa peringatan signifikan / relevan lebih mungkin muncul.
2. Jika peringatan yang relevan ditemukan dan ditangani tepat waktu (sebelum rilis), bug dapat dihindari, sehingga mengarah pada kepuasan pengguna akhir yang lebih baik
3. Memecahkan peringatan biasanya mengarah pada kode yang lebih mudah dikelola dan sederhana (mis. Menghilangkan kondisi yang selalu benar)
4. Ketika jumlah peringatan mendekati 0, mudah untuk menyetujui Kebijakan Peringatan Nol di tim, yang sangat mudah untuk diotomatisasi dalam sistem CI.
5. Saat memecahkan peringatan kompiler, pemahaman kode program diperdalam, yang dapat mengarah pada wawasan berguna tentang implementasi (misalnya menemukan bug lain atau mendapatkan ide bagaimana mengembangkan kode lebih lanjut)
6. Build semakin cepat, produktivitas harian naik: IDE / kompiler memiliki lebih sedikit masalah untuk dikelola dan dilaporkan, sehingga kompilasi lebih cepat (ini hanya relevan dalam konteks ribuan peringatan).

Ada perbedaan spesifik bahasa pada jenis peringatan tertentu. Saya pikir penting untuk berpikir dan berdiskusi tentang topik dan kemudian menonaktifkan beberapa peringatan individu jika mereka merasa sama sekali tidak berguna sehingga keketatan dapat dicapai. Ini telah dicapai dalam beberapa tim dalam karir saya. Lebih banyak tentang pengalaman saya pada topik

Peringatan dan kesalahan adalah pesan yang digunakan kompiler untuk memberi tahu programmer "sesuatu yang Anda tulis tidak masuk akal" - perbedaan di antara mereka adalah bahwa dengan peringatan, kompiler bersedia untuk menebak maksud niat programmer, sedangkan dengan kesalahan, kompilator bahkan tidak bisa menebak.

Kesalahan kompiler akan ditangani (saya tidak akan mengatakan diperbaiki ), tetapi terlalu sering, programmer (bahkan yang berpengalaman) akan mengabaikan peringatan. Masalah dengan mengabaikan peringatan adalah bahwa kadang-kadang kompiler menebak salah dan jika Anda punya 1000+ pesan peringatan, mudah untuk melewatkan pesan peringatan yang menunjukkan bahwa kompiler menebak salah.

Dari sudut pandang sosiologis, program yang memiliki banyak pesan peringatan adalah Windows Rusak .