Pemrogram pemula frustasi karena kurangnya glosarium kesalahan penyusun

Seorang teman keluarga saya meminta sedikit bantuan saat dia belajar memprogram (dalam bahasa C). Ketika kami berbicara, dia menyatakan frustrasi tentang kesulitan memahami pesan kesalahan yang diberikan oleh kompilernya (GCC) ketika dia membuat kesalahan. Dia tidak mengerti semua istilah yang digunakan, dan kadang-kadang kombinasi mereka yang di luar pemahamannya. Dia bertanya kepada saya, "Kenapa dokumentasi kompiler tidak menyertakan penjelasan lebih panjang dari pesan kesalahan?" - dan saya tidak punya jawaban yang bagus untuknya.

Saya sendiri - sebagai programmer yang lebih berpengalaman - sangat jarang dalam situasi ini, tetapi kejadian langka itu terjadi - beberapa pesan kesalahan eksotis yang belum pernah saya temui sebelumnya. Saya berhasil bertahan dengan mencari pesan kesalahan di mesin pencari, tetapi ternyata itu tidak selalu berhasil untuknya - terutama karena kesalahan yang ia temui lebih umum dan terjadi dalam beberapa kasus berbeda, yang ia mengalami kesulitan terkait dengan pesannya. sendiri.

Jadi, bagaimana seharusnya seorang programmer pemula mendekati tantangan memahami pesan kesalahan kompiler? Secara khusus, dengan kombinasi C dan GCC?

Beberapa teknik yang bermanfaat:

• Nyalakan -Walldan -Werror. Ini mungkin tampak berlawanan dengan intuisi ketika Anda berjuang dengan menguraikan pesan kesalahan untuk membuat lebih banyak pesan kesalahan, tetapi peringatan biasanya lebih mudah dipahami dan lebih dekat ke sumber masalah yang sebenarnya, dan mengabaikannya dapat menyebabkan kesalahan yang sulit dipahami .
• Coba perbaiki kesalahan pertama dalam daftar. Seringkali kesalahan bertambah satu sama lain, yang menyebabkan pesan kesalahan di kemudian hari tidak benar-benar menjadi kesalahan aktual. Perbaiki satu dan kompilasi ulang. Anda akan menjadi lebih baik dalam memperbaiki beberapa pesan kesalahan saat Anda mendapatkan lebih banyak pengalaman.
• Gunakan versi kompiler terbaru mungkin. C adalah bahasa yang sangat stabil. Oleh karena itu, sebagian besar peningkatan pada kompiler yang lebih baru bukan untuk menambahkan fitur bahasa, tetapi untuk meningkatkan pengalaman pengembang, termasuk pesan kesalahan yang lebih baik. Banyak distribusi linux yang digunakan secara luas memiliki versi gcc yang sangat lama secara default.
• Program secara bertahap. Jangan mencoba menulis banyak kode sebelum kompilasi. Tulis jumlah sesingkat mungkin yang masih akan dikompilasi. Jika Anda hanya mengubah satu baris sejak terakhir kali dikompilasi dengan bersih, jauh lebih mudah untuk mengetahui baris mana yang berisi masalah aktual.
• Tulis tes unit. Itu membuat Anda lebih percaya diri untuk melakukan klarifikasi perubahan refactoring ketika memperbaiki kesalahan kompilasi.

Teman Anda tidak perlu glosarium. Glosarium tidak akan membantunya. Yang dia butuhkan adalah intuisi yang lebih baik tentang apa yang harus dilakukan ketika kesalahan kompiler terjadi.

Kesalahan kompiler C tidak seintuitif, katakanlah, kesalahan penyusun C #, karena banyak alasan sebagian besar berkaitan dengan sifat "dekat dengan logam" dari C. Memecahkan kesalahan kompiler dalam C bukanlah latihan pencocokan pola, karena kesalahan yang Anda lakukan terima mungkin tidak ada hubungannya dengan masalah aktual. Tidak seperti C # atau Java, di mana pesan kesalahan biasanya memetakan ke lokasi kode yang tepat dan masalah, kesalahan dalam C cenderung banyak dan jauh.

Contohnya adalah "titik koma yang diharapkan" atau sejumlah kesalahan sintaks yang mengindikasikan parser yang terpaku pada sesuatu (belum tentu titik koma). Atau sesuatu seperti "deklarasi maju tak terduga," kesalahan yang, ketika saya melihatnya, selalu berarti bahwa saya salah kapitalisasi pada salah satu file .h saya, tetapi yang tidak menunjuk ke file .h sebagai sumber masalah.

