Aller au contenu
Anarchick

La bienséance en skript

Messages recommandés

dBonjour, ce sujet s'adresse aux personnes disposant déjà des bases en skript et qui souhaite s'améliorer dans leur méthodologie

 

Règle de nomenclature

{_nameofvariable} ou {_name.of.variable} ou {_nameOfVariable}

A défaut de retrouver le sujet de la personne qui avait rédiger tout un article dessus je vous renvoie vers cette page

Contenu masqué

    Réagissez ou répondez à ce message afin de consulter le contenu masqué.

Les noms des variables doivent donc être attachés en commençant par une minuscule et les mots suivant doivent commencer par une majuscule en étant attaché au précédent , donc {_nameOfVariable},

Pour ce qui est des fonctions la règle devrait être la même que pour les methods() mais il y a juste un petit problème qui se pose avec skript-mirror, "Comment faire la distinction entre une méthode java et une fonction skript ?" pour le coup je suggère que toute les premières lettres du nom d'une méthode commence par une majuscule (n'hésitez pas à donner votre avis)

La bonne méthode pour définir une variable

{player.level.%player%} , ça vous plait ? moi ça me donne envie de m’arracher les yeux !

Pourquoi ? Car plusieurs problèmes se pose : On peux oublier de supprimer des variables qu’on utilise plus, lorsque l’on souhaite supprimer toutes les informations concernant un joueur c’est plus que pénible d’utiliser cette méthodologie, et enfin ce n’est absolument pas le plus optimal pour un système de top/flop par exemple.

Ma recommandation : {%uuid of player%::level} , {%uuid of player%::{@title}::homes::*}, {{@title}::locations::*} , en gros utiliser les variables liste ! C’est vraiment très pratique et plus complet que les variables simples. Le plus gros avantage est ceci delete {%uuid of player%::*}

Bonus : j’ai écris {@title} , vous aurez donc comrpis que j’utilise une « option » , j’aime bien faire ça pour définir quel script utilise quel variable et ainsi éviter tout conflit entre scripts

Bonus 2 : A l’heure ou j’écris il y a un problème avec la version Skript-2.4Beta8 , qui bug avec function {@title}Xp(player: player) , mais j’ai déjà signalé le bug et il devrait être corrigé un jour où l’autre.

Variable local ou global ou yaml ou SQL ?

La règle est simple, le fichier variables.csv doit pourvoir être supprimé sans que cela ne casse quoi que ce soit après un redémarrage, pourquoi ? Car il arrive parfois qu’un problème persiste alors que le code est correct, et cela peut être la cause de l’oubli de suppression d’une variable (ce cas se présente principalement avec les variables de type liste {::*} )

Pour éviter ce phénomène il faut privilégier les variables locales (qui en plus ne s’écrivent pas dans le fichier .csv donc gain de temps), et les variables globales doivent êtres définis lors d’un événement tel que le on load:  ou lors de l’exécution d’une commande ou …

Dans quel cas utiliser les fichiers yaml (ou autre type de fichier textuel) ? Je recommande ce type de fichier pour tout ce qui est lié à la sauvegarde de statistique ou de données concernant le joueur ou le serveur qui doivent persister après l’extinction du serveur. L’utilisation de l’addon Skript-yaml sera nécessaire et pour ceux qui se le demande, oui c’est plus long au chargement mais cette addon a la particularité de ne pas passer son temps à aller chercher l’information dans le fichier, une fois que le fichier est chargé il est enregistré dans la RAM ce qui le rend rapide d’accès. 

EDIT : Comme l'indique Kilterra dans les commentaires, il y a un ralentissement du à l'accès à ce ficher, voici la technique que j'utilise pour palier à ce problème :

Contenu masqué

    Réagissez ou répondez à ce message afin de consulter le contenu masqué.

Une fois fait je peux oui ou non décharger le fichier yml de la ram

Le cas du SQL : C’est très sympathique mais aussi très pénible à utiliser, entre latence, baisse de performance, code à rallonge, perte de données, base de données payante, problème de configuration réseau, … Bref, c’est malheureusement une vraie galère bien que l’idée soit bonne. Recommandé uniquement pour les personnes qui gère un site web utilisant la même base de donnée SQL.

Rédiger en français ou en anglais ou autre ?

