Bonjour à tous et à toutes,

Bref, vous savez ya pas mal de convention de nommage en Symfony que ce soit avec twig, avec PHP et même au niveau des annotations...

J'aime bien savoir vos opinions, vos propositions à propos ma philosophie.

Personnellement j'utilise camelCase pour les variables, les classes, underscores pour toute configuration, options ou paramétrage ...

Ma propre facon de nommage :

• Tout nom d'un fichier quelconque doit être forcément écrite en anglais.

• Classe : MaClasse
  

• Fichier de classe : MaClasse.php : et j'ajoute (s) à la fin si ce classe représente une collection, ou bien si la classe de l'entité inverse d'une relation ManyToOne se termine avec (s).
  

• Fonction publique : maFonction()
  

• Fonction privée|protégée : _autreFonction()
  

• variable publique : $maVariable
  

• variable privée|protégée : $_maVariable
  

• variable (variante) : $monArray, $maString, $monEntier
  

• constante : NOM_DE_CONSTANTE
  

• Service: something.service_name
  

• Macros: _macro_checkbox_tree.html.twig
  

• simple twig view: add-user-je-ce-pas.html.twig
  

• Form theme: _collection_theme.html.twig
  

• Annotation:

    * @ORM\Column(name="update_at", type="datetime", nullable=true)
    private $updateAt;

    * @ORM\ManyToOne(targetEntity="AppBundle\Entity\Sessions", inversedBy="sessionsLists")
    * @ORM\JoinColumn(name="session_id",nullable=true) 
    private $sessionId; 

Je vous remercie infiniment pour toute bienveillante réponse, recommandation, idée à me proposer.

-
Edité par ahmedbhs 20 novembre 2017 à 15:26:31

J'ai tendance à faire sur certaines de mes variables :

$aArray

$oObject

$sString

etc ...

Grace à la première lettre je sais directement si ma variable contient une string, un objet, un tableau ...

@tally Cool, très bonne idée.
Et concernant le nommage au niveau des différents composants du Framework Symfony, que ce soit, classe et ces propre variables, bundle, service, configuration yaml , annotation, les vues twig, quesque vous proposez !!

-
Edité par ahmedbhs 20 novembre 2017 à 17:43:03

Salut !

Moi je propose d'essayer de comprendre quand/où est utilisé quelle méthode, et de s'y faire  Ceci notamment parce que c'est rare de trouver un projet où il y a des règles précises qui ont été respectées de bout en bout (et sincèrement, dans le milieu professionnel, chacun fait toujours comme il veut au final). Moi-même je tente de suivre les PSR pour ce qui est de PHP, mais je sais pertinemment que je ne suis pas "tip-top-nickel" à ce niveau, ne serait-ce que parce que je ne suis pas d'accord avec certains choix et que du coup j'ai de la peine à les respecter.

Alors déjà, tous mes noms de variable, de classes et de bundles sont en anglais, et je préfère avoir de longs noms plutôt que des abréviations qui varient trop d'une personne à l'autre (seules exceptions que je me permets : $nb* pour un nombre et $i, $jet $k pour les compteurs). Etant donné que la longueur du nom des variables influence très très peu l'exécution du code, pas de souci à être clair.
Avec Symfony, j'évite les noms de classes qui sont aussi des mots-clés SQL. Les balbutiements de Doctrine 2 dans ces cas m'y ont bien aidé 

Pour les bundles, ça dépend. J'aime bien conserver le niveau racine YSoft en ce qui me concerne, mais je verrai avec Symfony 4.
Après, si je n'ai qu'une entité dedans, le bundle prend le nom de l'entité, sinon c'est le contexte (PersonBundle peut ainsi contenir non seulement l'entité Person, mais aussi Address), tout comme il détermine ce que je mets dans un bundle ou dans un autre. Pour les différents éléments, je prends exemple sur les classes auto-générées par Symfony. Mes services sont dans un dossier Service, et je ne suffixe pas le nom de la classe avec un Service supplémentaire, on a déjà l'indication par l'espace de nom et le dossier dans lequel la classe existe.

Symfony suit les conventions PSR, donc c'est CamelCase#lowerCamelCase ou CamelCase::lowerCamelCase(). Attention cependant à ne pas généraliser Symfony à ses dépendances. Doctrine, notamment, ayant vécu plus longtemps que Symfony, ne suit pas nécessairement déjà le standard au pied de la lettre. Twig de même. Aussi, je ne vois pas trop comment on peut changer la dénomination des annotations, vu que ce sont des pseudo-appels à des classes, donc ça découle de ci-dessus. Après, la manière "compacte" pour les annotations, c'est */uniquement pour les déclarations de contexte (/** @var string $message */ quand je fais un foreach ($messages as $language => $message)), sinon /** et */ sont sur leurs propres lignes. Pour ce qui est des types des variables, mon environnement de développement reconnaît les "annotations" de documentation (@var string, etc), du coup, aucun besoin de spécifier le type pour moi. Et le contexte tout comme le nom en lui-même fait beaucoup.

Dans les templates Twig, il est préconisé d'utiliser snake_case pour les noms de variables, mais sauf erreur les systèmes pour accéder aux propriétés des objets ne transforment pas ce_truc en ceTruc, mais si je ne me trompe l'inverse fonctionne. Déjà là, souci. Du coup, lowerCamelCase.

En YAML par contre, vu que j'utilise ce format pour les traductions (et les chaînes sources sont des mots-clés), snake_case. Cela me permet de voir plus rapidement s'il m'en manque, par rapport à un texte "rythmé" par les espaces et les majuscules. Pour la configuration (et j'utilise aussi le YAML pour les mappings), du coup, pareil.

-
Edité par Ymox 20 novembre 2017 à 19:06:07