Anda mungkin bertanya -tanya apa yang dimaksud dengan judulnya. Kode adalah kode, benar? Penting untuk bebas bug dan itu, apa lagi? Pengembangan lebih dari menulis kode dan menguji/men -debug. Bayangkan Anda harus membaca karya orang lain, dan saya kira Anda sudah melakukannya, dan semua variabel bernama Foo, Bar, Baz, Var, dll. Dan kodenya tidak dikomentari atau didokumentasikan. Anda mungkin akan merasakan keinginan tiba -tiba untuk memohon dewa yang tidak dikenal, lalu pergi ke pub lokal dan menenggelamkan kesedihan Anda. Mereka mengatakan bahwa Anda tidak boleh melakukan kepada orang lain apa yang tidak ingin Anda lakukan kepada Anda, jadi bagian ini akan fokus dari pedoman pengkodean umum, ditambah ide-ide khusus GNU yang akan membantu Anda menerima kode Anda. Anda seharusnya telah membaca dan memahami bagian -bagian sebelumnya dari seri ini, serta menyelesaikan semua latihan dan, lebih disukai, membaca dan menulis sebanyak mungkin kode.

Rekomendasi

Sebelum memulai, harap perhatikan arti sebenarnya dari kata di atas. Saya tidak, dengan cara apa pun, ingin memberi tahu Anda cara menulis kode Anda, saya juga tidak menemukan rekomendasi ini. Ini adalah hasil dari pekerjaan bertahun -tahun oleh programmer yang berpengalaman, dan banyak yang tidak hanya berlaku untuk C, tetapi untuk bahasa lain, ditafsirkan atau dikompilasi.

Saya kira aturan pertama yang ingin saya stres adalah: Komentari kode Anda, lalu periksa apakah Anda cukup berkomentar, lalu komentar lagi. Ini tidak bermanfaat bagi orang lain yang akan membaca/menggunakan kode Anda, tetapi juga untuk Anda. Yakinlah bahwa Anda tidak akan ingat apa yang sebenarnya ingin Anda tulis setelah dua atau tiga bulan, Anda juga tidak akan tahu apa int ghrqa34; seharusnya berarti, jika ada. Pengembang yang baik mengomentari (hampir) setiap baris kode mereka secepat mungkin, dan imbalannya lebih dari yang mungkin Anda sadari pada awalnya, meskipun waktu yang dibutuhkan untuk menulis program. Keuntungan lain adalah bahwa dengan berkomentar, karena ini adalah bagaimana otak kita bekerja, apa pun yang ingin kita lakukan akan lebih diingat, jadi sekali lagi Anda tidak akan melihat kode Anda, maju cepat beberapa bulan, bertanya-tanya siapa yang menulis kode Anda. Atau mengapa.

Parser C tidak terlalu peduli bagaimana memesan kode Anda. Itu berarti Anda dapat menulis program "halo, dunia" yang khas seperti ini, dan itu akan tetap menyusun:

#include int main () printf ("halo, dunia!"); return 0; 

Tampaknya jauh lebih mudah dibaca cara kita menulisnya pertama kali, bukan? Aturan umum mengenai pemformatan adalah: satu instruksi per baris, pilih lebar tab Anda dan konsisten dengan itu, tetapi pastikan bahwa itu sesuai dengan pedoman proyek, jika Anda sedang mengerjakannya, juga memanfaatkan garis kosong secara liberal, untuk Membatasi berbagai bagian program, bersama dengan komentar, dan akhirnya, meskipun ini belum tentu mengkodekan gaya terkait, sebelum Anda mulai mengkode dengan serius, temukan editor yang Anda sukai dan belajar menggunakannya dengan baik. Kami akan segera menerbitkan artikel tentang editor, tetapi sampai saat itu Google akan membantu Anda dengan beberapa alternatif. Jika Anda mendengar orang di forum, milis, dll. Mengatakan “Editor X Sucks, Editor Y FTW!", abaikan mereka. Ini adalah masalah yang sangat subyektif dan apa yang baik bagi saya mungkin tidak begitu baik untuk Anda, jadi setidaknya cobalah beberapa editor yang tersedia untuk Linux untuk beberapa hari masing -masing bahkan sebelum mulai mencoba membuat beberapa pendapat.

