====== Python NeL Library ====== Travaux en cours / Work in progress Un nettoyage/revue du code est en cours afin de finalisé une première version "publiable". Nettoyage des partie du code expérimentale et/ou obsolète suppression des commentaires de dev/debug, (ré)écriture des commentaires des diverses méthodes, des docstrings python,... Cela va prendre un peu de temps d'autant plus que la santé du fou furieux qui code se bazar est quelque peu aléatoire pour le moment. Une fois fait on devrai pouvoir faire un merge sur master et avoir une première version suffisamment stable et robuste pour pouvoir la "publier" et proposer quelque chose qui ne devrai pas changé trop rapidement en dehors d’éventuel hotfix et correctifs mineurs. Et donc commencer a créer la doc sur ce wiki. Un scoui ===== Introduction ===== ==== Description ==== Page destinée à regrouper la documentation au sujet de du module python py_nel. Ce module à pour but de permettre de manipuler les données liées aux différents objets NeL3D via python. Il a donc pour principal objectif d'exposer toutes les données éditables à l’extérieur du NeL, par les graphistes, leveldesigner… et dont le moteur a besoin pour peupler l'univers et le faire fonctionner. Tel que les différents types d'objets la façon dont ceux-ci sont lié ensemble,... Son principale objectif est de permettre la lecture, création et modification des différents fichiers aux formats spécifiques du NeL tel que les .shape, .skel, .anim, .ps, ... ==== Gestion des branches ==== * La branche //develop// sert au travail régulier ; * la branche //testing// est une version qui doit être fonctionnelle sous Blender, elle sert à valider ce qui a été développé, qui peut demander des modifications/ajouts dans la partie //bpy_nel_workbench // ; * la branche //master// est la version fonctionnelle et aboutie. ==== Notes de l'auteur ==== Je pense également à terme faire en sorte de pouvoir manipuler également les données tel que les datasheets voire si possible les primitives elles même, mais sur ce point mes connaissance ne pas "encore" suffisantes, mais cela viendra. Pour l’instant la plupart de la doc est directement dans le code sous forme de tout un tas de commentaires, car c'est bien plus pratique pour moi pendant la phase de développement/analyse/prototype mais je compte bien à terme tout mettre au propre ici ainsi que le résultat de mes découverte et de mon analyse du fonctionnement interne du NeL. Ainsi que bien évidement la doc et les exemple d'utilisation du module. Le principal projet utilisant ce module est bien évidement la création de pluginS Blender et j'insiste sur le pluriel car il ne s'agit pas de se contenter d'un simple import/export mais bien de créer un ensemble d'outils à l’intérieur même de Blender afin de facilite la création de contenu via celui-ci. Je crée cette page ne serai-ce que pour pouvoir commencer à la remplir et parce que je risque de bientôt rendre "public" le fait que je taff la dessus, vu que ça avance quand même assez vite. osquallo ==== Documentation pour les devs ==== === Intro === Le code suis (dans la mesure de mes propres connaissances sur le sujet et avec peut être de légère variation dans certains cas, sachant que visiblement le pep suis généralement ma propre façon de faire (vu que j'ai quelque année d'avance sur certains points semble t-il), les recommendation du PEP dans le but d’être plus facilement lu par diverses personne d'horizon différent. Cela dit la seul règle vraiment importante reste la lisibilité quitte sur un cas particulier à s'adapter a la situation et jamais a adapter le code pour le forcer à suivre des regles lorsque celle ci ne s'avere plus adapter a la situation, faites surtout en sorte que cela soit lisible et oublier votre ego/fierté, préférer utiliser votre cervelle et réfléchissez à ce que vous faites. La citation python qui me semble la plus importante est: Explicit over implicit Exemple: Préférer utiliser des noms explicites même si cela les rallongent un peu plutôt que d'utiliser des nom flou et aisément interprétable de diverses façon ou nécessitant une doc rien que pour les expliquer, et éviter les acronymes pour les méthodes/fonctions ! Même si ils vous semblent évident, cela dois rester une solution de dernier recours, évitez que cela soit systématique ou le choix par défaut. Si vous vous connaissez votre code les autre non, de plus vous même ne le connaitrez plus après plusieurs mois sans y toucher donc penser a non seulement aux autres mais aussi a vous même plus tard. Aérer le code, on ne dois pas avoir mal au crane rien qu'en le regardant. === liens utiles === [[https://www.python.org/dev/peps/pep-0008/|PEP8 Style Guide for Python Code]] [[https://www.python.org/dev/peps/pep-0257/|PEP257 Docstring Conventions]] [[https://www.python.org/dev/peps/pep-0224/|PEP224 Attribute Docstrings]] {{tag>Tag_a_ajouter}}