67 java

[pataluc]

Rule now only reports when i++ is in statement.

Issue #4

[cyChop]

Quid d'un test case (compliant) int a = 2 + counter++ ?
(Normalement couvert par bar61(2 + counter++), mais ce cas était également déjà couvert par bar61(counter++).)

[pataluc]

Quid d'un test case (compliant) int a = 2 + counter++ ? (Normalement couvert par bar61(2 + counter++), mais ce cas était également déjà couvert par bar61(counter++).)

après discussion avec @dedece35 hier, au final on ne cherche que les cas ou le parent de i++ est une Kind.EXPRESSION_STATEMENT, parce que les autres cas sont soit volontaires, soit des code smells déjà reporté par les règles Sonar hors ecocode. du coup je ne suis pas sûr que cela apporte qqchose de rajouter ce cas (même si c'est très simple de l'ajouter)

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[dedece35]

Quid d'un test case (compliant) int a = 2 + counter++ ? (Normalement couvert par bar61(2 + counter++), mais ce cas était également déjà couvert par bar61(counter++).)

après discussion avec @dedece35 hier, au final on ne cherche que les cas ou le parent de i++ est une Kind.EXPRESSION_STATEMENT, parce que les autres cas sont soit volontaires, soit des code smells déjà reporté par les règles Sonar hors ecocode. du coup je ne suis pas sûr que cela apporte qqchose de rajouter ce cas (même si c'est très simple de l'ajouter)

Hello ... merci pour la précision ... mais peut-être qu'on s'est mal compris, perso, je serai aussi pour checker le uses case de @cyChop même si je pense qu'il est déjà couvert (ça ne coute rien de rajouter un cas de test dans les fichiers de tests et voir ce qui se passe en TU, puis en test env reel et vérifier si SonarQube remonte déjà un code smell natif sur ces cas là)
Donc, je préfère tout de meme rajouter du check et du test pour vérifier please.

[dedece35]

cf les commentaires ci-dessus

[github-actions]

This PR has been automatically marked as stale because it has no activity for 30 days.
Please add a comment if you want to keep the issue open. Thank you for your contributions!