-
Notifications
You must be signed in to change notification settings - Fork 9
Conventions de nommage
- Elodie
- Vanessa
Chaque langage a son propre coding style, il n'est donc pas possible de respecter le coding style de tous les langages.
C/C++, Java,PHP, JavaScript, typeScript ==> CamelCase
langages de script (Ruby, Python) ==> snake_case
Chaque ressource d'une API REST a un identifiant, souvent noté id dans la ressource. Dans les ressources liées on trouve aussi un id ainsi que l'identifiant de la ressource liée.
Par exemple l'identifiant du payment lié à un refund peut être noté : payment, id_payment ou payment_id. Le choix entre le payment et payment_id se fait en fonction des capacités de notre API et des éventuelles bibliothèques qui accèdent notre API. L'utilisation de payment est contre intuitive car on s'attend à avoir un objet payment alors qu'il s'agit juste d'un identifiant. Utilisation intuitive de payment_id :
{ "id": "re_390312", "object": "refund", "payment_id": "pay_490329", ... }
Utilisation intuitive de payment :
{ "id": "re_390312", "object": "refund", "payment": { "id": "pay_490329", "object": "payment", "amount": 2200, ... }, ... }
Les booleans ont souvent des noms qui peuvent porter à confusion avec d'autres attributs du même objet. Trouver des noms qui ne portent jamais à confusion (bon courage !) ou utiliser un préfixe ou un suffixe Par exemple un attribut paid. Est-ce qu'il s'agit d'un attribut qui indique que le paiement est payé ou alors de la date à laquelle il a été payé ? solution à ce problème : payment = payplug.getPayment(id='pay_CD9SCD')
payment.is_paid # c'est payé, pas de doute on sait tout de suite.
Exemple avec des recettes , ici recipe :
Objet : recipe (au singulier) Liste ou tableau d’objets : recipes (au pluriel) Pour les observables : Recipes$ (dollar à la fin du nom de l’attribut.) Pour les subscriptions : recipesSub Dans un objet on a toujours un attribut id dans la classe côté client correspondant à l’ID du JSON côté serveur: **recipe_id ** Si nécessaire on peut créer un « id » faisant référence par ex à la clé étrangère d’une autre table pour pouvoir y accéder: id_recipe ( l’ id correspondrait au créateur de la recette disponible dans une autre table par exemple)
getRecipe, setRecipe, addRecipe