web-dev-qa-db-fra.com

Quand dois-je utiliser camelCase/Camel Case ou des traits de soulignement dans PHP appellation?

J'ai appris PHP et j'ai constaté qu'il y avait beaucoup de variabilité dans la façon dont les gens nomment les choses. Je tiens au moins à être cohérent avec moi-même.

Où devrais-je utiliser Camel Case et où devrais-je utiliser des traits de soulignement?

Pensées:

  • Variables/Propriétés: $userid ou $user_id ou $userID

  • Classes: MyCustomClass ou myCustomClass

  • Fonctions/méthodes: my_custom_function() ou my_Custom_Function()

Toutes les pensées appréciées.

phpnaming-conventionsnamingcamelcasing
8
Linz Darlington

D'après la norme de codage de base PSR ( https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md )

Noms de classe DOIT être déclaré dans StudlyCaps.

Les constantes de classe DOIVENT être déclarées dans tous les majuscules avec séparateurs de soulignement.

Noms de méthodes DOIT être déclaré dans camelCase.

Ce guide a intentionnellement évite toute recommandation concernant l'utilisation De $ StudlyCaps, $ camelCase ou $ under_score noms de propriétés .

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';

    private $StudlyCapsProp = null;
    protected $camelCaseProp = null;
    public $under_score_prop = null;

    public function fooBar()
    {

    }
}
13
Accountant م

Beaucoup de gens ont beaucoup de préférences différentes et la plupart du temps, ils ne sont que cela, des préférences. Au-delà de ce que les gens sont habitués ou que c'est populaire, il y a rarement une rime de la raison pour laquelle une personne moyenne préfère un style particulier. Malheureusement, cela n'a pas tendance à vous donner une idée de pourquoi d'utiliser une convention particulière en ce qui concerne des questions plus pratiques.

Beaucoup de gens comptent sur le PSR, ce qui facilite la tâche de devoir établir des conventions. Dans toute équipe de développement, des conventions doivent être établies pour faciliter la cohérence. Les RPS peuvent permettre de gagner du temps par rapport au travail personnel. Bien que ce soit un début utile, vous ne devriez pas sentir que les suggestions de RP font autorité. C’est finalement à vous de décider comment vous écrivez PHP, mais si vous partez de zéro, vous devez d’abord rechercher comment les autres le font.

Le PSR a certaines limites:

  1. Il est établi par consensus plutôt que par une science particulière, ce qui signifie qu'il tend à être incohérent.
  2. Ce n'est pas tout à fait complet. Vous trouverez éventuellement des situations pour lesquelles aucune option n'est spécifiée.
  3. Il visait à l’origine à améliorer la compatibilité entre les cadres, mais il inclut maintenant des questions de goût plutôt que de compatibilité. Dans de nombreux cas, la convention que vous utilisez aura autant d’impact sur la compatibilité que la couleur de vos chaussettes qui convient à vos pieds.
  4. La compatibilité entre les cadres tend à ne préoccuper que peu ou pas la plupart des projets, voire la plupart d'entre eux. Surtout pour les projets commerciaux à sources fermées.
  5. Ce sont purement des suggestions d'un tiers non officiel. Quelqu'un préférera peut-être mélanger son café dans le sens inverse des aiguilles d'une montre et le recommander par Internet, mais en réalité, la direction dans laquelle vous le remuez dépend de vous ou de l'équipe sur laquelle vous êtes. Starbucks, Nero et Costa pourraient publier une déclaration commune vous recommandant d’agiter dans le sens des aiguilles d’une montre, mais vous n’avez pas besoin de les écouter si vous ne le souhaitez pas.

En mettant cela de côté, il existe quelques différences sémantiques et pratiques entre l’affaire chameau (chameau) et l’affaire serpent (serpent).

La différence immédiate est que camel utilise un caractère moins pour séparer les mots; c'est plus compact. Ce n'est peut-être pas toujours le cas si vous convertissez votre objet au format JSON, puis le compressez pour l'envoyer au navigateur. Bien que dans la plupart des cas, la différence soit négligeable, chamel compressera parfois moins efficacement. Vous n'êtes pas susceptible d'avoir à vous inquiéter à ce sujet. En général, les différences de performance entre les deux sont très minimes et insignifiantes.

