Le code source en C# de l'éditeur et du moteur Unity est maintenant disponible à la lecture

Le code source en C# de l'éditeur et du moteur Unity est maintenant disponible à la lecture

En effet, dorénavant, le code source en C# du moteur de jeux vidéo Unity ainsi que de l'éditeur est disponible à la lecture sur GitHub. Toutefois, tous les mots de cette phrase sont importants. En effet, ce n'est pas l'intégralité du code source de Unity qui est disponible, mais uniquement les morceaux codés en C#. Aussi, le code n'est pas open source. Il est disponible uniquement à des fins de lecture. C'est-à-dire : vous n'avez aucun droit de le modifier, ni même pour en faire un « pull request » (pour rapporter un bogue, il faut utiliser le trackeur de bogues, comme auparavant).
En bref, le code a été mis à disposition afin d'aider les développeurs à mieux comprendre le fonctionnement de leur projet, ou encore, aux curieux souhaitant comprendre comment le moteur fonctionne. Il est aussi possible de voir les changements entre chaque version (et de remonter jusqu'à la version 2017.1).

Il est utile de rappeler que les parties C# du moteur de jeux vidéo étaient déjà accessibles, en décompilant les assemblies de Unity. Cela est même permis par la licence de Unity. Toutefois, le résultat était difficile à utiliser (absence des noms de variables et des commentaires). De plus, certaines personnes mettaient à disposition les fichiers produits par le disassemblage, ce qui était illégal. Ainsi, pour améliorer la vie des curieux et pour éviter à des personnes bienveillantes de passer dans l'illégalité, la société a mis le code source à disposition (à la lecture uniquement).

Bonne lecture !


Votre opinion

:fleche: Aviez-vous eu le besoin de désassembler Unity ?
:fleche: Est-ce que cette annonce vous impacte ? Pourquoi ?


Source

Annonce officielle

le code n'est pas très propre

@datalandia : n'hésite pas à le leur faire savoir. Je suis sûr qu'ils n'attendent que cela.

je donne simplement mon avis...et si il le mettent en open source c'est justement pour avoir aussi ce genre de retour

Je suis d'accord leur code est a chier, ils ont nommé les variables comme s'ils ecrivaient du C++. (m_Variable) Si c'est pas un anti pattern ca ! ... :D

Sachant que le moteur est codé en c++, ça parait pas si absurde.
C'est marrant les critiques subjective du code sans arguments. C'est un peut "je trouve ça moche", bref, très constructif...

Très intéressant par ailleurs, merci pour l'info.

Citation:

---

Envoyé par datalandia

je donne simplement mon avis...et si il le mettent en open source c'est justement pour avoir aussi ce genre de retour

---

Un avis est intéressant s'il est constructif (surtout sur un aspect aussi subjectif que la qualité d'un code). Et ce n'est clairement pas le cas du votre. Je vous invite donc à étayer vos propos à l'aide d'arguments et d'exemples tirés du code source.

De plus, il n'est pas "open source". Il est "ouvert" à la lecture, pour des raisons explicitées dans l'actualité. La nuance est importante...

1)un exemple parlant, il manque clairement de commentaire, les fichiers se contente de 1-2 commentaires de 1 ligne grand max
c'est un exemple typique d'une mauvaise qualité de code

2)il n'y a pas de coding standard, certaines variable (de meme catégorie, c'est pas des global ou des attributs) commence par des majuscule d'autre non

voila un exemple de code bien fait par exemple

Citation:

---

Envoyé par datalandia

1)un exemple parlant, il manque clairement de commentaire, les fichiers se contente de 1-2 commentaires de 1 ligne grand max
c'est un exemple typique d'une mauvaise qualité de code pour vous

---

J'ai rajouté la partie en gras. Beaucoup ne partagent pas votre point de vue.

Le point 2 est tout à fait recevable par contre.

Citation:

---

Envoyé par datalandia

