La Convention dit: "Les noms de champs non publics non statiques commencent par m. D'autres champs commencent par une lettre minuscule". Est-ce qu'il fait référence au champ de classe uniquement (comme dans l'exemple 1) ou à tous les champs (comme dans l'exemple 2)?
exemple 1 exemple 2
4 Réponses :
Dans votre deuxième exemple, MmeThodfieldoneOne MmeThodfieldTwo ne sont pas des champs, des variables locales à SOMEMETHOD , la convention de dénomination ne s'applique pas.
Il fait référence aux champs uniquement, qui sont les membres de la classe (= m ). Les autres sont variables locales .
Méthode interne Le modificateur d'accès (privé) n'est pas acceptable, compilez une erreur d'heure. "" Noms de champs non publiques non statiques commencent par M "signifie des variables d'instance, qui est le premier cas. Méthode intérieure, il va juste commencer par une petite lettre.
Désolé, c'était juste un exemple. J'ai fait copier et coller sans prendre trop de soin. Je l'ai réparé.
Ceci est une ligne directrice de contributeur android, pas la communauté Java.
Suivez les conventions de nommage sur le terrain Noms de champ non publiques et non statiques Commencez avec m.
Les noms de champ statiques commencent avec s.
D'autres champs commencent par une lettre minuscule.
Les champs finaux statiques publics (constantes) sont all_caps_with_underscores.
http://source.android.com/ Source / Code-style.html # Conventions de nommage sur le terrain
Quoi qu'il en soit, je pense que cela n'est pas nécessaire et n'est pas d'accord avec le style.
Notez que ces «champs» dans les méthodes que dans votre exemple ne compilent pas, le modificateur
privé est illégal là-bas. Cela devrait déjà avoir allumé une ampoule :)@Ballusc Désolé, c'était juste un exemple. J'ai fait copier et coller sans prendre trop de soin.
D'accord. Mon point a été, vous ne pouvez pas régler la visibilité des variables locales ni les rendre statiques, donc la déclaration «non publique, non statique» n'aurait aucun sens.
@Ballusc hahaha tu es absolument juste!
Je me demande encore pourquoi il y a des règles de codage Android lorsqu'il y a toujours été des règles de codage Java ...
@Snicolas pourquoi pas? Nous utilisons Java, mais la création de règles de codage spécifiques SDK rend ces applications distinctives. Comme, quand vous voyez un titre d'image IC_LAUNCHER_App, vous savez immédiatement que c'est une image de l'application Android.
@bergnam et vous touchez le point central; Il n'est absolument pas nécessaire de distinguer le code Android du code Java. Il n'y a pas de moyen spécial de programmer pour utiliser Swing ou toute autre API et Android ne diffère que par son API. Il vous aiderait à construire des modules de base Java pure dans les applications Android s'il n'y aurait aucune règle de codage spécifique, simplement parce que vous utilisez quelques classes Android.
@Snicolas vous avez raison, à moins que Google ait des projets pour l'avenir, comme faire de la langue Ajava :), de la même manière que Apple a fait l'objectif C. Juste une pensée ... mais franchement, je n'ai pas vu d'énormes différences d'Android Style de code, sauf qu'ils ont ajouté quelques suggestions sur la manière de nommer de nouvelles choses qui sont venues avec Android SDK. Pouvez-vous nommer ce que style Android a changé de Java d'origine?
@bergmam: Conventions Conding (à mon esprit absolument terriblement terrible et inutile) pour nommer des champs privés, des champs statiques. Les autres conventions ad hoc qui semblent ACKWARD comprennent ONXXX pour les méthodes d'événement, ONXXX pour les noms d'interface d'auditeur d'événements, une méthode d'enregistrement unique au niveau de l'auditeur à la place de l'enregistrement Common multiple d'auditeur (SetonxxxListener au lieu d'AddxxxListener / SuveXxxListener). Pas beaucoup, mais mal suffisamment, pas de valeur plus réelle ..
android: Stackoverflow.com/Questtions/2092098/...