Souvent je vois du code avec des nom de variable comme {joueurs::*} ou {niveauJoueur.%player%} , alors je suis d’accord que nous sommes sur un forum français et que nous sommes francophones MAIS il ne faut pas oublier que la plus grosse communauté Skript est anglophone et que c’est chez eux qu’il y a les « skripteur » les plus talentueux , donc si vous avez un jour besoin de demander de l’aide sur le forum SkUnity ou les différents discords anglophone il est préférable de rédiger les noms de variables en ANGLAIS , car oui vous avez bien fait correspondre votre nom français avec l’utilisation que vous faite de votre variable et ça aide beaucoup pour comprendre rapidement votre code, mais si vous avez besoin d’aide de la part d’un anglophone ça peut lui un poser problème de compréhension et il ne vous répondra peut être pas. Imaginer on fait l’analogie avec des écritures cyrilliques ou des Kanji, là ça devient très complexe car en plus la personne qui souhaite vous aider ne pourra même pas utiliser les mêmes caractères que vous pour définir une nouvelle variable.

Conclusion : LES NOMS DE VARIABLES DOIVENT ÊTRE ÉCRIT EN ANGLAIS

PS : Les commentaires doivent être écrits si possible dans la langue du forum sur lequel vous souhaitez partager votre script. Voir même en FR et ANG en même temps pour les courageux !

L’optimisation poids/lisibilité/évolutivité/CPU/RAM

Lorsque tu code (peu importe le langage), ne te dis pas « ça fonctionne donc je n’y touche plus », c’est une mauvaise façon de réfléchir, si l’on ne fait pas d’effort pour optimiser son code on ne progresse pas ! Il existe différentes façons d’optimiser et certaines sont compatibles les uns avec les autres, le tout c’est d’identifier ce dont on a besoin.

Par exemple mon projet btooom est tellement conséquent qu’il m’impose de faire un code extrêmement optimisé pour le CPU/RAM mais à défaut il est très peu lisible et son évolutivité me demande parfois de tout réécrire. Mais je ne partage pas ce code donc ce n’est pas gênant. (En même temps aucun code n'est en double, tous mes scripts sont liés les uns aux autres dans le but de réduire le plus possible la consommation des ressources matériel ce qui veut dire que pour identifier une erreur c'est un véritable labyrinthe dont je suis le seul à connaitre les recoins)

