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)
- Modules Node embarqués (tel que
- 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
- Méthodes et propriétés de la classe (méthodes commençant par un
- É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.
- Utilisez
- Utiliser un simple
retour
lors des retour explicite en fin de fonction.- Pas de
return null
,return undefined
,null
ouundefined
- Pas de
C++ et Python
For C++ and Python, we follow Chromium's Coding Style. 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
- Ecrivez les remarques en markdown.
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 quefile_name.js
, car dans atom/atom les noms des modules sont généralement sous la formemodule-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 lePascalCase
. - Lorsque le module est un ensemble d’API, comme
globalShortcut
, utilisez lecamelCase
. - Lorsque l’API est une propriété d’un objet comme
win.webContents
, utilisezmixedCase
. - Pour d’autres API non-module, utilisez des titres naturels, tels que
<webview>Tag
ouProcess 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 .