La compacité a un prix, tant du point de vue humain que du point de vue du programme. Il peut être plus difficile de séparer et de travailler avec des termes. Dans un sens, c'est également une perte, c'est-à-dire que le délimiteur mute le caractère. C'est gênant car cela ne s'applique pas au premier caractère. Vous ne pouvez pas simplement diviser et rejoindre par cas. Une des raisons importantes est l’accès dynamique ou le méta-codage, dans lequel les propriétés et les méthodes peuvent être déterminées automatiquement, par exemple en assemblant un ensemble de jetons.

Si j'ai créé un générateur qui créerait automatiquement des objets pour représenter les tables dans une base de données et servir de référentiel, je pourrais générer des méthodes sur cette classe pour pouvoir extraire chaque colonne. Je pourrais regarder soit get_by_username|get_by_email ou getByUsername|getByEmail.

Si j'avais (get_by|getBy)($field, $value), alors je passerais un nom d'utilisateur ou un email pour le champ, ce sont les formulaires originaux. Dans ce cas, je dois ucfirst chaque champ lors de la création de la classe. Pour aller plus loin, que se passe-t-il si je les fournis de manière dynamique via __call? Dans ce cas, chaque fois que j'ai besoin de convertir le chameau avec au moins lcfirst, tout en ayant recours à Snake Case, c’est tout ce que je dois faire est de le fixer au bout de la chaîne. la fin ou le début. Vous pouvez comparer le mappage à deux dans une classe:

  • scinder par cas en excluant d'abord, map lcfirst, join
  • diviser, mapper ucfirst sur tout si on ajoute sinon pour se reposer, concat

Contre:

  • split
  • joindre

Snake conserve le jeton dans sa forme d'origine par défaut. Dans le cas contraire, il est généralement plus facile de transformer individuellement des mots facilement séparés.

Il est très courant d'utiliser le méta-codage dans PHP pour en tirer le meilleur parti, notamment un polymorphisme d'exécution basé sur des chaînes. Vous êtes assez susceptible de rencontrer éventuellement un cas dans lequel vous trouverez plus d'avantages avec serpent que chameau où vous souhaitez coder de manière dynamique.

ifCamelCaseWereReallyThatGreatEveryone serait une réponseProgrammingQuestionsOnStackOverFlowLikeThis. asYouCanSeeForAnythingButTheShortestPhrasesShortFormFeedTicklyBecomesTiring. youCanUsuallyGetAwayWithItInProgrammingAsItsInSmallDosesAndInASeaOfWhiteSpace. otherAnnoyanceWithCamelCaseIsWhenYouHaveAbbreviationsOrSingleLetterWords. itNotAllGood.

Sémantiquement, les gens ont également tendance à utiliser serpent pour créer un espace de noms et ne l’utilisent pas avec des phrases. Inversement, camel a tendance à être utilisé pour de petites phrases ou des phrases qui se lisent en anglais clair, dans l’ordre, ou sous forme de titre. C'est particulièrement courant dans OOP où le nom de classe tend à offrir la première couche de catégorisation la plus utilisée et à autoriser de plus en plus les espaces de noms imbriqués (entièrement pris en charge par PHP). Si vous faites quelque chose de catégorique, c'est-à-dire combiner des mots d'ensembles de différentes catégories dans l'ordre plutôt que de combiner des mots en anglais pour créer une phrase, la convention est d'utiliser serpent. Dans ce cas, il est également plus probable que vous vous retrouviez en métacodage.

Par exemple, database_statement_read_row_next() n'est pas vraiment une phrase anglaise valide. Où Database\Statement::readNextRow à la fin devient une expression anglaise valide.

