Ini ialah arahan perlstyle yang boleh dijalankan dalam penyedia pengehosan percuma OnWorks menggunakan salah satu daripada berbilang stesen kerja dalam talian percuma kami seperti Ubuntu Online, Fedora Online, emulator dalam talian Windows atau emulator dalam talian MAC OS.
JADUAL:
NAMA
perlstyle - Panduan gaya Perl
DESCRIPTION
Setiap pengaturcara, sudah tentu, mempunyai keutamaannya sendiri dalam hal pemformatan,
tetapi terdapat beberapa garis panduan umum yang akan menjadikan program anda lebih mudah dibaca,
memahami, dan mengekalkan.
Perkara yang paling penting ialah menjalankan program anda di bawah -w bendera pada setiap masa. Anda boleh
matikan secara eksplisit untuk bahagian tertentu kod melalui pragma "tiada amaran" atau
Pembolehubah $^W jika anda mesti. Anda juga harus sentiasa berjalan di bawah "gunakan ketat" atau tahu
sebab kenapa tidak. Pragma "guna sigtrap" dan juga "guna diagnostik" mungkin juga terbukti
berguna.
Mengenai estetika tata letak kod, satu-satunya perkara yang Larry sangat mengambil berat tentang
bahawa kurungan kerinting penutup BLOK berbilang baris hendaklah selaras dengan kata kunci itu
memulakan konstruk. Selain itu, dia mempunyai pilihan lain yang tidak begitu kuat:
· Inden 4 lajur.
· Membuka kerinting pada baris yang sama dengan kata kunci, jika boleh, sebaliknya berbaris.
· Ruang sebelum pembukaan kerinting BLOK berbilang baris.
· BLOCK satu baris boleh diletakkan pada satu baris, termasuk kerinting.
· Tiada ruang sebelum koma bertitik.
· Koma bertitik ditiadakan dalam BLOK satu baris "pendek".
· Ruang di sekeliling kebanyakan pengendali.
· Ruang di sekeliling subskrip "kompleks" (dalam kurungan).
· Garis kosong antara ketulan yang melakukan perkara yang berbeza.
· Lain-lain yang tidak dipeluk.
· Tiada ruang antara nama fungsi dan kurungan pembukaannya.
· Ruang selepas setiap koma.
· Garisan panjang terputus selepas pengendali (kecuali "dan" dan "atau").
· Ruang selepas kurungan terakhir padanan pada baris semasa.
· Selaraskan item yang sepadan secara menegak.
· Abaikan tanda baca yang berlebihan selagi kejelasan tidak terjejas.
Larry mempunyai alasannya untuk setiap perkara ini, tetapi dia tidak mendakwa bahawa semua orang lain
minda berfungsi sama seperti dia.
Berikut ialah beberapa isu gaya lain yang lebih substantif untuk difikirkan:
· Hanya kerana anda CAN melakukan sesuatu dengan cara tertentu tidak bermakna anda DAPATKAN melakukannya
Jalan itu. Perl direka bentuk untuk memberi anda beberapa cara untuk melakukan apa sahaja, jadi pertimbangkan
memilih yang paling mudah dibaca. Contohnya
buka(FOO,$foo) || mati "Tidak boleh membuka $foo: $!";
lebih baik daripada
mati "Tidak boleh membuka $foo: $!" melainkan terbuka(FOO,$foo);
kerana cara kedua menyembunyikan titik utama pernyataan dalam pengubah suai. Pada
tangan lain
cetak "Memulakan analisis\n" jika $verbose;
lebih baik daripada
$verbose && cetak "Memulakan analisis\n";
kerana perkara utama bukanlah sama ada pengguna menaip -v atau tidak.
Begitu juga, hanya kerana pengendali membenarkan anda menganggap hujah lalai tidak bermakna
bahawa anda perlu menggunakan lalai. Lalai ada untuk sistem malas
pengaturcara menulis program satu pukulan. Jika anda mahu program anda boleh dibaca,
pertimbangkan untuk membekalkan hujah.
Sepanjang garis yang sama, hanya kerana anda CAN tinggalkan kurungan di banyak tempat tidak
bermakna anda sepatutnya:
kembalikan nilai num isihan terbalik cetakan %array;
kembalikan cetakan(terbalik(nombor isihan (nilai(%array))));
Apabila ragu-ragu, tandakan kurungan. Sekurang-kurangnya ia akan membiarkan beberapa schmuck miskin melantun
pada kunci % masuk vi.
Walaupun anda tidak ragu-ragu, pertimbangkan kebajikan mental orang yang terpaksa melakukannya
kekalkan kod selepas anda, dan siapa yang mungkin akan meletakkan kurungan di tempat yang salah.
· Jangan melalui lilitan bodoh untuk keluar dari gelung di bahagian atas atau bawah, apabila Perl
menyediakan pengendali "terakhir" supaya anda boleh keluar di tengah. Hanya "outdent" ia a
sedikit untuk menjadikannya lebih kelihatan:
BARIS:
untuk (;;) {
kenyataan;
BARISAN terakhir jika $foo;
BARISAN seterusnya jika /^#/;
kenyataan;
}
· Jangan takut untuk menggunakan label gelung--ia ada untuk meningkatkan kebolehbacaan serta untuk
benarkan pecah gelung berbilang peringkat. Lihat contoh sebelumnya.
· Elakkan menggunakan "grep()" (atau "map()") atau `backticks` dalam konteks kosong, iaitu, apabila anda
buang sahaja nilai pulangan mereka. Fungsi tersebut semua mempunyai nilai pulangan, jadi gunakan
mereka. Sebaliknya gunakan gelung "foreach()" atau fungsi "system()".
· Untuk mudah alih, apabila menggunakan ciri yang mungkin tidak dilaksanakan pada setiap mesin,
menguji konstruk dalam eval untuk melihat jika ia gagal. Jika anda tahu versi atau
patchlevel ciri tertentu telah dilaksanakan, anda boleh menguji $] ($PERL_VERSION dalam
"Bahasa Inggeris") untuk melihat sama ada ia akan berada di sana. Modul "Config" juga akan membenarkan anda
menyoal nilai yang ditentukan oleh Konfigurasi program apabila Perl dipasang.
· Pilih pengecam mnemonik. Jika anda tidak dapat mengingati maksud mnemonik, anda mempunyai a
masalah.
· Walaupun pengecam pendek seperti $gotit mungkin ok, gunakan garis bawah untuk memisahkan perkataan
dalam pengecam yang lebih panjang. Secara umumnya lebih mudah untuk membaca $var_names_like_this daripada
$VarNamesLikeThis, terutamanya untuk bukan penutur asli bahasa Inggeris. Ia juga mudah
peraturan yang berfungsi secara konsisten dengan "VAR_NAMES_LIKE_THIS".
Nama pakej kadangkala merupakan pengecualian kepada peraturan ini. Perl rizab secara tidak rasmi
nama modul huruf kecil untuk modul "pragma" seperti "integer" dan "ketat". Lain-lain
modul harus bermula dengan huruf besar dan menggunakan huruf besar bercampur, tetapi mungkin tanpa
menggariskan kerana batasan dalam perwakilan sistem fail primitif modul
nama sebagai fail yang mesti dimuatkan ke dalam beberapa bait yang jarang.
· Anda mungkin mendapati ia berguna untuk menggunakan huruf besar untuk menunjukkan skop atau sifat a
pembolehubah. Sebagai contoh:
Pemalar $ALL_CAPS_HERE sahaja (berhati-hati pertembungan dengan perl vars!)
$Some_Caps_Here global/statik seluruh pakej
$no_caps_here fungsi skop pembolehubah my() atau local().
Nama fungsi dan kaedah nampaknya berfungsi paling baik kerana semua huruf kecil. cth.,
"$obj->as_string()".
Anda boleh menggunakan garis bawah utama untuk menunjukkan bahawa pembolehubah atau fungsi tidak sepatutnya
digunakan di luar pakej yang menentukannya.
· Jika anda mempunyai ungkapan biasa yang sangat berbulu, gunakan pengubah suai "/x" dan masukkan beberapa
ruang putih untuk menjadikannya kelihatan kurang seperti bunyi garisan. Jangan gunakan slash sebagai a
pembatas apabila regexp anda mempunyai garis miring atau garis miring ke belakang.
· Gunakan pengendali "dan" dan "atau" baharu untuk mengelak daripada menyarungkan pengendali senarai sedemikian
banyak, dan untuk mengurangkan kejadian pengendali tanda baca seperti "&&" dan "||". Panggil
subrutin anda seolah-olah ia adalah fungsi atau pengendali senarai untuk mengelakkan berlebihan
ampersand dan kurungan.
· Gunakan di sini dokumen dan bukannya pernyataan "cetak()" berulang.
· Selaraskan perkara yang sepadan secara menegak, terutamanya jika ia terlalu panjang untuk dimuatkan pada satu
baris pula.
$IDX = $ST_MTIME;
$IDX = $ST_ATIME jika $opt_u;
$IDX = $ST_CTIME jika $opt_c;
$IDX = $ST_SIZE jika $opt_s;
mkdir $tmpdir, 0700 atau mati "tidak boleh mkdir $tmpdir: $!";
chdir($tmpdir) atau mati "tidak boleh chdir $tmpdir: $!";
mkdir 'tmp', 0777 atau mati "tidak boleh mkdir $tmpdir/tmp: $!";
· Sentiasa semak kod pemulangan panggilan sistem. Mesej ralat yang baik harus pergi ke
"STDERR", sertakan program yang menyebabkan masalah, panggilan sistem yang gagal dan
argumen adalah, dan (SANGAT PENTING) harus mengandungi mesej ralat sistem standard
untuk apa yang salah. Berikut ialah contoh yang mudah tetapi mencukupi:
opendir(D, $dir) atau mati "tidak boleh opendir $dir: $!";
· Selaraskan transliterasi anda apabila ia masuk akal:
tr [abc]
[xyz];
· Fikirkan tentang kebolehgunaan semula. Mengapa membazirkan kuasa otak pada satu pukulan sedangkan anda mungkin mahu melakukannya
sesuatu seperti itu lagi? Pertimbangkan untuk menyamaratakan kod anda. Pertimbangkan untuk menulis modul
atau kelas objek. Pertimbangkan untuk membuat kod anda berjalan dengan bersih dengan "use strict" dan "use
amaran" (atau -w) dalam kesan. Pertimbangkan untuk memberikan kod anda. Pertimbangkan untuk menukar anda
pandangan seluruh dunia. Pertimbangkan... oh, tidak mengapa.
· Cuba dokumentasikan kod anda dan gunakan pemformatan Pod dengan cara yang konsisten. Disini adalah
konvensyen yang biasa dijangka:
· gunakan "C<>" untuk nama fungsi, pembolehubah dan modul (dan lebih umum apa-apa
yang boleh dianggap sebahagian daripada kod, seperti pemegang fail atau nilai tertentu). Catatan
bahawa nama fungsi dianggap lebih mudah dibaca dengan kurungan selepas nama itu
nama, iaitu "fungsi()".
· gunakan "B<>" untuk nama arahan seperti kucing or grep.
· gunakan "F<>" atau "C<>" untuk nama fail. "F<>" sepatutnya menjadi satu-satunya kod Pod untuk fail
nama, tetapi kerana kebanyakan pemformat Pod menjadikannya sebagai italik, laluan Unix dan Windows dengan
garis miring dan garis miring belakang mereka mungkin kurang boleh dibaca, dan lebih baik diberikan dengan
"C<>".
· Selaras.
· Jadilah baik.
Gunakan perlstyle dalam talian menggunakan perkhidmatan onworks.net