Strategi teman Anda seharusnya bukan untuk mencocokkan pola ini dengan daftar kesalahan dan solusi; seharusnya memahami sintaks dan spesifikasi bahasa C dengan cukup baik untuk mencari tahu apa masalah sebenarnya .

Teknik yang relevan yang layak disebutkan adalah menggunakan kompiler kedua. Dentang telah berinvestasi dalam pesan kesalahan yang lebih baik, misalnya, tetapi cara alternatif untuk mengungkapkan kesalahan bisa mencerahkan.

Ini terutama terjadi untuk jenis kesalahan yang paling kompleks. Misalnya, ketika Anda mencampur dua konstruksi yang sama (tidak biasa untuk pemula), kompiler biasanya memiliki masalah dalam menghasilkan pesan kesalahan yang tepat. Ini dapat menyebabkan kebingungan ketika kompilator memberikan pesan kesalahan tentang penggunaan yang salah dari konstruk A ketika Anda benar-benar bermaksud membangun B. Kompiler kedua mungkin menyimpulkan bahwa yang Anda maksudkan B.

Seseorang mencoba glosarium kesalahan GCC di Wikibooks beberapa waktu lalu, tetapi sepertinya tidak pernah benar-benar lepas landas dan belum diperbarui.

Bagian "Kesalahan" jauh lebih jauh daripada bagian "Peringatan". Sepertinya itu ditujukan untuk G ++, tetapi masih ada kemungkinan beberapa informasi berguna untuk teman Anda di sana.

Selain jawaban di atas, perhatikan bahwa sebagian besar kompiler tidak memiliki daftar kesalahan yang komprehensif - ini akan banyak pekerjaan untuk mempertahankan karena pesan-pesan itu sendiri sering berubah, dan ada cukup banyak dari mereka.

Pengganti glosari terbaik adalah akses ke internet. Setiap kali kompiler menghasilkan kesalahan yang tidak Anda mengerti, merasa nyaman karena sangat kecil kemungkinan Anda yang pertama kali menjumpainya dan bingung. Google cepat dari pesan yang tepat sering cukup untuk memberi Anda banyak informasi dalam format yang mudah dibaca, sering dengan kode contoh sangat mirip dengan Anda.

Lebih dari itu, waktu dan keakraban dengan bahasa dan kompiler adalah semua yang Anda butuhkan. Itu, dan saran bagus yang diberikan oleh Karl Bielefeldt .

Standar C menggunakan sejumlah istilah seperti "nilai" dan "objek" dengan cara yang berbeda dari bahasa pemrograman lain, dan pesan penyusun sering ditulis dalam istilah tersebut. Penggunaan terminologi tidak konsisten di beberapa bagian Standar, tetapi siapa pun yang ingin belajar C harus melihat draft standar C89, C99, dan / atau C11 serta dokumen rasional untuk mereka. Mencari mis. "C99 draft" atau "C89 rationale" harus bekerja dengan baik, meskipun Anda mungkin perlu memastikan Anda mendapatkan dokumen yang Anda harapkan. Meskipun sebagian besar penyusun mendukung Standar C99, mungkin berguna untuk mengetahui perbedaannya dari Standar C89, dan dasar pemikiran C89 mungkin menawarkan beberapa latar belakang historis yang tidak dimiliki oleh versi yang lebih baru.

Saya terkejut tidak ada yang memberikan jawaban yang jelas dan, saya curiga, yang paling sering digunakan dalam praktik: hanya saja tidak membaca pesan kesalahan.

Sebagian besar nilai dari sebagian besar pesan kesalahan hanyalah bahwa ada sesuatu yang salah pada baris ini dan itu. Sebagian besar waktu saya hanya melihat nomor baris dan pergi ke baris itu. "Pembacaan" saya tentang pesan kesalahan pada titik itu biasanya hanya apa pun yang menarik perhatian saya, bahkan bukan skim. Jika tidak segera jelas apa yang salah pada atau dekat garis, maka saya akan benar-benar membaca pesannya. Alur kerja ini bahkan lebih baik dengan IDE atau alat yang menyoroti kesalahan di tempat, dan secara otomatis menyelesaikan saran Karl Bielefeldt untuk hanya mempertimbangkan perubahan kecil.

Tentu saja, pesan kesalahan tidak selalu mengarah pada baris yang sesuai, tetapi kemudian mereka juga sering tidak menunjuk ke akar penyebab yang tepat, sehingga bahkan pemahaman penuh tentang pesan kesalahan akan sangat membantu. Tidak butuh waktu lama untuk mendapatkan gagasan tentang pesan kesalahan apa yang lebih dapat diandalkan untuk menemukan garis yang tepat.

