perlmodstyle - Online di Cloud

PROGRAM:

NAMA

perlmodstyle - panduan gaya modul Perl

PENGANTAR

Dokumen ini mencoba menjelaskan "praktik terbaik" Komunitas Perl untuk menulis Perl
modul. Ini memperluas rekomendasi yang ditemukan di perlstyle , yang harus dipertimbangkan
wajib dibaca sebelum membaca dokumen ini.

Meskipun dokumen ini dimaksudkan untuk berguna bagi semua penulis modul, ini terutama:
ditujukan untuk penulis yang ingin mempublikasikan modul mereka di CPAN.

Fokusnya adalah pada elemen gaya yang terlihat oleh pengguna modul, bukan
bagian-bagian yang hanya dapat dilihat oleh pengembang modul. Namun, banyak dari
pedoman yang disajikan dalam dokumen ini dapat diekstrapolasi dan diterapkan dengan sukses ke a
internal modul.

Dokumen ini berbeda dari perlnewmod karena merupakan panduan gaya daripada tutorial
pada pembuatan modul CPAN. Ini memberikan daftar periksa dengan modul mana yang dapat dibandingkan
untuk menentukan apakah mereka sesuai dengan praktik terbaik, tanpa harus menjelaskan
rinci bagaimana mencapai ini.

Semua saran yang terkandung dalam dokumen ini telah diperoleh dari percakapan yang ekstensif
dengan penulis dan pengguna CPAN berpengalaman. Setiap nasihat yang diberikan di sini adalah hasilnya
dari kesalahan sebelumnya. Informasi ini di sini untuk membantu Anda menghindari kesalahan yang sama dan
pekerjaan ekstra yang pasti akan diperlukan untuk memperbaikinya.

Bagian pertama dari dokumen ini menyediakan daftar periksa yang diperinci; bagian selanjutnya
memberikan diskusi yang lebih rinci tentang item dalam daftar. Bagian terakhir, "Umum
Pitfalls", menjelaskan beberapa kesalahan paling populer yang dibuat oleh penulis CPAN.

CEPAT DAFTAR PERIKSA

Untuk detail lebih lanjut tentang setiap item dalam daftar periksa ini, lihat di bawah.

Sebelum Anda awal
· Jangan menemukan kembali roda

· Menambal, memperluas, atau mensubklasifikasikan modul yang ada jika memungkinkan

· Lakukan satu hal dan lakukan dengan baik

· Pilih nama yang sesuai

· Dapatkan umpan balik sebelum menerbitkan

API
· API harus dapat dimengerti oleh programmer rata-rata

· Metode sederhana untuk tugas-tugas sederhana

· Pisahkan fungsi dari keluaran

· Penamaan subrutin atau metode yang konsisten

· Gunakan parameter bernama (hash atau hashref) ketika ada lebih dari dua parameter

Stabilitas
· Pastikan modul Anda berfungsi di bawah "gunakan ketat" dan "-w"

· Modul yang stabil harus menjaga kompatibilitas ke belakang

Dokumentasi
· Tulis dokumentasi di POD

· Tujuan dokumen, ruang lingkup dan aplikasi target

· Dokumentasikan setiap metode atau subrutin yang dapat diakses publik, termasuk params dan return
nilai-nilai

· Berikan contoh penggunaan dalam dokumentasi Anda

· Berikan file README dan mungkin juga rilis catatan, changelog, dll

· Berikan tautan ke informasi lebih lanjut (URL, email)

Lepaskan pertimbangan
· Tentukan prasyarat di Makefile.PL atau Build.PL

· Tentukan persyaratan versi Perl dengan "gunakan"

· Sertakan tes dengan modul Anda

· Pilih skema penomoran versi yang masuk akal dan konsisten (X.YY adalah Perl . yang umum
skema penomoran modul)

· Tingkatkan nomor versi untuk setiap perubahan, sekecil apa pun

· Kemas modul menggunakan "make dist"

· Pilih lisensi yang sesuai (GPL/Artistic adalah default yang bagus)

SEBELUM ANDA MULAI PENULISAN A MODUL

Cobalah untuk tidak terburu-buru mengembangkan modul Anda tanpa menghabiskan waktu untuk berpikir
pertama. Sedikit pemikiran ke depan dapat menghemat banyak usaha di kemudian hari.

Memiliki it menjadi dilakukan sebelumnya?
Anda bahkan mungkin tidak perlu menulis modul. Periksa apakah sudah dilakukan di Perl,
dan hindari menciptakan kembali roda kecuali Anda memiliki alasan yang baik.

