Anda mungkin tertanya -tanya apa yang dimaksudkan dengan tajuk. Kod adalah kod, betul? Penting untuk menjadi bug-free dan itu sahaja, apa lagi? Pembangunan lebih daripada menulis kod dan menguji/menyahpepijatnya. Bayangkan anda mesti membaca karya orang lain, dan saya rasa anda sudah melakukannya, dan semua pembolehubah bernama Foo, Bar, Baz, Var, dll. Dan kod itu tidak dikomentari atau didokumenkan. Anda mungkin akan merasakan dorongan secara tiba -tiba untuk memanggil tuhan -tuhan yang tidak diketahui, kemudian pergi ke pub tempatan dan menenggelamkan kesedihan anda. Mereka mengatakan bahawa anda tidak boleh melakukan kepada orang lain apa yang anda tidak mahu lakukan kepada anda, jadi bahagian ini akan memberi tumpuan kepada garis panduan pengekodan umum, ditambah idea khusus GNU yang akan membantu anda menerima kod anda. Anda sepatutnya membaca dan memahami bahagian sebelumnya siri ini, serta menyelesaikan semua latihan dan, sebaik -baiknya, membaca dan menulis sebanyak mungkin kod.

Cadangan

Sebelum memulakan, sila perhatikan makna sebenar perkataan di atas. Saya tidak, dengan cara apa pun, ingin memberitahu anda bagaimana menulis kod anda, dan saya juga tidak mencipta cadangan ini. Ini adalah hasil kerja tahun oleh pengaturcara yang berpengalaman, dan banyak yang tidak hanya akan digunakan untuk C, tetapi kepada bahasa lain, ditafsirkan atau disusun.

Saya rasa peraturan pertama yang ingin saya tegaskan ialah: komen kod anda, kemudian periksa sama ada anda memberi komen yang cukup, kemudian komen lebih lanjut. Ini tidak memberi manfaat kepada orang lain yang akan membaca/menggunakan kod anda, tetapi juga untuk anda. Yakin bahawa anda tidak akan ingat apa sebenarnya yang anda maksudkan untuk menulis selepas dua atau tiga bulan, dan tidak akan tahu apa int ghrqa34; sepatutnya bermaksud, jika ada. Pemaju yang baik mengulas (hampir) setiap baris kod mereka secepat mungkin, dan hasilnya lebih daripada yang anda mungkin sedar pada mulanya, walaupun peningkatan masa yang diperlukan untuk menulis program. Satu lagi kelebihan ialah dengan memberi komen, kerana ini adalah bagaimana otak kita berfungsi, apa sahaja yang kita mahu lakukan akan lebih baik diingat, jadi sekali lagi anda tidak akan melihat kod anda, cepat ke hadapan beberapa bulan, tertanya-tanya siapa yang menulis kod anda. Atau mengapa.

Parser C tidak begitu peduli bagaimana memerintahkan kod anda. Ini bermakna anda boleh menulis program "hello, dunia" yang biasa seperti ini, dan ia masih akan menyusun:

#include int main () printf ("hello, dunia!"); kembali 0; 

Nampaknya lebih mudah dibaca dengan cara kami menulisnya pada kali pertama, bukan? Peraturan umum mengenai pemformatan adalah: satu arahan setiap baris, pilih lebar tab anda dan selaras dengannya, tetapi pastikan ia mematuhi garis panduan projek, jika anda bekerja pada satu, juga menggunakan garis kosong liberal, untuk Membatalkan pelbagai bahagian program, bersama-sama dengan komen, dan akhirnya, walaupun ini tidak semestinya pengekodan gaya yang berkaitan, sebelum anda mula mengodkan dengan serius, cari editor yang anda suka dan belajar menggunakannya dengan baik. Kami akan segera menerbitkan artikel mengenai editor, tetapi sehingga itu Google akan membantu anda dengan beberapa alternatif. Sekiranya anda mendengar orang di forum, senarai mel, dll. Mengatakan "Editor X Sucks, Editor Y FTW!", abaikan mereka. Ini adalah perkara yang sangat subjektif dan apa yang baik untuk saya mungkin tidak begitu baik untuk anda, jadi sekurang -kurangnya cuba beberapa editor yang tersedia untuk Linux selama beberapa hari setiap hari sebelum mula cuba membuat beberapa pendapat.

