10
votes

Combien de lignes de code PHP est trop importante pour un fichier?

Je crée un fichier PHP qui fait 2 appels de base de données MySQL et que le reste du script est si des instructions pour des éléments tels que File_exists et d'autres variables simples. J'ai environ 2000 lignes de code dans ce fichier jusqu'à présent.

est-ce une meilleure pratique d'inclure un fichier distinct si une déclaration est vraie; ou simplement taper le code directement dans la déclaration IF elle-même?

est leur nombre maximal de lignes de code pour un seul fichier à respecter avec PHP?


0 commentaires

8 Réponses :


1
votes

Avez-vous besoin de vous concentrer sur le nombre de lignes? Non pas forcément. Assurez-vous simplement que votre code est organisé, efficace, et non inutilement verbeux.


0 commentaires

3
votes

2000 lignes de code dans un seul fichier n'est pas vraiment mauvais d'un point de vue de l'ordinateur, mais dans la plupart des situations est probablement évitable, jetez un coup d'oeil dans le Modèle de conception MVC , il vous aidera à mieux organiser votre code.

également, gardez à l'esprit que, y compris (beaucoup de) fichiers ralentiront l'exécution de votre code.


1 commentaires

Un cache de bytecode tel que APC prendrait soin du dernier problème.



0
votes

Cela n'a pas d'importance, tant que vous avez documenté votre code correctement, modularisé autant que possible et vérifié pour toute inefficacité. Vous pouvez bien avoir un fichier de 10 000 lignes. Bien que je sépare habituellement à environ 500-1000 pour chaque section d'une application.


0 commentaires

1
votes

Vous voudrez peut-être lire un livre comme Clean Code par Bob Martin . Voici quelques pépites de ce livre:

  • une classe devrait avoir une responsabilité
  • Une fonction devrait faire une chose et le faire bien

    avec PHP, si vous n'utilisez pas l'approche de la classe; Vous allez rencontrer des problèmes de duplication. Faites-vous une faveur et faites une certaine lecture sur le sujet; Cela vous fera économiser beaucoup plus de temps à prolonger et à entretien.


0 commentaires

9
votes

Je dirais qu'il ne devrait y avoir aucune question de performance liée au nombre de lignes dans vos fichiers PHP, cela peut être aussi grand que nécessaire.

Maintenant, pour les modèles et les meilleures pratiques, je dirais que vous devez juger par vous-même, j'ai vu de nombreux dossiers bien organisés de plusieurs milliers de lignes et beaucoup de fichiers réellement petits et difficiles à lire. Mon avantage serait:

  • juge la lisibilité du code source, toujours l'organiser bien.
  • Il est important d'avoir une séparation logique dans une certaine mesure, si votre fichier fait les deux: accès de base de données lourd, écriture, modification, rendu HTML, ajax et ainsi de suite .. Vous voudrez peut-être séparer des objets ou utiliser une approche orientée objet. < / li>
  • recherchez toujours l'équilibre entre la séparation logique et le code. Il ne devrait pas être désordonné ni extra-net avec beaucoup de fichiers de 10 lignes

2 commentaires

Les fichiers PHP sont traités dans son ensemble. Les fichiers importants, même s'ils contiennent du code non qualifié, aura un impact significatif sur la performance. Cependant, 2000 lignes ne sont pas le même ordre de grandeur que "grand".


Un cache de fonctionnement tel que APC peut s'occuper de ce problème, cependant.



2
votes

Le nombre de lignes n'est pas un bon indicateur de la performance. Assurez-vous que votre code est organisé efficacement, divisé en classes logiques ou en blocs et que vous ne combinez pas de code non apparenté dans des modules uniques.

L'un des problèmes d'une langue comme PHP est que, sauf une mise en cache créative, chaque ligne de chaque fichier incluse doit être tokenized, zippée par un arbre d'analyse et transformé en instructions significatives chaque fois que la page d'hébergement est demandée. Les plates-formes compilées comme .NET et Java ne souffrent pas de ce tueur de performance.

En outre, étant donné que l'une des autres affiches mentionnées MVC comme moyen de garder les fichiers abrégés: une bonne organisation de code est une fonction d'expérience et de bon sens et n'est en aucun cas liée à un modèle ou à une architecture particulière. MVC est intéressant, mais n'est pas une solution à ce problème.


4 commentaires

Un cache de fonctionnement comme APC - pas besoin d'être particulièrement créatif - prendra soin de la question de la compliation.


Vrai, mais aussi loin que je suis conscient, APC n'effectue toujours pas les nombreuses étapes d'optimisation dont les compilateurs natifs sont capables. Pas exactement des pommes-à-pommes.


De plus, .NET VS PHP (avec et sans APC) de référence: Brandonsavage.net/of-lies-Damned-lies-et-benchmarks-Rx


Bien sûr, cela ne sera pas aussi rapide qu'un langage compilé, mais comme vous l'avez dit, la comparaison est des pommes à oranges et n'a pas beaucoup de sens.



0
votes

Les lignes 2K sonnent trop pour moi ... bien que cela dépend de quel style de code vous suivez, par exemple. De nombreux lampes, de nombreuses petites fonctions ou de bons commentaires de contrat d'API peuvent augmenter la taille bien qu'ils soient bonnes pratiques. Le formatage de bon code peut également augmenter les lignes.

En ce qui concerne PHP, il serait bon de savoir: est-ce que des lignes 2K avec une seule classe ou une seule grosse incluent un code PHP non OOP? Est-ce mélangé avec des instructions de modèle et une logique de programmation (comme si je trouve souvent en code PHP)?

généralement je ne compte pas ces lignes, quand se faire scinder. Ils ont juste participé à des habitudes. Si le code est déroutant, je réagis et refacteur. Ayant toujours examiné du code que nous avons écrit récemment, je peux voir des modèles:

  • Fonction d'extraction / méthode si la taille est plus grande que 20LOC (sans commentaire) et utilisation des clauses if / else
  • extraire à une autre classe si taille> 200-300LOC
  • extraire dans un autre paquet / dossier si des artefacts> 10

    Toujours, cela dépend de ce que le type de code que j'ai. Par exemple, si des charges de logique sont impliquées (si / else / commutateur / pour), la fonction ACL par fonction diminue. S'il n'y a pratiquement aucune logique impliquée (des énoncés simples de codes One-Path), les limites augmentent. En fin de compte, la règle la plus importante est la suivante: un humain comprendrait-il le code. Sera-t-elle / il pourra bien le lire?


0 commentaires

0
votes

Je ne connais pas un moyen utile de fractionner le code qui est aussi simple, surtout si tout appartient ensemble sémantiquement.

Il est probablement plus intéressant de penser si vous pouvez éliminer une partie du code en refactorisant. Par exemple, si vous utilisez souvent une combinaison particulière de vérifications avec des variables légèrement différentes, cela pourrait aider à sous-traiter la combinaison de chèques dans une fonction et d'appeler le tout autant qu'il est approprié.
Je me souviens de voir un projet une fois qui était bien écrit pour la plupart, mais cela avait un problème de ce type. Par exemple, le code d'analyse de son fichier de configuration était dupliqué comme celui-ci: xxx

c'est un exemple extrême, mais vous obtenez l'idée.


0 commentaires