Di satu sisi, sebagian besar kesalahan yang mungkin dilakukan oleh seorang pemula cenderung sangat jelas bagi seorang programmer berpengalaman tanpa bantuan dari kompiler yang diperlukan. Di sisi lain, mereka jauh lebih kecil kemungkinannya begitu jelas bagi pemula (meskipun banyak yang akan jelas, kebanyakan kesalahan adalah kesalahan bodoh). Pada titik ini saya sepenuhnya setuju dengan Robert Harvey, pemula hanya perlu menjadi lebih akrab dengan bahasa. Tidak ada cara untuk menghindarinya. Kesalahan penyusun yang merujuk konsep asing atau tampak mengejutkan harus dilihat sebagai petunjuk untuk memperdalam pengetahuan bahasa tersebut. Demikian pula untuk kasus di mana kompiler mengeluh tetapi Anda tidak dapat melihat mengapa kode salah.

Sekali lagi, saya setuju dengan Robert Harvey bahwa strategi yang lebih baik untuk memanfaatkan kesalahan kompiler diperlukan. Saya telah menguraikan beberapa aspek di atas dan jawaban Robert Harvey memberi aspek lain. Bahkan tidak jelas apa yang diharapkan teman Anda untuk dilakukan dengan "glosarium" seperti itu, dan sangat tidak mungkin "glosarium" semacam itu akan sangat berguna bagi teman Anda. Pesan kompiler tentu bukan tempat untuk pengantar konsep bahasa ¹ dan "glosarium" bukanlah tempat yang lebih baik untuk itu. Bahkan dengan deskripsi yang jelas tentang apa arti pesan kesalahan, itu tidak akan memberi tahu Anda cara memperbaiki masalah.

¹ Beberapa bahasa, seperti Elm dan Dhall (dan mungkin Racket), serta beberapa implementasi bahasa "berorientasi pemula" berusaha melakukan hal ini. Dalam nada ini, saran MSalters untuk menggunakan implementasi yang berbeda relevan secara langsung. Saya pribadi menemukan hal-hal semacam itu tidak menarik dan tidak cukup ditujukan pada masalah yang tepat. Ini bukan untuk mengatakan bahwa tidak ada cara untuk membuat pesan kesalahan yang lebih baik, tetapi, bagi saya, mereka cenderung berputar membuat kepercayaan kompiler dan dasar dari kepercayaan itu menjadi lebih jelas.

Jadi, bagaimana seharusnya seorang programmer pemula mendekati tantangan memahami pesan kesalahan kompiler? Secara khusus, dengan kombinasi C dan GCC?

Beri tahu teman Anda untuk melakukan hal berikut saat menemukan kesalahan yang tidak mereka pahami:

• Hapus / komentar kode yang ditambahkan sejak build terakhir yang berhasil.
• Pasang kembali sebagian kecil dan kompilasi
• Ulangi sampai kesalahan terjadi

Kesalahan kompiler hanya memberi tahu Anda apa yang tidak dipahami oleh kompiler tentang kode Anda, bukan apa yang salah dengannya. Pendekatan ini membutuhkan waktu yang kira-kira sama dengan Googling kesalahan dan membaca beberapa dokumen atau posting StackOverflow, tetapi memberikan pemahaman yang jauh lebih baik tentang apa yang Anda lakukan salah.

Juga buat mereka sering dikompilasi sampai mereka mulai mengerjakan proyek yang membutuhkan waktu beberapa menit untuk membangun, menemukan kesalahan sebelum menambahkan terlalu banyak kode lain banyak membantu.

Akhirnya, suruh mereka untuk mengerjakan satu hal pada satu waktu, jangan bekerja di banyak file tanpa kompilasi di antaranya, jangan memperkenalkan beberapa dependensi sekaligus, dll.

Teknik lain adalah agar teman itu menulis glosariumnya sendiri dari waktu ke waktu ketika dia menemukan pesan kesalahan yang berbeda. Seringkali cara terbaik untuk mempelajari sesuatu adalah dengan mengajarkannya. Tentu saja, pada saat glosarium selesai, dia mungkin tidak akan membutuhkannya lagi.

Pengalaman pribadi saya dengan GCC adalah bahwa setiap pesan kesalahan berhubungan dengan serangkaian kesalahan "biasa". Misalnya, ketika GCC mengatakan "apakah Anda lupa &" itu biasanya berarti saya lupa tanda kurung. Tentu saja, kesalahan mana yang sesuai dengan pesan kesalahan mana yang akan tergantung pada programmer, alasan lain yang baik bagi teman tersebut untuk menulis glosariumnya sendiri.