Konsisten dalam penamaan pembolehubah. Juga pastikan nama sesuai dengan yang lain, jadi ada keharmonian dalam keseluruhan program. Ini terpakai walaupun anda satu -satunya pengarang perisian, lebih mudah untuk dijaga kemudian. Buat senarai awalan dan akhiran yang digunakan (e.g. max, min, get, set, cnt) dan pergi bersama mereka, kecuali ditanya sebaliknya. Konsistensi adalah kata kunci di sini.

Garis panduan khusus GNU

Apa yang berikut adalah ringkasan piawaian pengekodan GNU, kerana kita tahu anda tidak suka membaca perkara tersebut. Jadi jika anda menulis kod yang ingin dimuatkan ke dalam ekosistem GNU, ini adalah dokumen untuk dibaca. Walaupun anda tidak, masih ada bacaan yang baik mengenai cara menulis kod yang betul.

Dokumen ini selalu dibaca dalam keseluruhannya jika anda membuat atau mengekalkan perisian GNU, tetapi anda akan mendapati bahagian yang paling penting di bawah. Satu isu pertama yang perlu disebutkan ialah cara menangani prototaip fungsi. Sila kembali ke bahagian yang berurusan dengannya jika anda mempunyai masalah. Ideanya ialah "Jika anda mempunyai fungsi anda sendiri, gunakan perisytiharan prototaip sebelum utama (), kemudian tentukan fungsi apabila diperlukan."Inilah contoh:

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

Gunakan lekukan yang betul dan berterusan. Ini tidak dapat ditekankan cukup. Pengaturcara yang berpengalaman dengan kod bertahun -tahun di belakang akan mengambilnya dengan sangat teruk apabila anda menghantar kod dengan lekukan yang tidak betul. Dalam kes kami, cara terbaik untuk membiasakan diri dengan cara GNU ini dengan menggunakan GNU Emacs (walaupun ini tidak dalam apa jua bentuk kami untuk memberitahu anda bahawa "GNU Emacs adalah baik untuk anda, gunakannya.", Kerana kami penyokong kehendak dan pilihan bebas), di mana tingkah laku lalai untuk kod C adalah lekukan yang ditetapkan di dua ruang dan pendakap pada garis untuk diri mereka sendiri. Yang membawa kita ke isu penting lain. Sebilangan orang menggunakan pendakap seperti ini:

manakala (var == 1) code ... 

... sementara yang lain, termasuk orang GNU, lakukan seperti ini:

manakala (var == 1) code ...

Sudah tentu, ini juga terpakai kepada ungkapan bersyarat, fungsi dan setiap kesempatan di mana anda perlu menggunakan pendakap dalam kod C. Sejauh yang diperhatikan, pilihan ini adalah sesuatu yang sangat khusus GNU, dan berapa banyak yang anda hormati bergantung hanya pada citarasa dan pendirian anda mengenai isu ini.

Isu seterusnya adalah teknikal, dan janji yang saya harus simpan: isu malloc (). Selain menulis mesej ralat yang berkaitan dan bermakna, tidak seperti yang kita lihat dalam sistem operasi lain, periksa bahawa malloc () dan rakan selalu kembali sifar. Ini adalah isu yang sangat serius, dan anda akan mendapat beberapa perkataan pelajaran mengenai malloc () dan bila menggunakannya. Sekarang anda tahu apa yang memperuntukkan memori secara automatik atau statik. Tetapi kaedah ini tidak meliputi semua pangkalan. Apabila anda perlu memperuntukkan ingatan dan mempunyai lebih banyak kawalan ke atas operasi, ada malloc () dan rakan -rakan, untuk peruntukan dinamik. Tujuannya adalah untuk memperuntukkan memori yang ada dari timbunan, Kemudian program ini menggunakan memori melalui penunjuk yang malloc () pulangan, kemudian berkata memori mestilah percuma () d. Dan "mesti" ditulis dengan ibu dalam huruf 2 kaki dengan warna merah yang terbakar. Itu sahaja dengan Malloc (), dan sebab -sebabnya telah didedahkan sebelum ini di bahagian sebelumnya.

