Question Contenu de Source en général ...

Spirit écrit:

Les autres scripts auxquels celui-ci serait lié de façon obligatoire

Je trouve que ce principe alourdi la maintenance de la documentation. Les dépendances devraientt si possible être gérées dynamiquement.
Il manque le chemin d'accès avec du coup une politique d'accés au script, i.e. une arborescence type.
Pour la documentation d'une solution en production et figée je suis d'accord mais rien n'est figé en info...
Spirit écrit:

Une description plus ou moins détaillée de la fonctionnalité du script en cours. Avec pas forcément des détails techniques, sauf si ceux-ci ont une importance particulière.

Le mieux est de faire au plus simple dans l'entête : quel est le traitement, les détails techniques devrait être documenté dans le corps du fichier source
Spirit écrit:

Et pour finir, un historique des modifications avec dates, intervenant et description de la modification.

Le mieux est d'utiliser un gestionnaire de source. Ensuite on peut retrouver ces infos dynamiquement. Dans ce cas les placer en fin de fichier par un tag dédié
Comme ce type d'outil propose le + souvent une visualisation des différences autant lui laisser ce travail
Spirit écrit:

Vous remarquerez que j’ai ici intégré la version (1A) au nom du script

A mon avis les régles de nommages ne sont pas des régles de versionning. C'est à éviter je pense.

Ce type de régles doivent être simple et le moins contraignantes possible sinon elles ne seront pas respectées. A moins que l'organisation la mettant en place dédié une personne au contrôle de ces régles.
Vu que c'est souvent l'urgence qui prédomine en production c'est mal partis...

A propos des constantes.
Autant procéder ainsi :
[code:1]
#Constantes
Set-Variable CACETYPE_ACCESS_ALLOWED -value 0 -option constant -scope Script
[/code:1]
Sinon ton exemple est faux.

Je suis partisant de suivre les régles de nommage du C#. Ensuite quant à préfixer la portée des variables je suis partagé car elles peuvent l'être par $Global: , $Local: ...

Bien sur, il est à noter que la notion de variables n’existe pas vraiment dans PS, puisque se sont en réalité des objets de .NET. Quand on écrit [string], c’est exactement pareil que si l’on écrivait [System.IO.Directory]. On fait toujours référence à la classe d’objet. La séparation dans le source des variables et des objets est donc de plus en plus symbolique.

