1) Normes de programmation ASP
1.1) Séparation du code :
1.1.1) Séparation au maximum du code ASP du code HTML.
Dans une page idéale, le code html ne devrait contenir que des variables ASP. Non des blocs de code. Bien sûr, cela n'est pas toujours possible. Raison : clarté.
1.1.2) Éviter au maximum la construction du code HTML à l'intérieur du code ASP.
Raison de clarté, de la même façon qu'on évite de mettre du code ASP dans le code HTML.
1.1.3) Éviter de concaténer de longues chaînes en itérant.
Par exemple, préparer l'affichage d'une table HTML en remplissant une variable "string" VB avec les "rows" en bouclant. Raison de clarté, mais surtout de performance. Il n'y rien de plus lourd que de faire des longues boucles qui concatènent des "string". C'est le cas dans tous les langages, mais spécialement dans VB. VB gère très mal la réallocation de la mémoire dans les String et dans les Array. Une seule page qui abuserait légèrement de cette technique peut suffire à geler IIS.



1.1.4) Envisager les stored procédures lorsque le code SQL devient trop complexe.
Sql permet de construire des requêtes dynamiques, et cela est très pratique. Mais n'oublions pas que SQL (transact-sql) est un langage entier en soi. SQL ne se limite pas à des requêtes simples qui tiennent sur 2 lignes. Parfois, ça peut devenir très complexe. Le fait de "construire" le bout de code SQL à exécuter peut devenir tout aussi illisible que de "construire" des bouts de code HTML en ASP. Créer des stored procedure devient alors une bonne solution pour clarifier le code en le séparant.
1.1.5) Pour construire une requête SQL, séparer le plus possible l'ASP du SQL.
Si votre valeur désirée peut être obtenu par sql, n'utilisez pas ASP. Exemple : récupération des valeurs pour l'année en cours : " …… WHERE year(date_creation)=year(getdate()) " et non " ….. WHERE year(date_creation)= " & year(now). Au niveau des dates, ceci permet d'éviter des erreurs de paramètrages différents entre des serveurs.
1.2) Coder proprement :
1.2.1) Libérez la mémoire lorsque vous avez terminé d'utiliser vos objets.
La création d'objets, quels qu'ils soient, demande à IIS de stocker ces objets dans une mémoire à part. IIS garantit de libérer la mémoire à la fin de l'exécution des pages ASP. Cependant, Microsoft n'a jamais réussi à rendre son garbage collector fiable. Du coup, il faut libérer explicitement la mémoire. Le plus tôt est le mieux. Raison : performance.
1.2.2) Les connexions SQL
Fermez explicitement et le plus tôt possible vos connexions SQL.
1.3) Libérer rapidement les ressources :
1.3.1) Libérer les curseurs.
Lorsque vous chercher des données avec un objet Recordset, dépêcher vous de parcourir le recordset et fermez la connexion. Ne faites surtout pas d'opération trop lourdes/longues à l'intérieur d'un bloc de code qui boucle sur un recordSet. Comme par exemple, boucler sur un recordset en envoyant un email à chaque itération. Raison : performance.
1.3.2) Évitez le "placotage" entre le serveur ASP et le serveur SQL.
À chaque fois que vous faites une requête SQL(autant écriture que lecture), le serveur ASP doit faire parvenir la requête par le réseau au serveur SQL. Le serveur SQL la reçoit, la compile, l'exécute, etc. En attendant, le serveur ASP patiente. Si vous avez une suite de 5-6, voire 10 requêtes SQL à exécuter d'un coup, pourquoi ne pas envoyer qu'une seule et unique requête SQL? N'oubliez pas que transact-sql est un langage en soi. Il est autant possible de créer une stored procedure qui contient l'ensemble des requêtes une à la suite de l'autre, que d'écrire carrément tout le bloc à exécuter dans une String ASP. Dans les deux cas, cela évite des pertes de temps à "placoter" sur le réseau. Cela peut devenir significatif dans les pages fortement appelées qui nécessitent une exécution éclair. Raison : performance.
1.3.3) Utilisez les tableaux pour stocker vos données tirées du recordset.
La methode GetRows est équivalente aux itérations du "moveNext" point de vue performance.
1.3.4) Choisissez le curseur le plus léger pour les lectures SQL.
1.4) La validation:
1.4.1) Filtrer les données
Effectuer une validation serrée sur le typage, et sur tout autre critère nécessaire avant d'accepter une donnée. Plus vous êtes sévère, plus vous aurez un contrôle de vos données.
1.4.2) Protéger systématiquement chaque couche contre les données indésirables.
Il existe la couche client (html), la couche IIS (ASP), la couche de données (SQL), ainsi que d'autres couches intermédiaires. Chaque fois qu'un client veut enregistrer une donnée, il appartient au code ASP de vérifier la validité du format de la donnée avant de procéder à l'étape d'insertion dans la couche SQL. À son tour, la couche SQL se doit d'être tout aussi sévère dans l'acceptation de ses données. Il existe une multitude de moyens pour garantir l'intégrité des données stockés dans vos tables SQL. Plus vous serez sévère, plus vous éviterez qu'un programmeur insoucieux insère des données non intègres par manque de vigilance dans son code ASP. Chaque couche, dans un monde idéal, devrait être autonome et intègre.
1.4.3) Formater les données attrapées par l'objet request
Il est inacceptable d'évoluer tout au long d'un programme avec une variable dont on ne connaît même pas le type. Si on croit avoir affaire à un Integer, ce n'est pas à la ligne 249 qu'il faut s'apercevoir qu'il s'agit en fait d'une String non convertible.
1.4.4) Utiliser la fonction formatRequest()
La fonction formatRequest() est un moyen robuste de garantir le typage d'une donnée en VB. C'est un bouclier contre la pollution. Cette fonction ne peut en aucun cas planter, ni laisser passer des types indésirables. Dans le langage VB, où le typage est anarchiste, vaut mieux se protéger des courants d'air.
1.5) Les déclarations globales:
1.5.1) Divisez en functions
Réutilisez vos bouts de codes à l'intérieur de fonctions déclarées dans des includes. Il n'y a pas de raison de réécrire 2 fois le même code dans un programme (ou un site web). Bien sûr, cela est relatif, et cela dépend de la taille du code.
1.5.2) L'autonomie des sous-programmes
Une fonction doit être indépendante dans sa structure et ses données. Une fonction est un sous-programme. Un programme est un bout de code qui peut prendre des paramètres dont il tient compte pour générer un résultat. Il est mal avisé d'utiliser des variables externes à l'intérieur d'une fonction. Une fonction doit s'autosuffire. Seules les données présentes dans son contexte ne devraient être utilisées. Mis à part de rares exceptions comme les constantes globales. Ce point concerne tous les langages, et non juste VB. Une fonction n'est plus portable si elle est dépendante de variables locales.
1.5.3) Donnez des préfixes spécifiques à vos déclarations globales.
Étant donné que l'ASP est un langage primitif, il exige une cohabitation de centaines, voire milliers de fonctions et constantes sous un même contexte. Il faut vivre avec. Deux options s'offrent. On peut limiter au minimum l'inclusion de includes dans une page ASP. Cela ne garantit aucunement que les déclarations n'entreront pas en conflit. La meilleure option est de spécifier un préfixe pour chaque bloc de déclarations, que ce soit pour les constantes ou pour les fonctions. Par exemple, ajouter " C_ " en préfixe aux constantes globales. Cela permet, entre autres, de comprendre rapidement que cette constante est globale, lorsqu'on relit le code.
1.5.4) Placez vos includes dans le même répertoire.
1.5.5) Diviser les includes
N'hésitez pas à diviser vos includes de fonctions en plusieurs includes. Un includes de 10 000 lignes devient illisible. Ce n'est pas une question de performance, mais bien de clarté
1.5.6) Inclure par défaut certains includes
N'hésitez pas à ajouter vos includes qui vous jugerez utile pour l'ensemble du site. Bien sûr, assurez-vous que vous fonctions seront bien utilisée de façon globale. Inutile d'embêter les programmeurs avec des includes qui ne seront utilisés que dans une seule page.
1.6) Les constantes:
1.6.1) Ajoutez le préfixe "C_" devant les déclarations de constantes globales.
Exemple : "C_UNE_CONSTANTE".
1.6.2) Écrivez vos constantes en majuscule.
Bien que cela ne fasse aucune différence réelle lors de l'interprétation du code par IIS, cela rend le code plus clair.
1.6.3) Toute donnée à valeur FIXE doit être déclarée en tant que constante
Toute donnée à valeur FIXE doit être déclarée en tant que constante, dans le haut d'une page, ou dans un include, si cette constante est globale. Dans un programme parfait, aucune donnée dont la valeur a un sens fixe ne devrait être utilisée avec sa valeur directement dans le code. D'abord, c'est moins clair visuellement lorsqu'on relit le code. Ensuite, cela rend la tâche terriblement lourde lorsque la valeur doit être changée, de temps à autre, par un programmeur. Une valeur fixe ne signifie pas qu'elle ne changera jamais!
1.7) La gestion des erreurs:
1.7.1) Gérer les pages d'erreurs ASP d'IIS
La première étape est de gérer soi-même les erreurs ASP les plus communes (500, 404, etc.). On redirige le client vers une page avec un message d'erreur bien encadré, après avoir noté l'erreur dans une BD.
1.7.2) On error resume next?
"On error resume next" ne devrait être utilisé que lorsque bien gérer, de façon localisée. Un "on error resume next" en entête de page est à proscrire. C'est irresponsable et une bombe à retardement. On ne règle pas un problème en jouant à l'autruche.
1.8) 11 Indentation et allure générale du code:
1.8.1) Simplifiez toujours votre code au maximum.
Remettez chacune de vos lignes de codes en question. Chaque ligne doit être justifiée. Un programmeur consciencieux ne tolérera pas 2 lignes de codes où une seule aurait suffi. Bien sûr, cela doit demeurer élégant.
1.8.2) Recherchez toujours la forme la plus élégante pour une ligne de code.
Il y a 100 façons différentes d'écrire certaines lignes de code, mais très peu le font de façon élégante. L'élégance permet une meilleure clarté.
1.8.3) Bien indenter le code, autant html, que le code asp, que le code sql.
Si en regardant votre code, vous constatez l'un des symptômes suivants, posez-vous de sérieuses questions :

