Share
En particulier lorsque vous commencez à utiliser différentes langues de développement Web, il peut s'avérer difficile d’apprendre toutes les conventions de dénomination d’une langue à l’autre. Cela peut être encore plus déroutant lorsque les développeurs sont en désaccord sur ce qui est considéré meilleur entrainement. Pour faciliter la transition des débutants, cette liste décrira certaines des conventions les plus courantes..
Lorsque vous rencontrez une variable ou une méthode qui est traitée par un _, il n'y a pas de magie vaudou dans les coulisses. Il s’agit simplement d’une convention de dénomination qui rappelle au développeur que la variable / propriété / méthode est soit privé ou protégé, et n'est pas accessible de l'extérieur de la classe.
// Cette variable n'est pas disponible en dehors de la classe private $ _someVariable; class MyClass // Cette méthode n'est disponible que dans cette classe, ou // dans les autres qui en héritent. fonction protégée __behindTheScenesMethod ()
Notez que, dans le code ci-dessus, le soulignement n'est pas ce que fait du la variable ou la méthode privé; la privé / protégé mot-clé fait ça. Le trait de soulignement n'est qu'un rappel pour les six mois à venir!
var Person = (function () var _trueAge = 50, _trueWeight = 140; return age: _trueAge - 15, weight: _trueWeight - 30;) (); Personnage; // 35 Person.weight; // 110 Person._trueAge; // non défini (parce que c'est privé, yo)
En faisant La personne égal à, pas un une fonction, mais le rendu objet, nous pouvons créer des variables privées. Encore une fois, le préfixe de soulignement nous rappelle cela.
UNE constant est une variable avec une valeur statique, cela ne changera pas. Par exemple, si votre projet nécessite la nécessité de multiplier une valeur par la taxe d’état, vous pouvez affecter ce taux., 0,0825 $ à un constant. Cependant, toutes les langues ne disposent pas de ces types de variables. En tant que tel, il est recommandé d’utiliser toutes les lettres majuscules pour vous rappeler que vous travaillez avec un constant. C’est une convention courante dans le monde JavaScript, qui utilise ses objets natifs, comme MATH.PI.
var TAXRATE = .0825;
Accentsconagua
define ('TAXRATE', .0825); Vous avez sûrement, à un moment donné, rencontré une variable qui a été précédée d'une seule lettre, telle que "s" ou "je".
$ sName = 'Captain Jack Sparrow';
Ceci est appelé Notation hongroise, et est tombé en disgrâce ces dernières années, même si cela reste une convention utilisée par de nombreuses entreprises.
La notation hongroise est une convention de dénomination qui rappelle au développeur la
typede variable avec laquelle il travaille:string,jeplus tard, etc.
En particulier dans le monde JavaScript, cette pratique est mal vue, du fait qu’il s’agit d’un langage mal typé. Un langage mal typé est un langage qui ne vous oblige pas à déclarer le type de données d'une variable. Pourquoi est-ce important? Et si, en utilisant la convention de notation ci-dessus, nous déclarions une chaîne avec le "s" préfixe, mais a ensuite changé la variable en un entier? À ce stade, cette forme de notation serait en fait contre nous, pas pour nous..
var sName = "Lieutenant-commandant Geordi La Forge"; typeof (sName); // chaîne… sName = undefined; typeof (sName) // non défini
Utilisateurs jQuery: avant de monter sur votre piédestal et de vous féliciter de ne pas utiliser cette forme de notation, demandez-vous si vous préfixez les variables - entourées de l'objet jQuery - par un symbole dollar? Si c'est le cas, c'est une forme de notation hongroise. C'est un symbole préfixé à un nom de variable qui sert uniquement à vous informer du type ou des qualités de la variable..
// Le symbole dollar me rappelle que cette variable // a accès aux différentes méthodes de jQuery. var $ conteneur = $ ('# conteneur'); C'est entièrement à vous. Même de nombreux membres de l’équipe jQuery utilisent la méthode du préfixe dollar. En fin de compte, si cela fonctionne pour vous, c'est tout ce qui compte. Personnellement, depuis environ un an, je n’utilise plus le préfixe du symbole dollar, mais seulement parce que j’ai réalisé que ce n’était pas nécessaire. pour moi. Faites votre propre opinion sur celui-ci.
Qu'en est-il de ces noms "variables", qui capitalisent la première lettre du nom?
$ response = $ SomeClass-> doQuelque chose ();
Dans le code ci-dessus, $ SomeClass est capitalisé parce que c'est un classe et pas un variable prénom. Encore une fois, il s’agit d’une convention de dénomination que la plupart des développeurs utilisent. En revenant au code un an plus tard, c'est un petit ampoule qui les informe qu'ils travaillent avec une classe contenant des objets et des méthodes.
// Notez le capital M dans le nom de la classe. class $ MyClass function __construct ()
En JavaScript, nous n'avons pas vraiment classees; mais nous avons constructeur les fonctions.
var Jeff = new Person ();
La raison pour laquelle nous capitalisons le nom du constructeur (La personne) est qu’il peut être facile d’oublier parfois les Nouveau mot-clé. Dans ces circonstances, JavaScript ne génère aucun avertissement et il peut s'avérer un cauchemar de détecter le problème. La capitalisation est une alerte utile pour le développeur lors du débogage. Douglas Crockford est un grand défenseur de cette convention.
Alternativement, si vous voulez vous protéger contre les oublis de votre futur moi, vous pouvez d'abord vous assurer que le constructeur est correct, avant de continuer..
function Person (name) // Si le nouveau mot-clé est absent, le constructeur sera la fenêtre. // Dans ce cas, compensez et renvoyez une nouvelle instance if (this.constructor! == Person) return new Person (name); this.name = name; // Oubli intentionnellement le mot-clé "nouveau" var Joey = Person ('Joey'); Joey.name; // Joey Pourquoi certaines variables utilisent-elles un motif camelCase, alors que d'autres utilisent un trait de soulignement pour séparer les mots? Quelle est la bonne méthode? La réponse est qu'il n'y a pas correct usage. Cela dépend entièrement de la langue et / ou des conventions de codage de votre entreprise. Les deux sont parfaitement acceptables.
// camelCase var preacherOfSockChanging = 'Lieutenant Dan'; // under_score var preacher_of_sock_changing = 'Lieutenant Dan';
Cependant, ceci étant dit, il est recommandé, lorsque vous avez la possibilité, de suivre les conventions courantes du langage que vous utilisez. Par exemple, la grande majorité des développeurs JavaScript utilisent la syntaxe camelCase, tandis que d'autres langages, tels que PHP, ont tendance à préférer l'utilisation du trait de soulignement. Encore une fois, cela n’est pas figé. Le Zend Framework préconise le camelCasing comme meilleure pratique.
Plus important que ce que vous utilisez, c'est de vous y tenir!
En particulier lorsque vous travaillez en équipe, il est essentiel que vous adoptiez la structure de répertoires appropriée en tant que développeurs. Mais, à tout le moins, n'abandonnez certainement pas toutes vos feuilles de style et tous vos scripts à la racine de votre projet, sans aucune organisation. De nombreux développeurs préfèrent placer toutes leurs images, scripts et feuilles de style dans un fichier parent. Les atouts annuaire.
/ Projet Racine / Assets / js / min script_min.js script.js / css / min style_min.css style.css / img img1.jpg index.html autreFichier.html
Notez également la convention de créer également un min dossier contenant les versions minifiées ajoutées dynamiquement de vos scripts et feuilles de style.
J'espère que lors de la création d'une marge, il est généralement admis que le identifiantle sable classees que vous choisissez devrait décrire le type de contenu et non les aspects de la présentation. Par exemple:
Justin Bieber est ma section de homeboy.
Justin Bieber est ma section de homeboy.
Justin Bieber est ma section de homeboy.
Comment venir? Et si, six mois plus tard, vous décidiez de placer votre section de ventilateurs Justin Bieber dans le milieu-DROIT-puis-un-peu-inférieur section? À ce stade, votre identifiant aura peu de sens.
Lors de la transition dans un monde HTML5, vous devriez vous retrouver avec beaucoup moins d'identificateurs dans vos éléments..
identifiants sont moins flexibles et sont souvent inutiles.
Entêtele sable Bas de pages Tu sais ce qui pue? Lorsque vous travaillez sur un site Web centré nécessitant plusieurs arrière-plans qui s’étendent sur toute la largeur de la fenêtre (généralement pour le entête et bas de page), vous devez généralement envelopper votre contenu pour que l’élément externe s’étende, tandis que l’élément interne peut rester centré.
Comme il s’agit d’un problème courant, il est important d’adopter une convention commune pour créer le supplément nécessaire..
La décision difficile à prendre ici est que, si vous travaillez avec les nouveaux éléments HTML5, vous devez décider de placer ou non le bas de page élément à l'intérieur ou à l'extérieur. Il reste encore à discuter, cependant, j’ai tendance à penser qu’il est plus sémantique de situer le bas de page élément à l'intérieur.
divs ne devrait être utilisé que lorsque:
Décidez maintenant si vous autorisez ou non l'utilisation de raccourcis dans votre code. Écrire du code précis / propre est toujours un combat entre lisibilité et taille. C'est pourquoi il est primordial que les équipes de développement suivent les mêmes directives de codage. Fournir deux exemples rapides:
var name = 'Joe'; // regular if (name === 'Jeff') alert ("C'est moi"); else alert ("Nope"); // ternary (name === 'Jeff')? alerte ("c'est moi"): alerte ("non"); // Nan && Pour les condition de mains courtes? var getTweets = true; // regular if (getTweets) alert ('les obtenir maintenant'); // AND logique et // le côté droit ne s'exécutera pas, à moins que le côté gauche ne soit "vrai" getTweets && alert ('Les obtenir maintenant'); De nombreux développeurs vont s'opposer à l'utilisation de la logique ET dans ce cas, insister pour que cela limite la lisibilité. Ceci est certainement un argument valable, même si, néanmoins, même des bibliothèques populaires comme jQuery font un usage intensif de cette méthode..
Pour rappel, les conventions spécifiques que vous choisissez sont beaucoup moins importantes que de veiller à rester cohérent avec votre utilisation. En fait, de nombreuses équipes de développement rédigent leurs propres directives de convention pour les nouveaux recrutements. Merci d'avoir lu!