Je ne suis pas sûr de comprendre ce passage:/
Dans notre contexte, une variable est une notion du langage (code source) et une instance objet est une notion proche du hardware/OS (adresse d'une zone mémoire)
Sinon je peux comprendre à la lecture de ce que tu écris que l'usage de Set-Variable est égale à celui de New-Object.
Une variable référence un objet qui peut être de n'importe quelle classe .NET. L'instance d'objet connait sa classe via ces méta-données.
Etc.
Spirit écrit:

Bon désolé pour toutes ces petites imperfections.

Seul celui/celle qui ne fait rien ne fait pas d'imperfection
Arnaud écrit:

Quand je parlais des bonnes pratiques PowerShell, je pensais à des choses plus précises. Comme par exemple, s'efforcer à utiliser des guillemets simples au lieu des doubles lorsque ce n'est pas nécessaire, vois tu ?

Je pensais aussi à ces préconisations. Mais il faut en donner la/les raisons. Personnellement, au cours de ces 8 dernières années et pour d'autres langages, je me souviens encore de celles qui étaient argumentés mais pas de celle qui ne l'étaient pas.
Je pense qu'on les accepte plus volontier présentées ainsi.
Arnaud écrit:

Et voici un petit Screen de VB.NET.

Je ne pense pas qu'on puisse faire de comparaison entre VB.NET et PS, enfin ça c'est une autre discussion

Quant à la méthode pour soumettre une préconisation d'écriture la création d'un nouveau thread pour chacune d'entre elles est préférable.
On peut suivre une pratique de la méthodologie de développement XP : Faire simple.


Belle initiative !

BatchMan écrit:

Spirit écrit:

Les autres scripts auxquels celui-ci serait lié de façon obligatoire

Je trouve que ce principe alourdi la maintenance de la documentation. Les dépendances devraient si possible être gérées dynamiquement.

Je reviens sur le sujet car ton approche sur ce point n'était pas erroné. Après lecture de ce post on peut adapter le code afin que les dépendances référencées soit vérifiées dans le code au lieu de les placer dans des commentaires :
[code:1]
function local:TestRequiredItem([String[]] $required, [string] $NomItem )
{ #D'après une idée de J.Snoover
# Test si les éléments référencées(Cmdlet, fonction, script) dans le tableau $required existent
#C'est en quelque sorte un contrôle des prérequis à l'exécution d'un script
if (($required -eq $null) -or ($required.count -eq 0))
{ throw \"Le tableau contenant les noms d'éléments à rechercher ne peut être null ou vide.\"}
switch ($NomItem)
{
\"Commande\" {$null=Get-Command $required -ea SilentlyContinue -ev missingRequired
for($I=0; $I -le $missingRequired.count -1; $i++){
Write-Warning \"$NomItem introuvable $($missingRequired[$i].Exception.CommandName)\"
}
if ($missingRequired.Count)
#$($NomItem) = concatenation de variable et d'un ou + caractères
{ throw \"$($NomItem)s introuvables. Le traitement ne peut continuer.\" }
break}
#Pour Test-path missingRequired est renseigné uniquement avec des erreurs irrécupérables
\"Fonction\" {$required|% {if ((Test-Path function:$_ -ea SilentlyContinue -ev missingRequired) -eq $false) {[array]$missingPath +=$_}}
Break}
\"Script\" {$required|% {if ((Test-Path $_ -ea SilentlyContinue -ev missingRequired) -eq $false) {[array]$missingPath +=$_}}
break}
Default {throw \"Cas imprévu : $NomItem\"}
}

for($I=0; $I -le $missingPath.count-1; $i++) {
Write-Warning \"$NomItem introuvable $($missingPath[$i])\"
}
if (($missingRequired.Count -gt 0 ) -or ($missingPath.Count -gt 0))
#$($Item) = concaténation de variable et d'un ou + caractères
{ throw \"$($NomItem)s introuvables. Le traitement ne peut continuer.\" }
}

#J'ai fait le choix de dupliquer le code pour être
#certains que le second argument est correct et simplfier le code dans la function TestRequiredItem
function TestRequiredCommands([String[]] $requiredCommands)
{ #Nom des item requis: TestRequiredCommands \"Test-MyData\", \"Add-MyData\"
TestRequiredItem $requiredCommands \"Commande\"
}

function TestRequiredScripts([String[]] $requiredScripts)
{ #Nom des item requis: TestRequiredScripts \"c:\PS\Scripts\PackageWinform.ps1\"
TestRequiredItem $requiredScripts \"Script\"
}

function TestRequiredFunctions([String[]] $requiredFunctions)
{ #Nom des item requis: TestRequiredFunctions \"c:\PS\Scripts\PackageWinform.ps1\"
TestRequiredItem $requiredFunctions \"Fonction\"
}
[/code:1]
Dans le code du script principal on ajoute ces lignes:
[code:1]
function Get-ScriptDirectory
{ #Renvoi le nom du répertoire d'un script parent, celui appelé sur la ligne de commande.
# By J.Snoover
$Invocation = (Get-Variable MyInvocation -Scope 1).Value
Split-Path $Invocation.MyCommand.Path
}
$ScriptPath = Get-ScriptDirectory

$PckConvertForm = Join-Path $ScriptPath PackageConvert-Form.ps1
TestRequiredScripts $PckConvertForm
#TestRequiredCommands aucune
#TestRequiredFunctions aucune

. $PckConvertForm
[/code:1]
Quant à la recherche dynamiques des dépendances, si on utilise que des appels de ce type
[code:1]
.\MonScript
[/code:1]
Cela reste possible de les retrouver via un parsing puis de les afficher à l'aide de Glee (Graph Layout Execution Engine).
Ce dernier point est à vérifier car je n'ai pas eu le temps faire un proto.