Après une mise à jour d'Android Studio, je reçois des avertissements sur des champs tels que :
public int ex1 = 0;
int ex2 = 0;ou des méthodes ou des classes imbriquées lorsqu'ils ne sont utilisés que dans une classe ou dans le paquet :
"L'accès peut être privé" ou "L'accès peut être réservé aux paquets".
C'est possible, et je ne veux pas de ces avertissements mais je ne trouve pas comment les désactiver. Avez-vous une idée ?
Vous pouvez également mettre cette annotation en tête de votre classe :
@SuppressWarnings("WeakerAccess")
Bien que cela soit possible, cette annotation devrait être ajoutée dans la base de données de l'UE. chaque fichier unique - Et il faut l'ajouter. C'est une réponse valide donc j'ai upvoted, mais c'est vraiment fastidieux si je dois écrire cette annotation dans chaque fichier java. La modification des paramètres reste la solution la plus simple (pour moi).
Ah, ça a mieux marché pour moi, parce que je voulais seulement désactiver certaines classes de données.
Cela dépend de l'utilisation. Cela fonctionne aussi, et c'est pratique si vous le voulez pour quelques classes seulement (c'est une réponse valide, et cela fonctionne). J'ai upvoted parce que cette réponse fonctionne toujours, mais pour mon utilisation, il est préférable de désactiver globalement.
Dans ce cas, je préfère conserver l'avertissement, mais de manière plus faible. J'ai réglé cette inspection sur avertissement faible et... modifiez la sévérité de l'avertissement le plus faible pour qu'il ne montre pas la marque d'erreur sur le côté droit, ce qui est gênant. J'espère que cela vous aidera. :)
Il suffit de désactiver l'inspection qui déclenche cet avertissement. Tiré de "Page "Inspections de suppression dans l'aide d'IntelliJ :
Pour supprimer une inspection dans l'éditeur
<inspection name> d'options.En appuyant sur la touche fléchée gauche, ou masque la liste des suggestions. Dans la liste des options de contrôle, sélectionnez l'action de suppression souhaitée
L'inspection sera supprimée avec des commentaires spéciaux dans le fichier code correspondant.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Mais n'est-ce pas une bonne chose à suivre ?
7 votes
Pas vraiment. Si l'accès peut être privé mais que je le configure en public, je peux vouloir l'utiliser en public plus tard.
0 votes
Écrire du code pour des cas futurs qui n'existent pas encore conduira à un code inutilement compliqué
3 votes
Considérez que vous avez une méthode : Vous l'appelez à l'ouverture de l'application et pendant toute la durée de vie de l'application. L'appel interne est ajouté, mais la classe externe n'est pas encore ajoutée. Vous avez toujours besoin de la classe et de la méthode, mais vous voulez garder l'accès à public pour ne pas avoir à le changer plus tard. Dans ces cas, ces avertissements sont dans le chemin, et le code est nécessaire, mais il y aura plus d'appels dans le futur à partir de sources externes et internes.
1 votes
@ChintanSoni Pas quand il se trompe !
2 votes
J'ajouterais également que l'on peut créer une bibliothèque et que la méthode doit être publique. Lorsque vous créez uniquement le code de votre bibliothèque et les tests unitaires, package private suffira. Il est donc bon de désactiver ces avertissements pour mieux exposer les avertissements qui peuvent être importants.
0 votes
J'obtiens ce résultat même lorsque les données membres sont accessibles en dehors de la classe ! Quelqu'un d'autre ?