Anda digesa menggunakan antara muka yang konsisten dalam semua program baris arahan anda. Sekiranya anda sudah menjadi pengguna GNU/Linux yang berpengalaman, anda telah melihat bahawa hampir semua program mempunyai -versi dan -help, ditambah, misalnya, -v untuk verbose, jika demikian. Kami tidak akan masuk ke dalamnya di sini; Dapatkan salinan piawaian pengekodan GNU, anda juga memerlukannya.

Walaupun saya secara peribadi cenderung untuk mengabaikan ini, dan kepada banyak masalah kecil, ia akan meningkatkan kebolehbacaan kod anda, kerana, sekali lagi, itulah cara otak kita berfungsi. Ideanya ialah: Apabila anda ragu -ragu menggunakan ruang, gunakannya. Sebagai contoh:

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

Ada beberapa yang mengatakan bahawa anda tidak boleh mengelakkan bersarang. Ada orang lain yang mengatakan "Mengapa mengelakkan bersarang?"Dan ada yang lain yang tidak menggunakan IF bersarang. Anda akan membuat pendapat anda sendiri mengenai masa ini sebagai pas masa dan baris kod yang anda tulis meningkat. Ideanya ialah, jika anda menggunakannya, menjadikannya sebagai boleh dibaca dengan mudah, kerana mereka mudah dapat membawa kepada kod hampir spageti, sukar dibaca dan mengekalkan. Dan sekali lagi, gunakan komen.

Standard pengekodan GNU mengatakan bahawa adalah baik untuk mempunyai kod anda sebagai mudah alih seperti yang boleh, "tetapi tidak penting". Perkakasan mudah alih-bijak? Itu bergantung pada tujuan program dan mesin apa yang anda ada. Kami merujuk lebih banyak ke bahagian perisian, iaitu mudah alih antara sistem unix, sumber terbuka atau tidak. Elakkan jika anda boleh, elakkan andaian mengenai lokasi fail (e.g. Solaris memasang perisian pihak ketiga di bawah /memilih, manakala BSD dan GNU /Linux tidak), dan secara amnya bertujuan untuk kod bersih. Bercakap mengenai andaian, janganlah menganggap bahawa byte adalah lapan bit atau ruang alamat CPU mestilah nombor juga.

Mendokumentasikan kod anda, dalam bentuk halaman manual dan readmes yang ditulis dengan baik dan sebagainya, merupakan aspek utama pembangunan perisian yang lain. Ya, itu adalah tugas yang membosankan, tetapi jika anda tidak mempunyai penulis dokumentasi di pasukan anda, tanggungjawab anda untuk melakukannya, kerana setiap pengaturcara yang baik melakukan tugasnya dari A hingga z.

Kesimpulan

Lain kali kita akan meneruskan dari mana kita berhenti di sini: pergi dari idea ke program lengkap, dengan makefiles, dokumentasi, kitaran pelepasan dan semua perkara yang menyeronokkan. Satu -satunya latihan yang saya ada untuk anda adalah untuk melangkaui piawaian pengekodan GNU dan mengubah suai kod anda untuk menyesuaikan diri. Dan bersiap sedia, lain kali ia menyeronokkan!

Inilah yang boleh anda harapkan seterusnya:

• I. C Pembangunan di Linux - Pengenalan
• Ii. Perbandingan antara c dan bahasa pengaturcaraan lain
• Iii. Jenis, pengendali, pembolehubah
• Iv. Kawalan aliran
• V. Fungsi
• Vi. Petunjuk dan tatasusunan
• VII. Struktur
• Viii. Asas I/O
• Ix. Gaya dan cadangan pengekodan
• X. Membina program
• Xi. Pembungkusan untuk Debian dan Fedora
• Xii. Mendapatkan pakej di repositori debian rasmi

Tutorial Linux Berkaitan:

• Tutorial Debugging GDB untuk Pemula
• Pasang Arch Linux di Workstation VMware
• Pengenalan kepada Automasi, Alat dan Teknik Linux
• Perkara yang hendak dipasang di Ubuntu 20.04
• Ungkapan biasa python dengan contoh
• Cara Membina Aplikasi TKInter Menggunakan Objek Berorientasikan ..
• Advanced Bash Regex dengan contoh
• Gelung bash dengan contoh
• Perkara yang perlu dilakukan setelah memasang ubuntu 20.04 Focal Fossa Linux
• Gelung bersarang dalam skrip bash