Bien que l'anglais soit plus confortable et familier, il présente certains problèmes. Les choses ne sont pas toujours dans le même ordre ou ne sont pas dites de la même manière quand elles pourraient l'être (c'est incohérent), ce qui peut encore rendre les choses plus gênantes avec le méta-codage où il est naturel de travailler avec des ensembles de mots et de les combiner sans se soucier parfois de la nécessité deux au lieu d'un mot, ordre ou mots, tournures de phrase, etc.

En règle générale, si vous écrivez des noms sous forme de fragments d'anglais simplifié, vous devez utiliser chameau principalement parce que c'est la convention utilisée à une écrasante majorité. Si vous ne vous souciez pas strictement de l'ordre des mots correspondant à l'ordre, ils devraient être en anglais mais vous vous souciez de la catégorisation et de l'organisation, les délimiteurs explicites ont tendance à être la norme.

Ce qu’ils ne vous disent pas à propos de camel, c’est que par convention, on vous demande presque toujours de l’écrire tout en respectant les règles grammaticales anglaises qui ne s’exercent pas toujours aussi bien que les noms catégoriques dans des circonstances occasionnelles.

Des termes plus corrects seraient:

  • trait de soulignement délimité = alpha_beta
  • cas délimité = alphaBeta
  • majuscules et minuscules = AlphaBeta

Dans le dernier cas, la première lettre majuscule ne délimite pas.

Dans le monde de la programmation en général, l’utilisation de cas délimités (mélange de majuscules et de majuscules) tend à être la norme pour la programmation orientée objet. En règle générale, vous finirez généralement par être plus cohérent avec PHP, en particulier pour tout nom associé à OOP, telles que ces méthodes.

Inversement, pour les variables procédurales, fonctionnelles et locales, les langages populaires ont une tendance assez forte à utiliser serpent.

Quoi que vous choisissiez, essayez d'être aussi cohérent que possible et, là où il y a une différence, vous devriez avoir à la fois une raison et une convention. Si vous mélangez les deux, vous pouvez en placer un derrière une façade. Camel a tendance à être destiné à la consommation humaine et à être lu comme un anglais valide où, si besoin est pour le métacodage, le serpent pourrait être quelque chose que vous pouvez imbriquer derrière une façade.

Spécifiquement pour vos propositions:

Variables/Propriétés:

  • userid deviendra difficile à lire et finira par créer d'autres mots. Il serait également impossible de le traduire dans un autre format standard.
  • user_id c'est bien.
  • userId c'est bien
  • userID est mauvais. Cela se traduirait par user_i_d plutôt que par user_id.

Des classes:

  • MyCustomClass est une norme universelle très cohérente qui a également du sens car les noms de classe sont des titres et doivent être mis en majuscule.
  • myCustomClass Peut donner l'impression que quelqu'un a mis une méthode alors qu'il voulait mettre un nom de classe.

Fonctions/méthodes:

  • my_custom_function C’est la chose la plus simple qui puisse fonctionner (dans des limites raisonnables) bien que, par convention, on ne s’en tienne pas à la grammaire anglaise, mais les mots anglais qui l’utilisent pour l’espace de nommage sont simplement appelés function_custom ou function_default.
  • my_Custom_Function n'est pas la chose la plus simple qui puisse fonctionner. La capitalisation est redondante et ne sert à rien ceux à qui elle révèle un avantage caché de caractère dédié délimité, elle peut préserver le casse.

Certaines personnes pourraient être incitées à utiliser les deux méthodes pour offrir un ou plusieurs niveaux de nidification. Quoi que vous fassiez pour ça ça va finir moche. C'est le même concept que CSV dans CSV ou un tableau à deux dimensions. Chameau et serpent sont utilisés pour représenter un tableau de mots simples. Si vous souhaitez représenter deux tableaux de mots, vous aurez besoin de quelque chose de spécial, par exemple une combinaison de deux ou plusieurs délimiteurs pouvant inclure un délimiteur de plusieurs caractères. Si vous vous trouvez dans cette situation, il est fort probable que YAGNI soit un cas, car dans la pratique, le chameau ou le serpent seul suffisent presque toujours. Si vous les mélangez, cela devrait faire partie d'une stratégie plus que superficielle et documentée ou évidente.

Un exemple pertinent de ceci pourrait être le cas get_by_username|get_by_email. Je pourrais décider de toujours avoir [$operation, $field]. Il peut être nécessaire de décrire l'opération et le champ avec plus d'un mot chacun. Cela pourrait conduire à utiliser chameau pour les champs et les opérations mais faire en sorte de séparer les champs et les opérations. Cela donnerait par exemple getBy_username, deleteBy_username ou getBy_firstName. Ce n'est pas beau, mais pourrait être argumenté pour servir un but pratique. Il est également assez courant de commencer par snake pour fournir un espace de noms, puis de terminer par camel, qui correspond essentiellement à ce que vous obtenez en utilisant OOP espaces de noms, classes et méthodes. Ce n'est pas faux de mélanger les choses si pour une bonne raison mais le plus souvent, un mélange de styles comme celui-ci a tendance à être une mauvaise odeur de code qui vous mène à des toilettes vides.

0
jgmjgm