İyi bilinen PowerShell kodlama kuralları var mı?

PowerShell'de programlama yaparken iyi tanımlanmış kurallar var mı?

Örneğin, uzun vadede korunması gereken komut dosyalarında şunları yapmamız gerekir:

• Gerçek cmdlet adını mı yoksa takma adını mı kullanıyorsunuz?
• Cmdlet parametre adını tam veya yalnızca kısmen ( dir -Recursekarşı dir -r) belirtin
• (Tırnak içine alın do cmdletler için dize argümanlarını belirtirken New-Object 'System.Int32'karşıNew-Object System.Int32
• İşlevleri ve filtreleri yazarken parametre türlerini belirtir misiniz?
• (Resmi) doğru davaya cmdlet'ler yazar mısınız?
• Gibi anahtar kelimeler için BEGIN...PROCESS...ENDbunları yalnızca büyük harfle mi yazıyorsunuz?

Görünüşe göre MSDN, PowerShell için kodlama kuralları belgesinden yoksunken, bu belge örneğin C # için var.

Robert Harvey bazı iyi resmi bağlantılara atıfta bulundu. Daha az resmi bir belge aracılığıyla düşüncelerim şöyle olurdu:

Gerçek cmdlet adını mı yoksa takma adını mı kullanıyorsunuz?

Diğer adı yalnızca tam addan daha açıksa kullanın. Örneğin, çoğu insanın bir komut dosyasında önceki deneyime göre daha açık dirveya lsdaha net bulacağını düşünüyorum Get-ChildItem(örneğin, bir PowerShell betiği yazan herkes DOS toplu komut dosyalarında veya Unix komut dosyalarında bu iki defadan birine sahiptir).

Cmdlet parametre adını tam veya yalnızca kısmen belirtin (dir -Recurse vs. dir -r)

Bir komut dosyasında, adı tam olarak heceleyebilirim çünkü (yukarıdaki örnekten farklı olarak) daha kısa anahtarın gerçekten hecelemekten daha açık olacağı bir zaman düşünemiyorum . Daha kısa anahtar adları yazmayı kaydetmek içindir. Bir komut satırında bu zorunludur. Bir komut dosyasında, ekstra tuş vuruşları okunabilirlik ve bakım kolaylığı için buna değer.

Cmdlet'ler için dize bağımsız değişkenleri belirtirken, bunları tırnak işaretleri içine alırsınız (New-Object 'System.Int32' ve New-Object System.Int32

Kod içinde okurken dize argümanlarını tırnak içine almak çok daha net görünüyor, bu yüzden onları dahil ederim.

İşlevleri ve filtreleri yazarken parametre türlerini belirtir misiniz?

Sadece tercüman için belirsizliği gidermek için buna ihtiyaç duyulduğunda (ki bu olur). Her şeyi yazıp denemek istiyorsanız, C # komut satırı uygulamalarını da yazabilirsiniz (bu her zaman kötü bir şey değildir, ancak komut dosyasıyla elde ettiğiniz zaman tasarrufunu olumsuz etkiler).

(Resmi) doğru davaya cmdlet'ler yazar mısınız?

Sen gerekir . Ben genellikle do. Aceleye geldiğinde sözdizimsel olarak önemli olmadığı için davada biraz gevşek olduğum biliniyordu.

BEGIN ... PROCESS ... END gibi anahtar kelimeler için yalnızca büyük harfle yazıyor musunuz?

Hayır. Bu FORTRAN değil. Çoğu insan bulmak düşünmek beginveya Begindaha okunabilir BEGIN. Tüm başlıkları çevrimiçi bağırmak ve programın en sıradan bölümlerini bağırmakla ilişkilendirmemizin bir nedeni, dikkatini en az önemli olan kısımlara çekerek okunabilirliği engeller.

Yol gösterici okunabilirlik olmalıdır. Komut dosyaları, doğaları gereği hızlı ve kirli programlar olarak, salt yazılan koda yönelirler. Siz ve ekibinizin senaryoyu altı ay içinde anlayabilmeniz için her kararınız alınmalıdır. Kodunuza bakarken kendinizi kendi ayakkabılarınızdan çıkarmaya çalışın ve şu soruyu sorun: "Bu işe bir hafta önce başlamış olsaydım (ve genel kültüre gerçekten aşılanmamışsa) bunun aydınlatıcı yazılma şeklini bulur muydum veya kafa karıştırıcı mı? "

Microsoft, çok iyi bir Cmdlet Geliştirme Yönergeleri seti yazdı ve yayınladı

Alıntı:

Bu bölümdeki konular, iyi biçimlendirilmiş cmdlet'leri üretmek için kullanabileceğiniz geliştirme yönergeleri sağlar. Windows PowerShell çalışma zamanı tarafından sağlanan ortak işlevsellikten yararlanarak ve bu yönergeleri izleyerek, en az çabayla sağlam cmdlet'ler geliştirebilir ve kullanıcıya tutarlı bir deneyim sağlayabilirsiniz. Ayrıca, ortak işlevsellik yeniden test gerektirmediği için test yükünü azaltabilirsiniz.

Bu bölümde

• Gerekli Geliştirme Yönergeleri
• Kesinlikle Teşvik Edilmiş Kalkınma Kılavuzları
• Danışma Geliştirme Yönergeleri

Bu yönergeler herhangi bir dil ile sınırlı değildir (bir dilden bahsetmezler) ve PowerShell'de Cmdlet'ler yazarken mükemmel şekilde uygulanabilir.

Bu yönergeleri kullanmak, net, keşfedilebilir, kullanılabilir ve tekrar kullanılabilir Cmdlet'ler yazmanıza yardımcı olacaktır. Bu yönergeleri izleyerek birkaç PowerShell modülü oluşturduktan sonra zor olmadığını görüyorum ve daha iyi bir PowerShell geliştiricisi olmamı sağladı. Bu beceri, basit komut dosyaları yazarken de doğrudan kullanılabilir.

İkinci cevap olarak; Kullanabileceğiniz PSScriptAnalyzer kodunuzu doğrulamak için modül.

Invoke-ScriptAnalyzer -Path .

Bir kural kümesi kullanarak kod analizine dayanır. Kod tasarımını doğrular ve kodunuzdaki birçok küçük sorunu tespit etmenize yardımcı olur.

Tasarım ve kalite sorunlarını yakalamak için bunu yapılarımıza dahil ettik (modüller için özel bir depo kullanıyoruz).

İlginizi çekiyorsa, bu modül ayrıca bir PowerShell kod biçimlendiricisi (birden fazla stil kullanabilir) içerir, böylece bunu kod düzenini standartlaştırmak için de kullanabilirsiniz.

@ Oɔɯǝɹ'nun cevabındaki dokümanlar, eğer biraz teğet bir kaynaksa iyidir.

Yaşlanan PowerShell ISE'sini değiştirmesi planlanan Visual Studio Code'u kullanır ve ardından en azından kısmen Resmi Olmayan PowerShell En İyi Yöntemleri ve Stil Kılavuzu'na dayanan çeşitli biçimlendirme seçenekleri içeren VS Code PowerShell uzantısını yüklerseniz . Hem VS Kodu hem de PowerShell uzantısı Microsoft tarafından yönetilir, bu yüzden resmi olmayan bir kılavuz olabileceği kadar resmi.

Belirttikleri her şeye katılmıyorum. Örneğin, gerekli değilse noktalı virgüllerin beklendiği PHP, Java, C # ve SQL'den geliyorum. Kod onlarsız bana yanlış geliyor, bu yüzden onları dahil ediyorum. Bir olsaydı #requires SemicolonTerminatorben bir çizgi kırma boşluk konusunda endişe gerekmez yüzden script'lerime çoğunda etkinleştirmek istiyorum. Kaçan satırbaşı ve diğer VB-izmlerinden nefret ediyorum.

Bunların geri kalanı benim görüşüm:

Gerçek cmdlet adını mı yoksa takma adını mı kullanıyorsunuz?

Açık olun. Kaydedilmiş bir komut dosyasında asla takma ad kullanmayın; varsayılan bir takma ad bile. Bir kullanıcının varsayılan takma adları değiştirmesini engelleyen hiçbir şey yoktur. Değişmez olduklarını varsaymak daha güvenlidir.

Cmdlet parametre adını tam veya yalnızca kısmen belirtin (dir -Recurse vs. dir -r)

Yine, açık olun. Tam parametre adları en iyi ileri uyumluluğa sahiptir. -rbugün açık olabilir, ancak bir komutun gelecekteki sürümlerinin yeni parametreler eklemesini engelleyen hiçbir şey yoktur. Bir IDE (ISE veya VS Kodu) kullanacaksınız. Ctrl+ SpaceTuşuna basın ve bu parametreyi otomatik tamamlayın.

Not ls -r olduğu belirsiz. -ReadOnlyparametresinin başka bir parametresidir Get-ChildItem.

Cmdlet'ler için dize bağımsız değişkenleri belirtirken, bunları tırnak işaretleri içine alırsınız (New-Object 'System.Int32' ve New-Object System.Int32

Genel olarak, tırnak işaretleri yalnızca gerektiğinde kullanılmalıdır (örn., New-Object -TypeName 'System.Collections.Generic.HashSet[System.Int32]'Mümkün olduğunda tek tırnak kullanın ve tek tırnakları kapsüllemek veya değişkenleri gömmek gerektiğinde yalnızca tırnak işaretleri kullanın.

İşlevleri ve filtreleri yazarken parametre türlerini belirtir misiniz?

Özellikle aynı parametreye sahip çok çeşitli tipleri kabul etmem gerekmiyorsa ve tek tek parametre setleri yazmak istemediğimde genellikle yaparım.

(Resmi) doğru davaya cmdlet'ler yazar mısınız?

Pascal davası. Evet.

BEGIN ... PROCESS ... END gibi anahtar kelimeler için yalnızca büyük harfle yazıyor musunuz?

Ben gibi ifadeler, operatörler ve dil yapıları gördüm Begin, If, ForEach, -NotInyanı sıra begin, if, foreach, -notin. Şahsen, küçük harf tercih ediyorum ve Pascal durumu olarak komutları bırakıyorum, ancak ikisi de eşit derecede yaygın.

Diğerleri:

• Her zaman parametreleri belirtin. Konumsal düzene güvenmeyin. New-Object -TypeName System.Int32bitti New-Object System.Int32. Bunun üzerinde anlaşılıp anlaşılmadığını bilmiyorum, ama yine de, genel olarak "açık olun" fikrini destekliyor gibi görünüyor.

• Bir modül yazıyorsam, ile belirtilen standart fiilleri kullanıyorum Get-Verb. Ancak, bu liste son derece dardır, bu yüzden sadece kendim çalışacağım komut dosyaları için tek başına komut dosyası adları kullanmaz. Genel fiil listesindeki sorun, içine yönelmesidir Get-ScriptForSpecificPurposeNoNotThatOneTheOtherOne.ps1. Bir PDF dosyasındaki belirli sayfaları ayıklayan bir komut dosyası yazıyorsam, çağırmıyorum Get-ExtractedAccountPDFPages.ps1. Ben arıyorum Extract-AccountPDFPages.ps1. Bir programın kendisi olarak çalışan ve çok doğası gereği modüler olması amaçlanmamış bir komut dosyasının keşfedilebilirliğinden endişe etmiyorum.

• Daha okunabilir, daha somut veya daha bakım yapılabilir olduğunda kuralları çiğneyin.

Yıllar boyunca değişkenler, fonksiyonlar vb. İçin çok kelimeli adlar yazmanın çeşitli yolları vardır.

PROGRAMFORSORTINGLOTSOFTHINGS okumak zor.

PROGRAM_FOR_SORTING_LOTS_OF_THINGS biraz daha kolay.

program_for_sorting_lots_of_things henüz daha kolay.

ProgramForSortingLotsOfThings alt çizgiyi ortadan kaldırır ve okunabilirliği korur. Powershell bunu çoğunlukla yapıyor.