1)un exemple parlant, il manque clairement de commentaire, les fichiers se contente de 1-2 commentaires de 1 ligne grand max
c'est un exemple typique d'une mauvaise qualité de code

---

Non. Il vaux mieux un nom de variable ou de fonction ayant du sens et explicite qu'un bloc de commentaire....
Et j'ai trop souvent vu des pavés de commentaires n'ayant rien avoir avec le code... au minimum actuel... pour les considérer comme fiable ou indicateur de quoique ce soit.

Lesquels classes que j'ai regardé ont des métriques relativement correct...

• Longueur de la classe inférieur à 2000 lignes.
• Longueur des fonctions inférieur à 200 lignes.
• Profondeur des fonctions (nombre de bloc imbriqué) inférieur à 5.

Edit :

Citation:

---

Envoyé par François DORIN

J'ai rajouté la partie en gras. Beaucoup ne partagent pas votre point de vue.

---

Je confirme.

il est vrai que c'est assez spécial comme code, faut pas s'attendre a du MVVM pur Microsoft pour l'UI :mouarf:

On dira mais bon si ça marche bien on s'en fiche.

Mais ça me surprends quand même.

Mon avis perso :
- Pour le nommage des variables , la seul fois ou je n'y fait pas attention c'est pour les couches auto générées style Entity Framework ou je trouve interessant d'être proche de la BDD, car l'abstraction naturelle d'entité peut amener des surprises dans la génération sur SQL. (Généralement je fais une couche de service qui l'abstrait)

- Pour les commentaires, ok pour ne pas trop en mettre mais au moins soigner les commentaire XML des entêtes de classe/méthodes(CsDoc), c'est la base.
- Je trouve qu'il y'a peu d'interfaces pour de la POO ?
- Beaucoups de if sans curly braces Il y'en a qui aiment (#vbPythonLovers) moi je trouve ça pas lisible en C#/Java et problématique pour les merges/intégration.
- indentation mal faite :

Code:

---

1 2 3 4 5 6

double time = EditorApplication.timeSinceStartup;   if (time > m_FadeoutTime) GUI.color = new Color(1, 1, 1, 1 - (float)((time - m_FadeoutTime) / kWarningFadeoutTime)); GUI.Label(r, GUIContent.none, EditorStyles.notificationBackground); EditorGUI.DoDropShadowLabel(r, m_Notification, EditorStyles.notificationText, .3f);

---

C'est quand même vrai que le code est un peu surprenant. Certes on doit pas avoir le wiki qui va avec (enfin j'espère qu'ils en ont un), mais dans l'état c'est dur de suivre le code, du fait du peu de commentaire et du noms de certaines variables pas très parlant. A titre d’exemple j'ai voulu voir comment était codé les gizmo de l'éditeur (pour comprendre les différences de fonctionnement avec ceux de blender) et c'est pas facile à suivre. Pourtant Unity ça fait 5 ans que je l'utilise donc c'est pas comme si je me plongeais dans un domaine que je ne connais pas. Et pour ceux qui trouve que le code est "très bien" (je dirai pas qu'il est mauvais non plus) il suffit de regarder les codes d'exemples fournit dans la documentation Unity (celle pour les utilisateurs) qui sont bien plus commentés et facile à suivre. Vous allez tout de suite voir que c'est radicalement différent. Pourtant les 2 sont codés par les personnes de la même boite (mais probablement pas les mêmes).

Du coup c'est sympa d'ouvrir le code mais je doute qu'a part quelques individus, ça sera sans doute inutile à la plupart, surtout que Unity c'est sa mise prise en main simple et immédiate qui fait son plus grand atout. Et la c'est pas les adjectifs que j'utiliserai pour qualifier le code de l'éditeur.

La POO n'est pas définie par l'utilisation d'interfaces.
Un pti CTRL+K, CTRL+D / "format document" et voilà, les tabulations seront réglées.

Ce code est disponible pour satisfaire les curieux, pas pour faire un état de l'art sur la meilleure façon d'écrire/présenter son code.