Tempat yang bagus untuk mencari modul yang sudah ada sebelumnya termasukhttp://search.cpan.org/> dan
dan bertanya"[email dilindungi]"
(<http://lists.perl.org/list/module-authors.html>).

Jika modul yang ada hampir melakukan apa yang Anda inginkan, pertimbangkan untuk menulis tambalan, menulis
subclass, atau memperluas modul yang ada daripada menulis ulang.

Do satu hal dan do it baik
Dengan risiko menyatakan yang sudah jelas, modul dimaksudkan untuk menjadi modular. Pengembang Perl
harus dapat menggunakan modul untuk menyusun blok bangunan aplikasinya.
Namun, penting bahwa balok memiliki bentuk yang tepat, dan pengembangnya
tidak harus menggunakan balok besar ketika yang mereka butuhkan hanyalah balok kecil.

Modul Anda harus memiliki ruang lingkup yang jelas yang tidak lebih dari satu kalimat.
Bisakah modul Anda dipecah menjadi keluarga modul terkait?

Contoh buruk:

"FooBar.pm menyediakan implementasi protokol FOO dan standar BAR terkait."

Contoh yang baik:

"Foo.pm menyediakan implementasi protokol FOO. Bar.pm mengimplementasikan BAR
protokol."

Artinya, jika pengembang hanya membutuhkan modul untuk standar BAR, mereka tidak boleh
dipaksa untuk menginstal perpustakaan untuk FOO juga.

Apa in a nama?
Pastikan Anda memilih nama yang sesuai untuk modul Anda sejak dini. Ini akan membantu orang
temukan dan ingat modul Anda, dan buat pemrograman dengan modul Anda lebih intuitif.

Saat memberi nama modul Anda, pertimbangkan hal berikut:

· Jadilah deskriptif (yaitu secara akurat menjelaskan tujuan modul).

· Konsisten dengan modul yang ada.

· Mencerminkan fungsionalitas modul, bukan implementasinya.

· Hindari memulai hierarki tingkat atas yang baru, terutama jika sudah ada hierarki yang sesuai
ada di mana Anda dapat menempatkan modul Anda.

Dapatkan umpan balik sebelum penerbitan
Jika Anda belum pernah mengunggah modul ke CPAN sebelumnya (dan bahkan jika sudah), Anda
sangat dianjurkan untuk mendapatkan umpan balik tentang PrePANhttp://prepan.org>. PrePAN adalah sebuah situs
didedikasikan untuk mendiskusikan ide-ide untuk modul CPAN dengan pengembang Perl lainnya dan sangat bagus
sumber daya untuk pengembang Perl baru (dan berpengalaman).

Anda juga harus mencoba untuk mendapatkan umpan balik dari orang-orang yang sudah akrab dengan modul
domain aplikasi dan sistem penamaan CPAN. Penulis modul serupa, atau modul
dengan nama yang mirip, mungkin merupakan tempat yang baik untuk memulai, seperti juga situs komunitas seperti Perl Monks
<http://www.perlmonks.org>.

DESAIN DAN PENULISAN ANDA MODUL

Pertimbangan untuk desain dan pengkodean modul:

Untuk OO or tidak untuk OO?
Modul Anda mungkin berorientasi objek (OO) atau tidak, atau mungkin memiliki kedua jenis antarmuka
tersedia. Ada pro dan kontra dari setiap teknik, yang harus dipertimbangkan saat Anda
desain API Anda.

In Perl Terbaik Praktek (hak cipta 2004, Diterbitkan oleh O'Reilly Media, Inc.), Damian Conway
memberikan daftar kriteria untuk digunakan saat memutuskan apakah OO cocok untuk masalah Anda:

· Sistem yang dirancang besar, atau kemungkinan besar.

· Data dapat diagregasikan ke dalam struktur yang jelas, terutama jika ada yang besar
jumlah data dalam setiap agregat.

· Berbagai jenis agregat data membentuk hierarki alami yang memfasilitasi penggunaan
pewarisan dan polimorfisme.

· Anda memiliki sepotong data di mana banyak operasi yang berbeda diterapkan.

· Anda perlu melakukan operasi umum yang sama pada jenis data terkait, tetapi dengan
sedikit variasi tergantung pada jenis data spesifik operasi yang diterapkan
untuk.

· Sepertinya Anda harus menambahkan tipe data baru nanti.

· Interaksi khas antara potongan data paling baik diwakili oleh operator.

· Implementasi masing-masing komponen sistem kemungkinan besar akan berubah
waktu.

· Desain sistem sudah berorientasi objek.

· Sejumlah besar programmer lain akan menggunakan modul kode Anda.

Pikirkan baik-baik apakah OO cocok untuk modul Anda. Objek serampangan
orientasi menghasilkan API kompleks yang sulit bagi pengguna modul rata-rata untuk
memahami atau menggunakan.

Merancang Tujuan API
Antarmuka Anda harus dapat dimengerti oleh programmer Perl rata-rata. Pengikut
pedoman dapat membantu Anda menilai apakah API Anda cukup sederhana:

Menulis rutinitas sederhana untuk melakukan hal-hal sederhana.
Lebih baik memiliki banyak rutinitas sederhana daripada beberapa yang monolitik. Jika Anda
rutin mengubah perilakunya secara signifikan berdasarkan argumennya, itu pertanda bahwa
Anda harus memiliki dua (atau lebih) rutinitas terpisah.

Pisahkan fungsionalitas dari output.
Kembalikan hasil Anda dalam bentuk yang paling umum dan izinkan pengguna untuk memilih caranya
untuk menggunakannya. Bentuk paling umum yang mungkin biasanya adalah struktur data Perl yang
kemudian dapat digunakan untuk menghasilkan laporan teks, HTML, XML, kueri basis data, atau apa pun
lain yang dibutuhkan pengguna Anda.

Jika rutinitas Anda mengulangi beberapa jenis daftar (seperti daftar file, atau
catatan dalam database) Anda dapat mempertimbangkan untuk memberikan panggilan balik sehingga pengguna dapat
memanipulasi setiap elemen daftar secara bergantian. File::Find memberikan contoh ini
dengan sintaks "find(\&wanted, $dir)".

Berikan pintasan dan default yang masuk akal.
Jangan mengharuskan setiap pengguna modul untuk melewati rintangan yang sama untuk mencapai yang sederhana
hasil. Anda selalu dapat menyertakan parameter opsional atau rutinitas untuk lebih kompleks atau
perilaku yang tidak standar. Jika sebagian besar pengguna Anda harus mengetik beberapa yang hampir sama
baris kode ketika mereka mulai menggunakan modul Anda, itu pertanda bahwa Anda seharusnya membuatnya
perilaku itu sebagai default. Indikator bagus lainnya yang harus Anda gunakan secara default adalah jika
sebagian besar pengguna Anda memanggil rutinitas Anda dengan argumen yang sama.

Konvensi penamaan
Penamaan Anda harus konsisten. Misalnya, lebih baik memiliki:

tampilan_hari();
tampilan_minggu();
tampilan_tahun();

dari

tampilan_hari();
minggu_tampilan();
tampilkan_tahun();

Ini berlaku sama untuk nama metode, nama parameter, dan hal lain yang
terlihat oleh pengguna (dan sebagian besar hal yang tidak!)

Melewati parameter
Gunakan parameter bernama. Lebih mudah menggunakan hash seperti ini:

$obj->lakukan_sesuatu(
nama => "goyang",
ketik => "teks",
ukuran => 1024,
);

... daripada memiliki daftar panjang parameter yang tidak disebutkan namanya seperti ini:

$obj->do_something("menggoyang", "teks", 1024);

Meskipun daftar argumen mungkin berfungsi dengan baik untuk satu, dua atau bahkan tiga argumen, apa saja
lebih banyak argumen menjadi sulit untuk diingat oleh pengguna modul, dan sulit untuk modul
penulis untuk mengelola. Jika Anda ingin menambahkan parameter baru, Anda harus menambahkannya ke
akhir daftar untuk kompatibilitas mundur, dan ini mungkin akan membuat daftar Anda
memesan tidak intuitif. Juga, jika banyak elemen mungkin tidak terdefinisi, Anda mungkin melihat yang berikut:
panggilan metode yang tidak menarik:

$obj->do_something(undef, undef, undef, undef, undef, 1024);

Berikan default yang masuk akal untuk parameter yang memilikinya. Jangan membuat pengguna Anda
tentukan parameter yang hampir selalu sama.

Masalah apakah akan meneruskan argumen dalam hash atau hashref sebagian besar merupakan masalah
dari gaya pribadi.

Penggunaan kunci hash dimulai dengan tanda hubung ("-name") atau seluruhnya dalam huruf besar
("NAME") adalah peninggalan dari versi lama Perl di mana string huruf kecil biasa
tidak ditangani dengan benar oleh operator "=>". Sementara beberapa modul mempertahankan huruf besar
atau kunci argumen dengan tanda hubung karena alasan historis atau karena gaya pribadi,
kebanyakan modul baru harus menggunakan tombol huruf kecil sederhana. Apa pun yang Anda pilih, jadilah
konsisten!

Kekerasan dan peringatan
Modul Anda harus berjalan dengan sukses di bawah pragma yang ketat dan harus berjalan tanpa
menghasilkan peringatan apa pun. Modul Anda juga harus menangani pemeriksaan noda jika perlu,
meskipun ini dapat menyebabkan kesulitan dalam banyak kasus.

Terbalik kesesuaian
Modul yang "stabil" tidak boleh merusak kompatibilitas mundur tanpa setidaknya a
fase transisi yang panjang dan perubahan besar dalam nomor versi.

error penanganan dan pesan
Saat modul Anda mengalami kesalahan, modul harus melakukan satu atau lebih dari:

· Mengembalikan nilai yang tidak ditentukan.

· set $Module::errstr atau yang serupa ("errstr" adalah nama umum yang digunakan oleh DBI dan
modul populer; jika Anda memilih sesuatu yang lain, pastikan untuk mendokumentasikannya dengan jelas).

· "peringatkan()" atau "ikan mas()" pesan ke STDERR.

· "croak()" hanya ketika modul Anda benar-benar tidak tahu apa yang harus dilakukan. ("menggaok()"
adalah versi "die()" yang lebih baik untuk digunakan dalam modul, yang melaporkan kesalahannya dari
perspektif penelepon. Lihat Carp untuk detail "croak()", "carp()" dan lainnya
rutinitas yang bermanfaat.)

· Sebagai alternatif di atas, Anda mungkin lebih suka membuang pengecualian menggunakan Kesalahan
modul.

Penanganan kesalahan yang dapat dikonfigurasi dapat sangat berguna bagi pengguna Anda. Pertimbangkan untuk menawarkan pilihan
level untuk pesan peringatan dan debug, opsi untuk mengirim pesan ke file terpisah, a
cara untuk menentukan rutin penanganan kesalahan, atau fitur lain semacam itu. Pastikan untuk default semua
pilihan ini untuk penggunaan yang paling umum.

DOKUMENTASI ANDA MODUL

POD
Modul Anda harus menyertakan dokumentasi yang ditujukan untuk pengembang Perl. Anda harus menggunakan Perl's
"dokumentasi lama biasa" (POD) untuk dokumentasi teknis umum Anda, meskipun Anda dapat
ingin menulis dokumentasi tambahan (kertas putih, tutorial, dll) di beberapa lainnya
format. Anda perlu mencakup mata pelajaran berikut:

· Sebuah sinopsis dari penggunaan umum dari modul

· Tujuan, ruang lingkup, dan aplikasi target modul Anda

· Penggunaan setiap metode atau subrutin yang dapat diakses publik, termasuk parameter dan
mengembalikan nilai

· Contoh penggunaan

· Sumber informasi lebih lanjut

· Alamat email kontak untuk penulis/pengelola

Tingkat detail dalam dokumentasi modul Perl umumnya berubah dari kurang detail menjadi lebih
terperinci. Bagian SINOPSIS Anda harus berisi contoh penggunaan minimal (mungkin sebagai
sedikitnya satu baris kode; lewati kasus penggunaan yang tidak biasa atau apa pun yang tidak dibutuhkan oleh kebanyakan orang
pengguna); DESKRIPSI harus menjelaskan modul Anda secara luas, umumnya hanya dalam a
beberapa paragraf; lebih detail dari rutinitas atau metode modul, contoh kode yang panjang, atau
materi mendalam lainnya harus diberikan di bagian selanjutnya.

Idealnya, seseorang yang sedikit akrab dengan modul Anda harus dapat menyegarkan kembali
memori tanpa menekan "page down". Saat pembaca Anda melanjutkan membaca dokumen, mereka
harus menerima jumlah pengetahuan yang semakin besar.

Urutan bagian yang disarankan dalam dokumentasi modul Perl adalah:

· NAMA

· SINOPSIS

· KETERANGAN

· Satu atau lebih bagian atau subbagian memberikan detail yang lebih besar dari metode yang tersedia dan
rutinitas dan informasi lain yang relevan.

· BUGS/PERINGATAN/dll

· PENGARANG

· LIHAT JUGA

· HAK CIPTA dan LISENSI

Simpan dokumentasi Anda di dekat kode yang didokumentasi (dokumentasi "sebaris"). Sertakan POD
untuk metode tertentu tepat di atas subrutin metode tersebut. Ini membuatnya lebih mudah untuk menyimpannya
dokumentasi terbaru, dan menghindari keharusan untuk mendokumentasikan setiap potongan kode dua kali (sekali masuk)
POD dan sekali di komentar).

BACA AKU, INSTALL, melepaskan catatan, log perubahan
Modul Anda juga harus menyertakan file README yang menjelaskan modul dan memberikan petunjuk ke
informasi lebih lanjut (situs web, email penulis).

File INSTALL harus disertakan, dan harus berisi petunjuk instalasi sederhana.
Saat menggunakan ExtUtils::MakeMaker ini biasanya akan:

perl Makefile.PL
membuat
buat tes
make install

Saat menggunakan Module::Build, ini biasanya:

Perl Build.PL
perl Membangun
perl Membangun tes
perl Membangun instal

Catatan rilis atau log perubahan harus dibuat untuk setiap rilis perangkat lunak Anda
menjelaskan perubahan yang terlihat oleh pengguna pada modul Anda, dalam istilah yang relevan dengan pengguna.

Kecuali Anda memiliki alasan yang baik untuk menggunakan beberapa format lain (misalnya, format yang digunakan
dalam perusahaan Anda), konvensinya adalah memberi nama file changelog Anda "Perubahan", dan untuk
ikuti format sederhana yang dijelaskan dalam CPAN::Changes::Spec.

RELEASE PERTIMBANGAN

Versi penomoran
Nomor versi harus menunjukkan setidaknya rilis mayor dan minor, dan mungkin sub-minor
rilis. Rilis utama adalah rilis yang sebagian besar fungsinya telah berubah, atau di
yang fungsi baru utama ditambahkan. Rilis minor adalah rilis di mana sejumlah kecil
fungsionalitas telah ditambahkan atau diubah. Nomor versi sub-minor biasanya digunakan untuk
perubahan yang tidak memengaruhi fungsionalitas, seperti tambalan dokumentasi.

Skema penomoran versi CPAN yang paling umum terlihat seperti ini:

1.00, 1.10, 1.11, 1.20, 1.30, 1.31, 1.32

Nomor versi CPAN yang benar adalah nomor floating point dengan setidaknya 2 digit setelah
desimal. Anda dapat menguji apakah itu sesuai dengan CPAN dengan menggunakan

perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' 'Foo.pm'

Jika Anda ingin merilis modul versi 'beta' atau 'alfa' tetapi tidak ingin CPAN.pm melakukannya
daftarkan sebagai yang terbaru gunakan '_' setelah nomor versi reguler diikuti oleh setidaknya 2
digit, mis. 1.20_01. Jika Anda melakukan ini, idiom berikut ini disarankan:

$VERSION kami = "1.12_01"; # jadi distribusi CPAN akan memiliki
# nama file yang benar
$XS_VERSION kami = $VERSION; # hanya diperlukan jika Anda memiliki kode XS
$VERSI = evaluasi $VERSI; # jadi "gunakan Modul 0.002" tidak akan menyala
# garis bawah

Dengan trik itu MakeMaker hanya akan membaca baris pertama dan dengan demikian membaca garis bawah,
sementara juru bahasa Perl akan mengevaluasi $VERSION dan mengubah string menjadi a
nomor. Operasi selanjutnya yang memperlakukan $VERSION sebagai angka akan dapat melakukannya
tanpa memprovokasi peringatan tentang $VERSION bukan angka.

Jangan pernah merilis apa pun (bahkan tambalan dokumentasi satu kata) tanpa menambah
nomor. Bahkan tambalan dokumentasi satu kata harus menghasilkan perubahan versi di
tingkat sub-minor.

Setelah dipilih, penting untuk tetap menggunakan skema versi Anda, tanpa mengurangi jumlahnya
dari angka. Ini karena pembuat paket "hilir", seperti sistem port FreeBSD,
menafsirkan nomor versi dengan berbagai cara. Jika Anda mengubah jumlah digit di
skema versi, Anda dapat mengacaukan sistem ini sehingga mereka mengeluarkan versi modul Anda
ketertiban, yang jelas buruk.

Pra-syarat
Penulis modul harus mempertimbangkan dengan hati-hati apakah akan mengandalkan modul lain, dan mana yang
modul untuk diandalkan.

Yang terpenting, pilih modul yang sestabil mungkin. Dalam urutan preferensi:

· Modul Inti Perl

· Modul CPAN yang stabil

· Modul CPAN tidak stabil

· Modul tidak tersedia dari CPAN

Tentukan persyaratan versi untuk modul Perl lainnya di prasyarat di . Anda
Makefile.PL atau Build.PL.

Pastikan untuk menentukan persyaratan versi Perl baik di Makefile.PL atau Build.PL dan dengan
"memerlukan 5.6.1" atau serupa. Lihat bagian tentang "gunakan VERSI" dari "memerlukan" di perlfunc untuk
rincian.

pengujian
Semua modul harus diuji sebelum didistribusikan (menggunakan "make disttest"), dan pengujian
juga harus tersedia untuk orang yang menginstal modul (menggunakan "make test"). Untuk
Module::Build Anda akan menggunakan "make test" yang setara dengan "perl Build test".

Pentingnya tes ini sebanding dengan dugaan stabilitas modul. A
modul yang dimaksudkan untuk stabil atau yang diharapkan dapat digunakan secara luas harus dipatuhi sebagai
ketat rezim pengujian mungkin.

Modul yang berguna untuk membantu Anda menulis tes (dengan dampak minimal pada proses pengembangan Anda atau
waktu Anda) termasuk Test::Simple, Carp::Assert dan Test::Inline. Untuk lebih canggih
suite uji ada Test::More dan Test::MockObject.

Pengemasan
Modul harus dikemas menggunakan salah satu alat pengemasan standar. Saat ini Anda memiliki
pilihan antara ExtUtils::MakeMaker dan Modul yang lebih independen terhadap platform::Build,
memungkinkan modul untuk diinstal secara konsisten. Saat menggunakan ExtUtils::MakeMaker,
anda dapat menggunakan "make dist" untuk membuat paket Anda. Alat ada untuk membantu Anda membangun
modul dalam gaya yang ramah MakeMaker. Ini termasuk ExtUtils::ModuleMaker dan h2xs. Lihat
juga perlnewmod.

Perizinan
Pastikan modul Anda memiliki lisensi, dan teks lengkapnya disertakan dalam
distribusi (kecuali yang umum dan persyaratan lisensi tidak mengharuskan Anda untuk
memasukkannya).

Jika Anda tidak tahu lisensi apa yang harus digunakan, lisensi ganda di bawah lisensi GPL dan Artistik
(sama seperti Perl itu sendiri) adalah ide yang bagus. Lihat perlgpl dan perlartistic.

UMUM KESALAHAN

Menemukan kembali itu roda
Ada ruang aplikasi tertentu yang sudah sangat, sangat baik dilayani oleh CPAN.
Salah satu contohnya adalah sistem templating, yang lain adalah modul tanggal dan waktu, dan ada banyak
lagi. Meskipun ini adalah ritus peralihan untuk menulis versi Anda sendiri tentang hal-hal ini, tolong
pertimbangkan baik-baik apakah dunia Perl benar-benar membutuhkan Anda untuk mempublikasikannya.

mencoba untuk do terlalu banyak
Modul Anda akan menjadi bagian dari perangkat pengembang. Itu tidak akan, dengan sendirinya, membentuk
seluruh peralatan. Sangat menggoda untuk menambahkan fitur tambahan hingga kode Anda monolitik
sistem daripada satu set blok bangunan modular.

tidak pantas dokumentasi
Jangan jatuh ke dalam perangkap menulis untuk audiens yang salah. Audiens utama Anda adalah
pengembang yang cukup berpengalaman dengan setidaknya pemahaman moderat tentang modul Anda
domain aplikasi, yang baru saja mengunduh modul Anda dan ingin mulai menggunakannya sebagai
secepat mungkin.

Tutorial, dokumentasi pengguna akhir, makalah penelitian, FAQ, dll. tidak sesuai dalam a
dokumentasi utama modul. Jika Anda benar-benar ingin menulis ini, sertakan sebagai sub-
dokumen seperti "My::Module::Tutorial" atau "My::Module::FAQ" dan berikan tautan di
LIHAT JUGA bagian dari dokumentasi utama.

Gunakan perlmodstyle online menggunakan layanan onworks.net