Konsisten dalam penamaan variabel. Pastikan juga namanya cocok dengan yang lain, jadi ada harmoni dalam seluruh program. Ini berlaku bahkan jika Anda satu -satunya penulis perangkat lunak, akan lebih mudah untuk dipertahankan nanti. Buat daftar awalan dan sufiks bekas (e.G. Max, Min, Get, Set, IS, CNT) dan pergi bersama mereka, kecuali ditanya sebaliknya. Konsistensi adalah kata kunci di sini.

Pedoman khusus GNU

Berikut ini adalah ringkasan dari standar pengkodean GNU, karena kami tahu Anda tidak suka membaca hal -hal seperti itu. Jadi jika Anda menulis kode yang ingin masuk ke dalam ekosistem GNU, ini adalah dokumen yang harus dibaca. Bahkan jika Anda tidak melakukannya, itu masih merupakan bacaan yang bagus tentang cara menulis kode yang tepat.

Dokumen ini selalu layak dibaca secara keseluruhan jika Anda membuat atau memelihara perangkat lunak GNU, tetapi Anda akan menemukan bagian terpenting di bawah ini. Satu masalah pertama yang layak disebutkan adalah bagaimana menangani prototipe fungsi. Harap kembali ke bagian yang berurusan dengan itu jika Anda memiliki masalah. Idenya adalah “Jika Anda memiliki fungsi sendiri, gunakan deklarasi prototipe sebelum main (), maka tentukan fungsi saat dibutuhkan.“Inilah contohnya:

#include int func (int, int) int main () […] int func (int x, int z) […] 

Gunakan lekukan yang tepat dan konstan. Ini tidak bisa cukup ditekankan. Programmer berpengalaman dengan kode bertahun -tahun di belakang akan sangat buruk saat Anda mengirimkan kode dengan lekukan yang tidak tepat. Dalam kasus kami, cara terbaik untuk terbiasa dengan bagaimana GNU melakukannya adalah dengan menggunakan GNU Emacs (meskipun ini tidak dalam bentuk apa pun cara kami untuk memberi tahu Anda bahwa “GNU Emacs baik untuk Anda, gunakan itu.”, Karena kami pendukung kehendak bebas dan pilihan), di mana perilaku default untuk kode C adalah indentasi ditetapkan pada dua ruang dan kawat gigi pada garis untuk diri mereka sendiri. Yang membawa kita ke masalah penting lainnya. Beberapa orang menggunakan kawat gigi seperti ini:

ketika (var == 1) code… 

… Sementara yang lain, termasuk orang GNU, lakukan seperti ini:

ketika (var == 1) code…

Tentu saja, ini juga berlaku untuk ekspresi bersyarat, fungsi dan setiap kesempatan di mana Anda perlu menggunakan kawat gigi dalam kode C. Sejauh yang diperhatikan, pilihan ini adalah sesuatu yang sangat spesifik GNU, dan seberapa banyak dari ini yang Anda hormati hanya tergantung pada selera dan sikap Anda tentang masalah ini.

Masalah kami berikutnya adalah masalah teknis, dan janji yang harus saya pertahankan: masalah malloc (). Selain menulis pesan kesalahan yang relevan dan bermakna, tidak seperti yang kita semua pernah lihat di sistem operasi lain, periksa apakah malloc () dan teman selalu mengembalikan nol. Ini adalah masalah yang sangat serius, dan Anda akan mendapatkan beberapa kata pelajaran tentang malloc () dan kapan menggunakannya. Sekarang Anda tahu apa yang mengalokasikan memori secara otomatis atau statis. Tapi metode ini tidak mencakup semua pangkalan. Ketika Anda perlu mengalokasikan memori dan memiliki lebih banyak kontrol atas operasi, ada malloc () dan teman, untuk alokasi dinamis. Tujuannya adalah untuk mengalokasikan memori yang tersedia dari tumpukan, Kemudian program menggunakan memori melalui pointer yang dikembalikan malloc (), lalu memori harus gratis () D. Dan "harus" ditulis dengan ibukota dalam huruf 2 kaki dengan warna merah yang terbakar. Itu saja dengan malloc (), dan alasannya telah diekspos sebelumnya di bagian sebelumnya.