-Vous avez une fonction qui excède 100 lignes de code.
-Vous avez un bloc de condition qui excède 100 lignes de code.
-Vous avez des blocs de conditions qui s'imbriquent les uns dans les autres, jusqu'à 4 ou 5 niveaux de profondeur.
1.8.4) Il est totalement absurde de déclarer une fonction à l'intérieur d'un bloc de condition.
Ca n'a aucun sens. Si Vbscript n'était pas si permissif, ça serait carrément interdit à la compilation.
1.8.5) Les includes ASP de fonctions
Les includes ASP qui contiennent du code Vbscript devraient être exclusivement des fonctions. On inclut le include dans l'entête de la page, et on appelle ensuite la fonction désirée à la ligne voulue.
1.8.6) Séparez votre code ASP en blocs de codes homogènes.
Faites toutes vos déclarations en tête de page. Faites ensuite tous vos appels à l'objet request. Ensuite, exécuter les actions les unes à la suite des autres. Tout est toujours plus simple lorsqu'on lit un programme comme un somme de blocs homogènes.
1.8) Option explicit:
1.8.1) À utiliser, non négociable. Point final
1.9) Sécurité:
1.9.1) 16.1 Les includes dans un répertoire protégé.
Les includes d'un site devraient toujours être dans un répertoire à part. Le répertoire devrait être protégé en lecture contre les internautes. Le code source des includes pourrait être lu directement dans le navigateur du client, si appelé. Le fait de nommer les fichiers includes avec l'extension ASP n'est ni une solution valable, ni une façon correcte de régler le problème. L'extension des includes doit être "inc". Une bonne solution pourrait aussi être d'interdire l'exécution des extension "inc" dans IIS.
1.9.2) Protégez vos pages ASP contre les hackers.
Une page mal programmée peut facilement devenir hackable. Par exemple, dans un formulaire HTML, si vous devez passer en paramètre l'Id d'un enregistrement à détruire, assurez-vous que le client ne pourra pas détruire l'enregistrement qu'il veut uniquement en changeant directement l'Id dans l'URL de son navigateur. La meilleure façon de se protéger est de considérer chaque client comme un hacker potentiel qui cherche à bombarder notre système et à trouver des failles. Si vous êtes vous-mêmes capable de hacker votre propre page, c'est qu'elle est imparfaite.
1.9.3) Bémole sur La validation d'un formulaire en DHTML
La validation d'un formulaire en DHTML, c'est envisageable pour ménager le serveur ASP, et pour répondre plus rapidement au client. Mais ca ne vaut STRICTEMENT rien en terme de sécurité et de validité. Une fois les données reçues en ASP, vous devez tout revalider. N'importe quel hacker de 12 ans peut passer à travers une validation javascript standard.
1.10) Le nommage:
1.10.1) Toutes les variables passées en "input" doivent avoir le préfixe " i_ ".
1.10.2) Essayez de groupez vos variables en fonction de leur utilités lorsque vous choisissez vos noms.
Utilisez des préfixes est une bonne formule.
1.11) Le objets d'IIS:
1.11.1) Ne JAMAIS placer d'objet dans des variables de sessions.
C'est la meilleure façon de tuer un serveur.
1.11.2) Les variables d'application pour simuler une cache
Les variables d'application sont excessivement rapides d'accès, et légères. Que ce soit pour stocker des objets, ou de simples variables. Très recommandé pour simuler une cache. Attention toutefois au stockage de tableaux trop grands. L'accès s'en trouverait ralenti et alourdi.
1.12) Les commentaires
1.12.1) Placer une entête détaillant l'évolution de la page :
1.12.2) Placer des lignes de commentaires aux différentes étapes de votre code.
Il est inutile de détailler chaque ligne. Contentez-vous de donner une explication concise des blocs de code plus difficiles à comprendre.
2) Normes de programmation SQL
2.1) Le nommage SQL
2.1.1) Chaque table doit posséder un id unique.
Il existe différentes normes de nommage (id, PK_, no_). L'important est de conserver la même dans toute la BD. Chez Wingowin, nous utilisons id.
2.1.2) Toutes les lettres des noms dans SQL doivent être en minuscules.
2.1.3) Les mots doivent être séparé par un trait surligneur. (underscore : _ )
2.1.4) Les clés étrangères doivent être nommée fk_ suivi du nom de la table visée.
Exemple : " fk_usager ".
2.1.5) Les procédures stockées doivent avoir le préfixe " ps_ ". " sp_ " est à proscrire.
2.1.6) Les views doivent avoir le préfixe " view_ ".
2.1.7) Les fonctions doivent avoir le préfixe "f_".
2.1.8) Mettre tous les noms des objets au singulier.
Permet d'éviter de se poser des questions à savoir si les différents termes dans le nom de la table sont au pluriel ou non. Exemple la table : membre_stat_log_archive. Est-ce membres_stats_logs_archives ou membres_stats_logs_archive, etc.
2.1.9) Prendre toujours un type "int" pour les champs qui servent à une foreign key.
2.1.10) La date de création d'un enregistrement
Ajouter une colonne permettant de connaître la date de création de chaque enregistrement, selon les besoins (quand il peut être intéressant de connaître l'évolution des enregistrements dans une table). Dans la plupart des cas, cette colonne est importante et intéressante. Utilisez le nommage " date_creation " dans chacune de vos tables. Placer la valeur par défaut getdate().
2.1.11) Nommez vos tables de façon à les regrouper.
Si vous avez 3 tables qui concernent la sous-section de publicité, ajoutez un préfixe commun : pub_site, pub_campagne, pub_stats, etc.
2.2) L'intégrité des données SQL
2.2.1) Soyez extrêmement sévère sur le format des données avant de les insérer dans la BD.
L'utilisation de contraintes, triggers et foreign keys sont des bonnes façons de garantir l'intégrité. Plus une BD est sévère, plus elle est en santé. Refusez tout garbage. Ne vous fiez pas sur la bonne volonté des programmeurs ASP. L'administrateur de la BD doit considérer le programmeur ASP comme un intrus qui tente d'insérer des données malsaines. La couche SQL doit s'autosuffir et se protéger par elle-même.
2.2.2) Interdire l'insertion de valeur null lorsque les null ne sont pas admis dans un champ.
2.2.3) Placer une valeur par défaut lorsque possible.
2.3) La performance du server SQL
2.3.1) Optimisez vos requêtes
Un serveur SQL peut-être très rapide. Malgré tout, ménagez-le. Recherchez toujours à construire les requêtes les plus légères, et les moins nombreuses.
2.3.2) Créez des index.
C'est de loin la chose la plus importante côté performance.
2.3.3) Placer le meilleur typage, le plus compressé possible, pour chacun des champs dans la BD.
Exemple : si un champ sert uniquement à placer des valeurs entre 0 et 10, prendre un tinyint et non un int.
2.3.4) Utilisez les stored procédures
Les procédures stockées ont l'avantage d'être précompilées. De plus, à chaque exécution, sql-server conserve le plan d'exécution pré-établi et le réutilise au besoin la prochaine fois. Aussi, les procédures stockées permettent d'enligner une série de requêtes à exécuter d'un seul coup. Cela évite de faire des aller-retour sur le réseau inutilement. Tout cela fait des procédures stockées un atout pour augmenter les performances.
2.3.5) Évitez le «select *»
Vous avez rarement besoin de tous les champs.
2.3.6) Toujours faire l'appel des objets SQL en ajoutant un préfixe devant (le owner).
Exemple d'appelle d'une store : EXEC ownerCI.ps_insert_membre ….
2.3.7) Éviter les views...
Soyez prudents avec les Views. Les views peuvent parfois être très utile. Malgré tout, elles peuvent devenir le pire ennemi de la performance lorsque mal utilisées. Faire un UNION dans une view fait partie des pires choses à faire, surtout lorsque la view risque d'être appelée dans une page ASP en ligne.
2.3.8) Méfiez-vous des UNION en général.
Si vous avez besoin d'en faire, le mieux est de faire vos "select" avec conditions sur chacun des deux tables, et de faire l'union ensuite. L'inverse est beaucoup plus lourd.
2.3.9) Utilisez les Alias.
Évitez de réécrire le nom des tables avec leurs champs. Utilisez des Alias dès que vous avez des champs ambigus et que vous devez spécifier la table. Cela améliore grandement la clarté.
2.4) La sécurité:
2.4.1) Les logins
Les logins de SQL server ne doivent pas avoir de droits d'administrateurs. Limitez au maximum les droits de chaque login. Donnez l'accès à une BD, oui. Mais donner l'accès à toutes les BD du server SQL, non!
2.5) Les jobs SQL:
2.5.1) Les jobs SQL sont la meilleure façon de compiler des données.
Il est absolument inutile de créer des programmes VB ou des pages ASP qui appellent le serveur SQL lorsqu'on désire compiler des données SQL. Les jobs SQL font un travail très propre et ça a l'avantage d'être centralisé.
2.6) Les relations SQL:
2.6.1) Pour garantir l'intégrité des données.
Les relations SQL sont très importantes pour garantir l'intégrité des données. Une BD doit posséder des tables qui sont bien reliées entre elles. Il existe 3 types de relations : 1-1, 1-m, m-n. Assurez-vous de choisir correctement vos types de relations
2.6.2) Structure d'arbre
En principe, un diagramme SQL, représentant les relations entre les tables, ne devraient contenir aucune boucle. La structure doit être celle d'un arbre. Il peut y avoir des exceptions.
3) Normes de programmation HTML
3.1) Séparation du code:
3.1.1) Séparation au maximum du code ASP du code HTML
Séparation au maximum du code ASP du code HTML. Dans une page idéale, le code html ne devrait contenir que des variables ASP. Non des blocs de code. Bien sûr, cela n'est pas toujours possible. Raison : clarté.
3.2) Diviser du code
3.2.1) Utilisez les CSS avec les classes plutôt que de répéter toujours le style dans les tags.
3.2.2) Divisez le code en pages pour utiliser la cache.
Il est toujours préférable de diviser une page HTML en feuilles de styles, d'html, de scripts. C'est plus clair, et cela évite de recharger les définitions des styles et des scripts à chaque nouvelle page que le client visite. Les feuilles de styles demeurent dans la cache du client, tout comme les scripts.