Aller au contenu principal

Style de Codage

Présentation des règles de style pour coder dans Electron.

Vous pouvez exécuter npm run lint pour voir les problèmes de style détectés par cpplint et eslint.

Pour le code en général​

  • Terminer les fichiers avec un saut de ligne.
  • Positionner les requires dans l'ordre suivant :
    • Modules Node embarqués (tel que path)
    • Modules Electron embarqués (tels que ipc, app)
    • Modules locaux (utilisant des chemins relatifs)
  • Placer les propriétés de classe dans l'ordre suivant :
    • Méthodes et propriétés de la classe (méthodes commençant par un @)
    • Méthodes et propriétés d'instance
  • Éviter le code dépendant de la plateforme :
    • Utilisez path.join() pour concaténer les noms de fichiers.
    • Utilisez os.tmpdir() au lieu de /tmp lorsque vous devez référencer le répertoire temporaire.
  • Utiliser un simple retour lors des retour explicite en fin de fonction.
    • Pas de return null, return undefined, null ou undefined

C++ et Python​

Pour C++ et Python, nous suivons le Style de codage de Chromium. Il existe également le script script/cpplint.py permettant de valider la conformité de tous les fichiers.

La version de Python que nous utilisons est Python 3.9.

Le code C++ utilise beaucoup d’abstractions et de types de Chromium, il est donc recommandé de se familiariser avec eux. Un bon endroit pour commencer est : Abstractions Importantes et Structure des Données de Chromium. Le document mentionne certains types spéciaux, les types de portée limitées (qui libère automatiquement leur mémoire en allant hors de portée), mécanismes de journalisation etc.

Documentation​

Vous pouvez exécuter npm run lint-docs pour vous assurer que vos modifications de documentation sont formatés correctement.

JavaScript​

  • Écrire selon le style JavaScript standard.
  • Les noms de fichiers doivent être concaténés avec - au lieu de _, par exemple : file-name.js plutôt que file_name.js, car dans atom/atom les noms des modules sont généralement sous la forme module-name. Cette règle s’applique uniquement aux fichiers .js.
  • Utilisez, llorsque c'est approprié la nouvelle syntaxe ES6/ES2015
    • const pour les requires et d'autres constantes. Si la valeur est une primitive, utilisez un nom en majuscules (par ex. const NUMBER_OF_RETRIES = 5).
    • let pour définir des variables
    • Arrow functions au lieu de function () { }
    • Template literals au lieu de la concaténation de chaîne en utilisant +

Règles de nommage​

L'API Electron utilise le même système de capitalisation que Node.js :

  • Lorsque le module lui-même est une classe comme BrowserWindow, utilisez le PascalCase.
  • Lorsque le module est un ensemble d’API, comme globalShortcut, utilisez le camelCase.
  • Lorsque l’API est une propriété d’un objet comme win.webContents, utilisez mixedCase.
  • Pour d’autres API non-module, utilisez des titres naturels, tels que <webview>Tag ou Process Object.

Lorsque vous créez une nouvelle API, il est préférable d’utiliser des getters et setters au lieu du style une-fonction de jQuery. Par exemple, .getText() et .setText(text) sont préférés aux .text([text]). Il y a d'ailleurs une discussion là-dessus ici .