En 2024, nous avons analysé de nombreux projets et partagé nos découvertes sur notre blog. C'est maintenant le réveillon du Nouvel An : il est temps de raconter des histoires festives ! Nous avons rassemblé les erreurs Java les plus intrigantes détectées dans les projets open source et vous les présentons désormais !
Nous avons longtemps maintenu la tradition de publier les bugs les plus intéressants détectés avec PVS-Studio, mais il n'y a pas eu de top lié à Java depuis 2020 ! Cette fois, j'ai essayé de ressusciter la rubrique vintage. J'espère que vous avez une couverture douillette et une tasse de thé chaude à portée de main, car j'ai sélectionné plus de 10 insectes amusants rien que pour vous. Voici comment ils ont été classés :
Préparez-vous pour 10 histoires divertissantes avec leur propre sagesse de programmation : le réveillon du Nouvel An arrive bientôt après tout :)
En dixième place, le premier extrait de code nous accueille à bras ouverts.
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Je n'ai pas pu m'empêcher de l'inclure dans le top du réveillon car un bug dans ce code nous permet de voyager plus rapidement vers l'année suivante :) Devinez d'où vient le bug ?
Jetons un coup d'œil à l'argument passé au constructeur SimpleDateFormat. Cela semble-t-il valable ? Si on y passe presque n'importe quelle date, comme la date de rédaction de cet article (12/10/2024), le code renverra la valeur correcte, 20241210.
Cependant, si nous dépassons le 29/12/2024, il renverra 20251229 à la place, passant ainsi ingénieusement au début de la nouvelle année. Au fait, voyager dans le temps est également faisable.
Cela se produit parce que le caractère Y dans l'argument de SimpleDateFormat représente l'année en fonction du numéro de la semaine. En bref, une semaine est considérée comme la première lorsqu'elle comprend au moins quatre jours de la nouvelle année. Ainsi, si notre semaine commence un dimanche, nous pouvons entrer dans la nouvelle année trois jours plus tôt.
Pour résoudre ce problème, remplacez simplement un Y majuscule par un y minuscule. Vous voulez en savoir plus ? Nous avons consacré un article entier à ce sujet.
Voici un avertissement PVS-Studio pour cette erreur :
V6122 L'utilisation du modèle « Y » (semaine année) a été détectée : il était probablement prévu d'utiliser « y » (année). SkeinParameters.java 246
En raison des spécificités du numéro de semaine, les tests ne sont donc pas le meilleur ami pour trouver cette erreur. Alors pourquoi un bug aussi actuel arrive-t-il en dernier lieu ? La raison est que l'avertissement ne provient pas de la version actuelle de Bouncy Castle mais de notre base de tests. Les anciennes sources restent toujours là, et ce bug est corrigé depuis longtemps. C'est un tel salut du passé, juste un nouveau voyage dans le temps :)
En neuvième place, nous avons l'avertissement de l'analyse GeoServer :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
Voici l'avertissement PVS-Studio :
V6027 Les variables 'newValue', 'oldValue' sont initialisées via l'appel à la même fonction. Il s'agit probablement d'une erreur ou d'un code non optimisé. DataAccessRuleDAOTest.java 110, DataAccessRuleDAOTest.java 111
Qu'est-ce qu'il y a d'intéressant dans une telle erreur ? Laissez-moi vous révéler ce qui se cache derrière les quatre points :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Il y a un commentaire indiquant que le code ne fonctionne pas pour une raison quelconque. Honnêtement, ça m'a fait rire la première fois que je l'ai vu.
Le commentaire est cependant plutôt ambigu. Il est probable que le test ait été écrit de cette façon intentionnellement pour éviter un échec alors que la comparaison est en baisse. Cependant, le code est dans cet état depuis plus d’une décennie, ce qui soulève certaines questions. Cette ambiguïté est la raison pour laquelle je ne le classe pas plus haut.
Si nous ne pouvons pas appeler les bugs de JBullet des coups dans le pied, je ne sais pas lesquels nous pouvons appeler ainsi. Voici une erreur de l'article :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
Je pense que nous n'avons même pas besoin de l'avertissement PVS-Studio pour repérer où se trouve l'erreur. Quoi qu'il en soit, juste au cas où, le voici :
V6026 Cette valeur est déjà affectée à la variable 'proxy1'. HashedOverlappingPairCache.java 233
Oui, c'est une erreur d'une simplicité embarrassante. Cette simplicité le rend encore plus hilarant. Néanmoins, il a sa propre histoire.
La bibliothèque JBullet est un portage de la bibliothèque Bullet C/C, et il y a une fonction similaire ici :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// properties equality does not seem to work...
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key);
Assert.assertEquals(newValue, oldValue);
}
}
Il est facile de voir que ce code est écrit correctement. À en juger par le blâme de git, il est initialement écrit correctement. Il s'avère que l'erreur s'est produite lorsque le code a été porté d'une langue à une autre.
Pour sa simplicité frappante associée à une histoire riche, j'attribue à cet avertissement la huitième place. J'espère que vous avez apprécié le fait que le bug de la balle dans le pied s'est avéré être lié au C.
Certes, le prochain avertissement me réchauffe le cœur pour plusieurs raisons. Voici un extrait de code de la vérification GeoGebra :
@Override
public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) {
BulletStats.gFindPairs++;
if (proxy0.getUid() > proxy1.getUid()) {
BroadphaseProxy tmp = proxy0;
proxy0 = proxy1;
proxy1 = proxy0;
}
....
}
Essayez de trouver l'erreur vous-même ! Pour vous empêcher de jeter un coup d'œil, j'ai caché l'avertissement et l'explication dans un spoiler.
V6107 La constante 0,7071067811865 est utilisée. La valeur résultante pourrait être inexacte. Pensez à utiliser Math.sqrt(0.5). DrawAngle.java 303 En réalité, 0,7071067811865 n'est pas un nombre magique, c'est simplement le résultat arrondi de la racine carrée de 0,5. Mais à quel point cette perte de précision est-elle critique ? GeoGebra est un logiciel conçu pour les mathématiciens, et une précision supplémentaire ne semble pas faire de mal. Pourquoi est-ce que j'aime tant ce bug ? Tout d'abord, lors des conférences, je demande souvent aux participants de trouver une erreur similaire dans d'autres fragments de code. Les regarder analyser attentivement le code lorsque le bug est dissimulé dans une constante a toujours été amusant. Deuxièmement, il s'agit de ma première règle de diagnostic implémentée pour l'analyseur Java. C'est pourquoi je n'ai pas pu m'empêcher de l'inclure en haut – même en étant conscient des préjugés – je l'ai mis à la septième place :)La réponse
Tout d'abord, regardons l'avertissement de PVS-Studio :
L'avertissement suivant, que j'ai tiré du premier article basé sur la vérification DBeaver, n'attirera peut-être pas immédiatement notre attention. Voici un fragment de code :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Voici ce que l'analyseur PVS-Studio a détecté :
V6082 Verrouillage non sécurisé à double vérification. Le champ doit être déclaré comme volatile. TaskImpl.java 59, TaskImpl.java317
Bien qu'il n'y ait rien de spécial à propos de cet avertissement particulier, je le trouve toujours très intriguant. Le fait est que le modèle de verrouillage à double vérification appliqué ne fonctionne pas. Quelle est l'astuce ? C'était pertinent il y a 20 ans :)
Si vous souhaitez en savoir plus sur le sujet, je vous suggère de lire l'article complet. Mais pour l'instant, permettez-moi de vous donner un bref résumé.
Le modèle de verrouillage à double vérification est utilisé pour implémenter une initialisation retardée dans des environnements multithread. Avant le contrôle « lourd », le contrôle « léger » est exécuté sans bloc de synchronisation. La ressource n'est créée que lorsque les deux vérifications réussissent.
Cependant, dans cette approche, la création d'objets est non atomique et le processeur et le compilateur peuvent modifier le ordre d'opération. Ainsi, un autre thread peut accidentellement recevoir un objet partiellement créé et commencer à travailler avec lui, ce qui peut entraîner un comportement incorrect. Cette erreur peut rarement se produire, le débogage sera donc un énorme défi pour les développeurs.
Voici une variante : ce modèle n'a pas fonctionné jusqu'au JDK 5. À partir du JDK 5, le mot-clé volatile a été introduit pour résoudre le problème potentiel de réorganisation des opérations grâce au principe arrive-avant. L'analyseur nous prévient que nous devons ajouter ce mot-clé.
Cependant, il serait préférable d’éviter ce schéma de toute façon. Les performances du matériel et de la JVM ont beaucoup progressé depuis, et les opérations synchronisées ne sont plus aussi lentes. Cependant, une mauvaise mise en œuvre du modèle DCL reste un piège courant, avec les conséquences potentiellement graves décrites ci-dessus. Cela confirme le fait que notre analyseur trouve encore de telles erreurs de négligence dans les anciens projets.
La cinquième place revient à un autre avertissement DBeaver auquel nous avons consacré un article. Jetons-y un coup d'oeil :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
Voici une explication :
V6030 La méthode située à droite de l'opérateur '&' sera appelée quelle que soit la valeur de l'opérande de gauche. Il est peut-être préférable d'utiliser « && ». ExasolTableColumnManager.java 79, DB2TableColumnManager.java 77
Le développeur a mélangé le && logique avec le & au niveau du bit. Ils ont un comportement différent : les conditions de l'expression ne se terminent pas après le ET au niveau du bit. L'évaluation de court-circuit ne fonctionne pas pour ET au niveau du bit. Ainsi, même si exasolTableBase != null renverra false, le thread d'exécution atteindra exasolTableBase.getClass() et mènera à un NPE.
D'accord, c'est juste une faute de frappe, passons à autre chose, d'accord ? DBeaver contient de nombreux avertissements de ce type. Beaucoup. Beaucoup sont relativement inoffensifs, mais pour les lecteurs curieux, j'ai laissé quelques exemples ci-dessous :
ExasolConnectionManager.java : ExasolDataSource.java :Utiliser des opérations au niveau du bit qui n'entraînent pas d'erreurs
ExasolSecurityPolicy.java :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// properties equality does not seem to work...
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key);
Assert.assertEquals(newValue, oldValue);
}
}
Après avoir creusé plus profondément, mon équipe a supposé que les développeurs auraient pu essayer de micro-optimiser les performances. Pour une image complète, vous pouvez consulter notre article – ici, je présente un résumé.
Le point clé est que les opérations au niveau du bit ne reposent pas sur des prédictions de branche, ce qui permet potentiellement une exécution plus rapide par rapport aux opérations logiques.
À notre grande surprise, une référence locale soutient cette affirmation :
Le tableau illustre le temps requis pour chaque type d'opération. Si nous lui faisons confiance, les opérations au niveau du bit semblent être 40 % plus rapides que les opérations logiques.
Pourquoi est-ce que j'aborde ce sujet ? Mettre en évidence le coût des micro-optimisations potentielles.
Tout d'abord, les développeurs ont inventé la prédiction de branche pour une raison : il serait trop coûteux de l'abandonner. Ainsi, le benchmark fonctionne probablement plus rapidement car les valeurs ont une distribution normale, ce qui est peu susceptible d'être observé dans des cas réels.
Deuxièmement, l'abandon du mécanisme d'évaluation des courts-circuits peut entraîner des coûts considérablement plus élevés. Si nous regardons le troisième exemple du spoiler ci-dessus, nous pouvons voir que l'opération contain la plus rapide ne s'exécutera pas tout le temps au lieu de s'arrêter rapidement.
Troisièmement, nous donnons carte blanche pour de telles erreurs dès le début du chapitre.
Dans l’ensemble, je trouve le récit édifiant du prix de la micro-optimisation suffisamment convaincant pour ouvrir notre top cinq.
Les tests automatisés sont souvent considérés comme la garantie ultime contre diverses erreurs. Cependant, de temps en temps, je suis tenté de demander : « Qui teste les tests lui-même ? Un autre avertissement de la vérification GeoServer le démontre une fois de plus. Voici un fragment de code :
@Override
public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) {
BulletStats.gFindPairs++;
if (proxy0.getUid() > proxy1.getUid()) {
BroadphaseProxy tmp = proxy0;
proxy0 = proxy1;
proxy1 = proxy0;
}
....
}
L'avertissement PVS-Studio :
V6060 La référence 'e' a été utilisée avant d'être vérifiée par rapport à null. ResourceAccessManagerWCSTest.java 186, ResourceAccessManagerWCSTest.java 193
À première vue, cet avertissement peut ne pas sembler être le plus excitant de l'analyseur, car le V6060 est souvent émis pour du code redondant. Pourtant, j'ai promis de sélectionner les candidatures en fonction de leur attrait. Cette affaire est donc bien plus intéressante qu’il n’y paraît.
Au départ, la logique du test peut sembler erronée car la variable e est obtenue à partir de l'opérateur catch et reste inchangée, elle ne sera donc jamais nulle. Nous pouvons simplement effectuer une modification parasite et supprimer la branche then de la condition if(e == nul) comme inaccessible. Pourtant, ce serait radicalement faux. Avez-vous déjà compris le piège ?
La clé réside dans une variable supplémentaire dans le code qui contient l'objet d'exception, c'est un soi. Sa valeur change dans le corps de la boucle. Ainsi, on peut facilement deviner que dans la condition, il devrait y avoir la variable se au lieu de e.
Cette erreur fera que la branche then ne sera jamais exécutée, nous ne saurons donc pas qu'il n'y a pas d'exception. Pire encore, il est assez difficile de remarquer une telle erreur lors d'une revue de code car les noms de variables sont terriblement similaires.
Il y a deux sagesses à tirer de cette histoire :
Pour avoir dispensé des leçons aussi précieuses, j'attribue à cet avertissement la quatrième place.
Les trois premiers gagnants appartiennent à l'avertissement du chèque NetBeans. Les extraits de code précédents étaient relativement compacts, alors regardons-en un plus long :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Pour la dernière fois, essayez de trouver le bug vous-même, j'attendrai...
Vous recherchez ?
Bien ! Ceux qui ont trouvé l'erreur uniquement dans l'expression iDesc.neighbor != null || iDesc.index == iDesc.index, je suis désolé de vous dire que vous avez perdu :)
Bien sûr, il y a un problème, mais il n'est pas assez intéressant pour celui du haut. Oui, il y a deux erreurs ici, je vous ai un peu trompé. Mais que sont les vacances sans un peu de malice ? :)
L'analyseur a détecté une erreur dans l'expression i^i ici et a émis l'avertissement suivant :
V6001 Il y a des sous-expressions identiques 'i' à gauche et à droite de l'opérateur '^'. LayoutFeeder.java 3897
L'opération XOR n'a aucun sens car le OU exclusif avec deux valeurs identiques sera toujours nul. Pour un rappel rapide, voici la table de vérité pour XOR :
| a | b | a^b |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
En d'autres termes, l'opération n'est vraie que lorsque les opérandes sont différents. Nous aurons tous les bits pareils, puisque la valeur est la même.
Pourquoi ai-je autant aimé ce bug ? Il existe l'opération i^1, qui semble presque identique à i^i. Ainsi, il serait incroyablement facile de rater cette erreur lors d'une révision de code, puisque nous avons déjà vu le bon i^1 ci-dessus.
Je ne sais pas vous, mais ça me rappelle le fameux :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Sinon, il est difficile d'expliquer comment cela est entré dans le code, à moins que nous rejetions la version ennuyeuse avec une simple faute de frappe. Si vous avez réussi à repérer ce bug, félicitez-vous ou partagez vos talents de détective dans les commentaires :)
J'ai déjà montré les erreurs des premier et troisième articles de DBeaver, en sautant le deuxième. Je me trompe : ce qui suit provient uniquement du deuxième article.
L'analyseur PVS-Studio n'aime pas que isBinaryContents soit appelé depuis le constructeur de la classe TextWithOpen, qui est remplacé dans les sous-classes :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
Et alors ? C'est annulé, mais ce n'est pas grave. Cela ressemble à une odeur de code, rien de critique. Du moins, c'est ce que je pensais. J'ai consacré un article à ma lutte contre ce bug.
TextWithOpen a de nombreuses sous-classes, et l'une d'entre elles est TextWithOpenFile. Là, la méthode est en fait remplacée, et au lieu de false, elle renvoie un champ que la superclasse n'a pas :
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// properties equality does not seem to work...
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key);
Assert.assertEquals(newValue, oldValue);
}
}
Encore suspect ? À quoi ressemble le constructeur de cette classe ?
@Override
public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) {
BulletStats.gFindPairs++;
if (proxy0.getUid() > proxy1.getUid()) {
BroadphaseProxy tmp = proxy0;
proxy0 = proxy1;
proxy1 = proxy0;
}
....
}
Vous avez remarqué ça ? Le champ binaire est initialisé après l'appel du constructeur de superclasse. Cependant, il y a un appel à la méthode isBinaryContents, qui fait référence au champ de la sous-classe !
Voici l'avertissement PVS-Studio :
V6052 L'appel de la méthode 'isBinaryContents' remplacée dans le constructeur de classe parent 'TextWithOpen' peut conduire à l'utilisation de données non initialisées. Inspecter le champ : binaire. TextWithOpenFile.java(77), TextWithOpen.java 59
C'est une image plutôt amusante. À première vue, le développeur semblait suivre les meilleures pratiques : éviter les spaghettis de code, impossibles à maintenir, et essayer d'implémenter la POO canonique via un modèle de méthode modèle. Mais même en mettant en œuvre un modèle aussi simple, nous pouvons commettre une erreur, et c’est ce qui s’est produit. À mon avis, une telle beauté (fallacieuse) dans la simplicité est une solide deuxième place.
Réjouissez-vous ! La première place sur scène ! La concurrence était rude, mais il fallait faire un choix. Après de longues délibérations, j'ai décidé de prendre en compte l'avertissement de la vérification NetBeans. Permettez-moi de vous présenter l'extrait de code final :
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
Je suis convaincu qu'il est impossible de repérer un tel bug d'un seul coup d'œil, à moins, bien sûr, que vous ayez commis cette erreur vous-même. Je ne vous ferai pas attendre, voici l'avertissement PVS-Studio :
V6009 La capacité du tampon est définie sur « 47 » à l'aide d'une valeur de caractère. Très probablement, le symbole « / » était censé être placé dans le tampon. IgnorerUnignoreCommand.java 107
En fait, l'erreur est ridiculement élémentaire : le constructeur StringBuilder n'a pas de surcharge qui accepte les caractères. Quel constructeur est alors appelé ? Le développeur pensait apparemment qu'une surcharge acceptant String serait appelée, et que la valeur initiale de StringBuilder serait alors cette barre oblique.
Cependant, une conversion de type implicite se produit et le constructeur de type qui accepte int est appelé. Dans notre cas, il représente la taille initiale de StringBuilder. Passer char comme argument n’affecte fonctionnellement rien car il ne sera pas inclus dans la chaîne finale. Si la taille initiale est dépassée, elle augmentera simplement d'elle-même sans provoquer d'exceptions ni d'autres effets secondaires.
Mais attendez, j'ai mentionné deux erreurs, n'est-ce pas ? Où est le deuxième et comment sont-ils connectés ? Pour repérer cela, nous devrons lire le corps de la méthode et comprendre ce que fait ce code.
Il génère un chemin absolu vers un fichier ou un répertoire. D'après le code, le chemin résultant devrait ressembler à ceci :
Le code semble tout à fait correct. C'est le problème. Le code fonctionne vraiment comme il se doit :) Mais si nous corrigeons l'erreur en remplaçant un caractère par une chaîne, nous obtiendrons ceci au lieu du résultat correct :
En d’autres termes, nous aurons une barre oblique supplémentaire à la fin de la chaîne. Ce sera à la fin car le code ci-dessus ajoute à chaque fois un nouveau texte au début de la ligne.
Par conséquent, la deuxième erreur est que cette barre oblique a été transmise au constructeur comme argument. Cependant, je ne sous-estimerais pas une telle erreur car si quelqu'un décide de remplacer un caractère par une chaîne sans vérifier, il peut y avoir des problèmes.
C'est ainsi que la première place dans le top des erreurs revient au code qui fonctionne correctement. Les miracles du Nouvel An, à quoi vous attendiez-vous ? :)
J'espère que vous avez aimé lire mes histoires de bugs. Si une histoire particulière vous a marqué – ou si vous avez des suggestions d'ajustements au classement – n'hésitez pas à partager vos impressions dans les commentaires, je les garderai en tête pour la prochaine fois :)
Si d'autres langages vous intéressent, je vous invite à consulter les principaux bugs C# pour 2024 ici : restez à l'écoute pour les nouveaux tops !
Toutes ces erreurs ont été détectées avec l'analyseur PVS-Studio, et la dernière version (7.34) vient de sortir ! Vous pouvez l'essayer par ce lien.
Pour rester à l'affut des nouveaux articles sur la qualité du code, nous vous invitons à vous abonner :
Bonne année !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment utiliser debug.exe
disposition absolue
Raisons pour lesquelles phpstudy ne peut pas être ouvert
Une liste complète des commandes alter dans Mysql
Quelle est la différence entre php et java
Solution http500
Une fois l'ordinateur allumé, le moniteur n'affiche aucun signal
Comment utiliser la fonction choisir
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