Anda didesak untuk menggunakan antarmuka yang konsisten di semua program baris perintah Anda. Jika Anda sudah menjadi pengguna GNU/Linux yang berpengalaman, Anda telah memperhatikan bahwa hampir semua program memiliki -versi dan -Help, plus, misalnya, -v untuk verbose, jika demikian halnya. Kami tidak akan membahas semua itu di sini; ambil salinan standar pengkodean GNU, Anda akan membutuhkannya.

Meskipun saya pribadi cenderung mengabaikan ini, dan bagi banyak orang itu adalah masalah kecil, itu akan meningkatkan keterbacaan kode Anda, karena, sekali lagi, begitulah cara otak kita bekerja. Idenya adalah: ketika Anda ragu menggunakan spasi, gunakan. Misalnya:

int func (var1, var2); int func (var1, var2);

Ada beberapa yang mengatakan Anda tidak dapat menghindari ifs bersarang. Ada orang lain yang mengatakan “mengapa menghindari ifs bersarang?”Dan ada orang lain yang tidak menggunakan IFS bersarang. Anda akan membuat pendapat Anda sendiri tentang ini seiring berjalannya waktu dan baris kode yang Anda tulis. Idenya adalah, jika Anda menggunakannya, menjadikannya semaksimal mungkin, karena mereka dengan mudah dapat mengarah pada kode yang hampir spageti, sulit dibaca dan mempertahankan. Dan lagi, gunakan komentar.

Standar pengkodean GNU mengatakan bahwa ada baik untuk membuat kode Anda portabel, "tapi tidak terpenting". Perangkat keras portabel? Itu tergantung pada tujuan program dan mesin apa yang Anda miliki. Kami lebih merujuk pada sisi perangkat lunak, yaitu portabilitas antara sistem UNIX, open source atau tidak. Hindari IFDEFS jika Anda bisa, hindari asumsi tentang lokasi file (e.G. Solaris menginstal perangkat lunak pihak ketiga di bawah /opt, sedangkan BSD dan GNU /Linux tidak), dan umumnya bertujuan untuk kode bersih. Berbicara tentang asumsi, bahkan jangan berasumsi bahwa byte adalah delapan bit atau bahwa ruang alamat CPU harus menjadi angka genap.

Mendokumentasikan kode Anda, dalam bentuk halaman manual dan readmes yang ditulis dengan baik dan sebagainya, adalah aspek terpenting dari pengembangan perangkat lunak. Ya, itu adalah tugas yang membosankan, tetapi jika Anda tidak memiliki penulis dokumentasi di tim Anda, itu adalah tanggung jawab Anda untuk melakukannya, karena setiap programmer yang baik melakukan pekerjaannya dari A ke Z.

Kesimpulan

Lain kali kita akan melanjutkan dari tempat kita tinggalkan di sini: pergi dari ide ke program yang lengkap, dengan makefile, dokumentasi, siklus rilis dan semua hal menyenangkan. Satu -satunya latihan yang saya miliki untuk Anda adalah membaca standar pengkodean GNU dan memodifikasi kode Anda untuk menyesuaikan. Dan bersiaplah, lain kali adalah waktu yang menyenangkan!

Inilah yang dapat Anda harapkan selanjutnya:

• SAYA. C Perkembangan di Linux - Pendahuluan
• Ii. Perbandingan antara C dan bahasa pemrograman lainnya
• AKU AKU AKU. Jenis, Operator, Variabel
• Iv. Alur kontrol
• V. Fungsi
• Vi. Pointer dan Array
• Vii. Struktur
• Viii. I/O Dasar
• Ix. Gaya pengkodean dan rekomendasi
• X. Membangun program
• Xi. Kemasan untuk Debian dan Fedora
• Xii. Mendapatkan paket di repositori resmi Debian

Tutorial Linux Terkait:

• Tutorial debugging GDB untuk pemula
• Instal Arch Linux di VMware Workstation
• Pengantar Otomatisasi Linux, Alat dan Teknik
• Hal -hal yang harus diinstal pada ubuntu 20.04
• Ekspresi reguler Python dengan contoh
• Cara Membangun Aplikasi Tkinter Menggunakan Objek Berorientasi…
• Lanjutan regex bash canggih dengan contoh
• Loop bash dengan contoh
• Hal -hal yang harus dilakukan setelah menginstal ubuntu 20.04 FOSSA FOSSA Linux
• Loop bersarang dalam skrip bash