Et pour mon autre projet de serveur survie c’est totalement différent, je fais un code orienté sur la lisibilité et surtout l’évolutivité, mais j’optimise moins les ressources CPU/RAM (J'ai du code en double car chacun de mes scripts sont totalement indépendant et non interférant avec les autres), par contre ça me permettra de potentiellement partager mes scripts.

Tout ce que j’ai à dire dans cette rubrique c’est qu’il faut bien réfléchir en amont à comment doit être penser son code en mettant toute sa bonne volonté pour l'optimiser le plus possible.

 

Petites astuces pour optimiser vos codes :

Quand je dis optimiser vos codes ça ne veut pas seulement dire "réduire la taille de son code" , absolument pas ! Parfois un code plus long est plus optimisé qu'un petit code ! Ce qui est effectivement commun à toutes les méthodes d'optimisation c'est de réduire la taille du code MAIS de façon logique pour enlever ce qui est inutile sans impacter les performances. L'optimisation passe souvent par une refonte TOTALE du code d'origine afin de trouver un algorithme plus efficace pour faire la même chose. L'optimisation c'est par exemple de passer d'une technologie de réseau GSM 3G à 4G puis 5G, ou bien de réduire la finesse de gravure des processeurs de 14nm à 7nm, ou encore Skript-yaml ! Et oui, la particularité de skript-yaml par rapport à skUtilities c'est qu'il enregistre le fichier dans la ram et ainsi il n'a pas besoin d'aller le chercher sur le disque de stockage à chaque fois ! un gain de temps considérable pour la même fonctionnalité ! Et je suis d'accord, c'est bien jolie de vous dire d'optimiser vos code mais sans vous dire réellement comment ... bah en faite on apprend à optimiser avec l'expérience, en regardant le code des autres, en demandant des conseilles, en faisant des tests, en se tenant à jour des ajouts d'une nouvelle version d'un plugin et surtout en se creusant la tête !!!

Révélation

Anecdote : Pour Btooom j'ai un code qui simule un gaz toxique sur 1000 blocs, un de mes tous premiers code d’ailleurs, très optimisé en terme de code brut mais toujours trop demandeur de ressource CPU et RAM, il faisait baisser le tps du serveur comme pas possible, et il m'a fallut 1 an avant de trouver une solution ! J'ai supprimé totalement mon code et développé un algorithme qui n'avait absolument rien à voir. Au final mon nouveau système me permet d'avoir 5000 blocs de gaz sans faire baisser le tps, le tout pouvant exploser d'un coup avec seulement 1 seconde de lag ! Bref tout ça pour dire qu'il suffit de se creuser la tête et qu'il faut TOUJOURS se poser cette fameuse question "Est-ce que je peux faire mieux ?" (spoiler : La réponse est OUI)

 

Maintenant je vous invite à proposer des exemples de code (basique ou complexe tant qu'il ne sont pas long) qui peuvent être optimisé afin de donner des idées :

Révélation

 

Révélation

 

Révélation

 

Révélation

 

Révélation

 

Pour cet exemple là, l'optimisation se fait au niveau des ressources CPU. En effet loop tous les blocs dans un chunk demande beaucoup de ressources alors que si l'on regarde dans l'API Spigot il existe une manière moins gourmande. Ça demande d'écrire plus de code, de connaître le java et d'utiliser skript-mirror mais le résultats est là !

Contenu masqué

    Réagissez ou répondez à ce message afin de consulter le contenu masqué.

PS: Ce code nécessite une version récente de Spigot et il n'y a pas la partie du code qui enregistre les changements apporté à un chunk !

 

 

Modifié par Anarchick
suite au commentaire de Kilterra
  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites
à l’instant, Kilterra a dit :

Salut,
Plutôt intéressant même si il y a quelques parties pour lesquels je ne suis pas d'accord.

 

Lesquels ? Tu peux donner ton opinion ça peut être intéressant d'avoir un autre point de vue

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 13 heures, Kilterra a dit :

Tout d'abord, au niveau des variables listes et autres.
Utiliser les variables listes n'est pas LA solution. Parfois je suis d'accord qu'il vaut mieux les utiliser mais à d'autres moments il vaut mieux passer par des variables simples. Comme par exemple une simple variable {chatOn} ça ne sert à rien d'utiliser une variable pour cela.

Ensuite, il ne faut pas toujours utiliser les fichiers yaml pour sauvegarder des variables qui doivent résister à l'extinction du serveur car même si skript-yaml est l'addon le plus optimisé il ne reste pas moins que charger un fichier en mémoire coûte beaucoup en termes de ressources à trop haute dose.

Aussi, pour moi, un code doit dans la mesure du possible est lisible même en étant optimisé, on ne fait pas de l'assembleur là.

Enfin, il existe des règles de nomenclature des noms de variables comme tu l'a dis et je pense que ce serait bon que tu les mettes explicitement dans ton post.

J'ai pris en compte ton commentaire et apporté des modifications dans la section nomenclature, yml et rajouté la raison de pourquoi le code de mon projet btooom n'est pas optimisé pour la lisibilité 

Le 15/10/2019 à 14:40, Anarchick a dit :

aucun code n'est en double, tous mes scripts sont liés les uns aux autres dans le but de réduire le plus possible la consommation des ressources matériel ce qui veut dire que pour identifier une erreur c'est un véritable labyrinthe dont je suis le seul à connaitre les recoins

Sans cette méthode mon serveur perdrait trop de TPS et je me retrouverai avec trop de code (j'en ai +10k)

 

Mais je suis d'accord avoir toi qu'il est bon d'avoir le plus possible de lisibilité, c'est pour ça que mon second projet qui est bien moins imposant me permet de tout miser là dessus

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 8 heures, Kilterra a dit :

les personnes qui essaye d'optimiser leur code cherche juste à l'optimiser au niveau de l'espace mémoire

Perso sur ce forum, je vois beaucoup de gens dire qu'ils ont optimisé leur code alors qu'ils ont juste réduit le nombre de ligne ^^

Et il y a une énorme différence entre les 2 ! Tu peux très bien avoir un code pas optimisé du tout de 25 lignes, mais avoir le même code de 150 lignes beaucoup plus optimisé !

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 22 minutes, noftaly a dit :

Perso sur ce forum, je vois beaucoup de gens dire qu'ils ont optimisé leur code alors qu'ils ont juste réduit le nombre de ligne ^^

Et il y a une énorme différence entre les 2 ! Tu peux très bien avoir un code pas optimisé du tout de 25 lignes, mais avoir le même code de 150 lignes beaucoup plus optimisé !

J'ai chopé cette monstruosité tout à l'heure sur le discord :

Contenu masqué

    Réagissez ou répondez à ce message afin de consulter le contenu masqué.

J'aimerai bien m'en occupé pour montrer un exemple d'optimisation plus que nécessaire mais il faut que je trouve le temps pour ça ^^

  • Bruh 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.