Apakah ada konvensi pengkodean PowerShell yang terkenal?

Apakah ada konvensi yang terdefinisi dengan baik saat pemrograman di PowerShell?

Misalnya, dalam skrip yang harus dipertahankan jangka panjang, apakah kita perlu:

• Gunakan nama cmdlet asli atau alias?
• Tentukan nama parameter cmdlet secara penuh atau hanya sebagian ( dir -Recursedibandingkan dir -r)
• Saat menentukan argumen string untuk cmdlet, Anda menyertakannya dalam tanda kutip ( New-Object 'System.Int32'versusNew-Object System.Int32
• Saat menulis fungsi dan filter, apakah Anda menentukan jenis parameter?
• Apakah Anda menulis cmdlet dalam case (resmi) yang benar?
• Untuk kata kunci seperti BEGIN...PROCESS...ENDapakah Anda menulisnya hanya dalam huruf besar?

Tampaknya MSDN tidak memiliki dokumen konvensi pengkodean untuk PowerShell, sementara dokumen tersebut ada misalnya untuk C #.

@Robert Harvey mereferensikan beberapa tautan formal yang bagus. Dengan dokumen yang kurang formal, pikiranku adalah:

Gunakan nama cmdlet asli atau alias?

Hanya gunakan alias jika lebih jelas dari nama lengkap. Sebagai contoh, saya pikir kebanyakan orang akan menemukan diratau lslebih jelas dalam skrip daripada Get-ChildItemberdasarkan pengalaman sebelumnya (misalnya pada dasarnya siapa pun yang menulis skrip PowerShell memiliki salah satu dari dua kali itu dalam skrip batch DOS atau skrip Unix).

Tentukan nama parameter cmdlet secara penuh atau hanya sebagian (dir -Recurse versus dir -r)

Dalam sebuah skrip, saya akan mengeja sepenuhnya nama karena (tidak seperti contoh di atas) saya tidak dapat memikirkan waktu di mana saklar yang lebih pendek sebenarnya lebih jelas daripada mengeja. Nama sakelar yang lebih pendek adalah menyimpan pengetikan. Pada baris perintah, ini sangat penting. Dalam sebuah skrip, penekanan tombol ekstra sangat layak untuk dibaca dan dirawat.

Ketika menentukan argumen string untuk cmdlet Anda menyertakannya dalam tanda kutip (New-Object 'System.Int32' versus New-Object System.Int32

Menutup argumen string dalam tanda kutip tampak jauh lebih jelas ketika membaca kode, jadi saya akan memasukkannya.

Saat menulis fungsi dan filter, apakah Anda menentukan jenis parameter?

Hanya ketika ada kebutuhan untuk menyelesaikan ambiguitas penerjemah (yang memang terjadi). Jika Anda akan mencoba dan mengetikkan segala sesuatu, Anda sebaiknya pergi dan menulis aplikasi baris perintah C # (yang tidak selalu merupakan hal yang buruk, tetapi meniadakan penghematan waktu yang Anda dapatkan dengan skrip).

Apakah Anda menulis cmdlet dalam case (resmi) yang benar?

Anda harus . Biasanya saya lakukan. Ketika tergesa-gesa, saya diketahui sedikit lemah dalam kasus ini karena tidak penting secara sintaksis.

Untuk kata kunci seperti MULAI ... PROSES ... AKHIR Anda menulisnya dalam huruf besar saja?

Tidak. Ini bukan FORTRAN. Saya pikir kebanyakan orang menemukan beginatau Beginlebih mudah dibaca daripada BEGIN. Ada alasan kami mengaitkan semua batasan dengan berteriak secara online dan meneriakkan bagian paling biasa dari program menghalangi pembacaan dengan menarik perhatian seseorang ke bagian yang paling penting.

Kepala sekolah harus keterbacaan. Skrip, pada dasarnya sebagai program cepat dan kotor, membelok ke arah kode hanya-tulis. Setiap keputusan Anda harus dibuat untuk memastikan bahwa Anda dan tim Anda masih dapat memahami skrip dalam enam bulan. Cobalah untuk melepaskan diri dari sepatu Anda sendiri ketika melihat kode Anda dan tanyakan pertanyaan ini: "jika saya telah memulai pekerjaan ini seminggu yang lalu (dan karena itu tidak benar-benar diindoktrinasi ke dalam budaya umum) akankah saya menemukan cara ini ditulis menerangi atau membingungkan? "

Microsoft telah menulis dan menerbitkan seperangkat Pedoman Pengembangan Cmdlet yang sangat baik

Kutipan:

Topik di bagian ini memberikan panduan pengembangan yang dapat Anda gunakan untuk menghasilkan cmdlet yang terbentuk dengan baik. Dengan memanfaatkan fungsionalitas umum yang disediakan oleh runtime Windows PowerShell dan dengan mengikuti panduan ini, Anda dapat mengembangkan cmdlet yang kuat dengan upaya minimal dan memberi pengguna pengalaman yang konsisten. Selain itu, Anda akan mengurangi beban pengujian karena fungsi umum tidak memerlukan pengujian ulang.

Di bagian ini

• Pedoman Pengembangan yang Diperlukan
• Pedoman Pengembangan yang Sangat Didorong
• Pedoman Pengembangan Penasihat

Panduan ini tidak terbatas pada bahasa apa pun (mereka tidak menyebutkan bahasa), dan sangat berlaku saat menulis Cmdlet di PowerShell.

Menggunakan pedoman ini akan membantu Anda menulis Cmdlet yang jelas, dapat ditemukan, dapat digunakan, dan digunakan kembali. Saya menemukan setelah membuat beberapa modul PowerShell mengikuti panduan ini tidak sulit, dan membantu saya menjadi pengembang PowerShell yang lebih baik. Keterampilan itu langsung dapat digunakan saat menulis skrip sederhana juga.

Sebagai jawaban kedua; Anda dapat menggunakan modul PSScriptAnalyzer untuk memvalidasi kode Anda.

Invoke-ScriptAnalyzer -Path .

Ini didasarkan pada analisis kode, menggunakan suatu aturan. Ini akan memvalidasi desain kode, dan akan membantu Anda mendeteksi banyak masalah kecil dalam kode Anda.

Kami memasukkannya ke dalam build kami (kami menggunakan build dan repositori pribadi untuk modul), untuk menangkap masalah desain dan kualitas.

Jika Anda tertarik, modul ini juga berisi pemformat kode PowerShell (yang dapat menggunakan banyak gaya), sehingga Anda dapat menggunakannya untuk membakukan tata letak kode juga.

Dokumen dalam jawaban @ o are adalah sumber yang baik, jika agak tangensial.

Jika Anda menggunakan Visual Studio Code, yang direncanakan untuk menggantikan PowerShell ISE yang menua, dan kemudian instal ekstensi VS Code PowerShell , yang mencakup beberapa opsi pemformatan yang setidaknya sebagian didasarkan pada Panduan Praktik Terbaik dan Gaya Panduan PowerShell . Baik VS Code dan ekstensi PowerShell dikelola oleh Microsoft, jadi ini sama resminya dengan panduan tidak resmi.

Saya tidak setuju dengan semua yang mereka nyatakan. Misalnya, saya berasal dari PHP, Java, C #, dan SQL di mana titik koma diharapkan jika tidak diperlukan. Kode terlihat salah bagi saya tanpa mereka, jadi saya memasukkannya. Jika ada #requires SemicolonTerminatorsaya akan mengaktifkannya pada sebagian besar skrip saya jadi saya tidak perlu khawatir tentang spasi putih melanggar garis. Saya benci melarikan diri kembali kereta dan VB-isme lainnya.

Sisanya adalah pendapat saya:

Gunakan nama cmdlet asli atau alias?

Bersikaplah jelas. Jangan pernah menggunakan alias dalam skrip yang disimpan; bahkan alias default. Tidak ada yang menghentikan pengguna untuk mengubah alias default. Lebih aman untuk menganggap mereka tidak berubah.

Tentukan nama parameter cmdlet secara penuh atau hanya sebagian (dir -Recurse versus dir -r)

Sekali lagi, jadilah ambigu. Nama parameter lengkap memiliki kompatibilitas maju terbaik. -rmungkin tidak ambigu hari ini, tetapi tidak ada yang menghentikan versi masa depan dari suatu perintah untuk memperkenalkan parameter baru. Anda akan menggunakan IDE (baik ISE atau VS Code). Tekan Ctrl+ Spacedan lengkapi parameter itu secara otomatis.

Perhatikan bahwa ls -r ini ambigu. -ReadOnlyadalah parameter lain dari Get-ChildItem.

Ketika menentukan argumen string untuk cmdlet Anda menyertakannya dalam tanda kutip (New-Object 'System.Int32' versus New-Object System.Int32

Secara umum, tanda kutip hanya boleh digunakan bila perlu (mis New-Object -TypeName 'System.Collections.Generic.HashSet[System.Int32]'. , Gunakan tanda kutip tunggal jika Anda bisa, dan hanya tanda kutip ganda saat Anda perlu merangkum tanda kutip tunggal atau perlu menyematkan variabel.

Saat menulis fungsi dan filter, apakah Anda menentukan jenis parameter?

Saya biasanya melakukannya, kecuali saya secara khusus perlu menerima berbagai jenis dengan parameter yang sama dan tidak ingin menulis set parameter individu.

Apakah Anda menulis cmdlet dalam case (resmi) yang benar?

Kasus pascal. Iya.

Untuk kata kunci seperti MULAI ... PROSES ... AKHIR Anda menulisnya dalam huruf besar saja?

Saya telah melihat laporan, operator, dan konstruksi bahasa sebagai Begin, If, ForEach, -NotInserta begin, if, foreach, -notin. Secara pribadi, saya lebih suka huruf kecil dan meninggalkan perintah sebagai huruf Pascal, tetapi keduanya sama-sama umum.

Lainnya:

• Selalu tentukan parameter. Jangan mengandalkan pesanan posisional. New-Object -TypeName System.Int32selesai New-Object System.Int32. Saya tidak tahu apakah itu disetujui, tetapi, sekali lagi, tampaknya mendukung gagasan umum "menjadi tidak ambigu".

• Jika saya menulis modul, saya menggunakan kata kerja standar yang ditunjukkan oleh Get-Verb. Daftar ini sangat sempit, namun, nama skrip yang berdiri sendiri untuk skrip yang hanya saya sendiri yang akan sering jalankan tidak. Masalah dengan daftar kata kerja generik adalah bahwa ia cenderung ke arah Get-ScriptForSpecificPurposeNoNotThatOneTheOtherOne.ps1. Jika saya menulis skrip yang mengekstrak halaman tertentu dari file PDF, saya tidak menyebutnya Get-ExtractedAccountPDFPages.ps1. Saya menyebutnya Extract-AccountPDFPages.ps1. Saya tidak khawatir tentang kemampuan menemukan script yang berjalan sebagai program itu sendiri dan tidak dimaksudkan untuk bersifat modular.

• Langgar aturan saat lebih mudah dibaca, lebih konkret, atau lebih bisa dipelihara.

Selama bertahun-tahun telah ada berbagai cara untuk menulis nama multi-kata untuk variabel, fungsi, dll.

PROGRAMFORSORTINGLOTSOFTHINGS sulit dibaca.

PROGRAM_FOR_SORTING_LOTS_OF_THINGS sedikit lebih mudah.

program_for_sorting_lots_of_things lebih mudah.

ProgramForSortingLotsOfThings menghilangkan garis bawah dan mempertahankan keterbacaan. Powershell melakukan ini untuk sebagian besar.