Quels sont les plus couramment utiliser des stratégies de développement web dans les entreprises de logiciels? [fermé]

Question

Avoir le meilleur site du forum parmi les développeurs, je pense que je trouverai un très bon consensus sur ce que les politiques et les meilleures pratiques font bon codage. Je mets certains d'entre eux ici, donc je donne l'idée, mais je voudrais connaître votre opinion et les votes sera probablement le juge des meilleures politiques autour.

• Indentation spécifique pour le codage entre les équipes de développement
• commentaires spécifiques avant chaque méthode, avant chaque déclaration de variable
• Conventions de dénomination, cas de chameau ou de toute autre.
• Dans HTML des commentaires après chaque balise conteneur.
• Dans CSS, en utilisant chaque déclaration qu'une seule fois.

Vous avez l'idée. Je voudrais savoir quelle compagnie choses nous demandent de faire, et ce de ceux qui travaillent vraiment pour obtenir le code maintenable et beau.

Answer 1

Je me concentrerais des politiques sur les pratiques de développement plutôt que le formatage du code. Voici quelques exemples:

• Utilisez toujours paramétrées requêtes SQL. Jamais concaténer entrée utilisateur dans une requête.
• Gardez HTML, CSS et JavaScript dans des fichiers séparés.
• Utilisez jslint ou un outil équivalent tous fois que vous livrez code.
• Choisissez une norme HTML (HTML 4.01 strict). Tous HTML doit valider.

Et ne soyez pas une politique Nazie. Parfois, les règles doivent être brisés, mais il devrait y avoir une très bonne raison de le faire.

Answer 2

• Code n'existe pas si ce n'est pas sous contrôle de version. Plus précisément, rien est sur un serveur de production, à moins qu'il est engagé dans le référentiel.
• Si un projet est l'occasion de factoriser ancien code, saisir cette occasion.
• Maintenir un wiki ou similaire à documenter les procédures, normes et utilisation du code de la bibliothèque (lorsque ces documents est trop pour les commentaires de code)

Answer 3

(Pour les projets PHP, au moins - notez que PHP est open source et a une communauté importante, donc, beaucoup de choses sont tout à fait motivées par ce qui est fait dans la communauté)

Tout d'abord, lors de l'utilisation d'un cadre sur un projet (toujours), nous essayons de tenir à sa politique, si elle est clairement définie (c'est le cas pour Zend Framework, au moins) : il assure tous ceux qui viennent travailler sur ce projet:

• trouver une définition de la norme
• re-utiliser sur d'autres projets qui utilisent le même cadre
  • même pour aller à une autre société, ou travaillant pour un autre client
  • ou en venant d'une autre société; -)

Etant donné que nous utilisons seulement entre 3 et 5 cadres pour les projets PHP dans l'entreprise où je travaille, et ce sont les mêmes, ce n'est pas un vrai problème de règles définies dans leurs normes.

de même si le codage intérieur / arround une sorte de CMS, par exemple, bien sûr.

Lorsqu'ils ne sont pas en utilisant un cadre spécifique, nous essayons de tenir à un ensemble de règles communes largement acceptées au sein de la communauté PHP: De même, il assurer ces règles sont bien connues (même par les nouveaux venus à notre société) , facile à trouver, et que beaucoup de gens les ont essayé et les améliorées.

À propos de commentaires, il y a un outil qui est bien utilisé en PHP: phpDocumentor (environ la même chose que javadoc) ; il définit une norme - celle-ci est la norme de facto, car il n'y a pas d'autre outil qui est utilisé beaucoup

.

A propos de commentaire balises spécifiques:

• nous utilisons toujours @param / @return: ils sont intégrés dans l'IDE, pour fournir type hinting, sont donc utiles
• autre, nous ne pas utiliser beaucoup: quelques lignes pour dire ce que la méthode ne s'il est pas évident; quelques lignes si l'on utilise un algorithme difficile.

Camel cas ou tout autre: nous nous en tenons à ce qui est commun parmi la communauté des PHP et des cadres:

this_is_a_function

ThisIsAClassName

thisIsAMethodName

En HTML: autant que possible, nous n'utilisons des commentaires HTML, car ils sont envoyés au navigateur:

• signifie de plus grandes pages (ok, pas beaucoup)
• signifie loin de donner des informations à l'utilisateur n'a pas besoin

Si possible, nous utilisons des commentaires du templating-moteur.

CSS: nous commentons en cas de besoin; chose la plus importante est d'utiliser plusieurs petits fichiers CSS, tout à fait spécifique (même si vous utilisez un outil de fusion au cours du processus de construction)

Mais, peut-être plus important que tout cela: nous essayons d'utiliser le code « propre », avec de petites méthodes qui font seulement une petite chose « unité », avec des noms autodescriptifs et tout

Il ne fait pas la magie, mais il aide à comprendre le code ... Et, aussi, le tester, le réutiliser, ...

En outre, comme Nate dit: Ce sont surtout des lignes directrices - sauf si spécifiquement requis par un client ... Dans ce cas, vous devez mettre un peu d'outil automatique (Dans votre processus de construction, par exemple) pour vérifier ils sont suivis par la lettre.