Android private Felder benennen von Richtlinien sind ok?
Hier http://source.android.com/source/code-style.html#follow-field-naming-conventions es wird festgestellt, dass :
Feldnamen
- Nicht-öffentlichen, nicht-statischen Feld-Namen beginnen mit m.
- Statische Feld-Namen beginnen mit s -.
- Anderen Felder beginnen mit einem Kleinbuchstaben.
- Public static final Felder (Konstanten) sind ALL_CAPS_WITH_UNDERSCORES.
Es auch Staaten, die :
Den unten aufgeführten Regeln nicht die Richtlinien oder Empfehlungen, sondern strikte Regeln. Sie können nicht missachten die Regeln, die wir Liste unten außer als genehmigt, auf einer " need-to-use-basis.
Ich weiß nicht, wie das "m" Konvention vor private oder package-Felder in einer Klasse. Das finde ich echt dieses uninspiriert... ich meine, wenn wir versuchen, gute Entwürfe, die geringe Kopplung der Klassen setzt Voraus, dass die wenigen öffentlichen Bereichen. tatsächlich, meiner Programme, die ich haben in der Regel keine öffentlichen Felder, auch wenn ich einige ich benutze Getter und setter...
So, warum sollte ich gezwungen werden, haben fast alle meine Felder im Programm mit einem "m" vor Ihnen? wäre das nicht einfacher sein, haben die wenigen öffentlichen Bereichen, falls vorhanden, mit einem "g" vor, oder was? oder nutzen Sie einfach setter und Getter als Bohnen empfehlen?
das ist wirklich mein code schwerer zu Lesen....
Auch, die sich an folgenden Leitlinien, lokale temp-Variablen der Methoden haben keine Einschränkungen, so dass Sie leicht verwechselt werden könnte, für öffentliche Globale Felder (auch ohne Einschränkungen)... auch dies finde ich falsch, denn es ist eine wahrscheinliche Quelle für Fehler...
Ich verstehe, dass Sie ein Weg der Differenzierung von Feldern, sondern private/protected member Felder sind die in einer Applikation verwendet, sollte Sie nicht weniger "lesbar".
Was denkst du? Sollte ich befolgen Sie die Richtlinien?
- Einer der Gründe, Präfixe wie diese sind oft beauftragt ist, um zu verhindern, dass ausblenden der member-Feldern. Zum Beispiel, Sie haben oft ein parameter für einen Konstruktor oder eine setter-Methode, die den gleichen Namen wie das Mitglied Feld, wenn Sie don ' T haben keine Präfixe. In solchen Fällen haben Sie dann Zugriff auf den member-Bereich mit "dies." vor, wenn es ausgeblendet ist. Programmierer gelegentlich vergessen, die "diese.", das führt zu bugs. Ein Präfix auf öffentlichen Feldern ist nicht so nützlich, da es keine Notwendigkeit für eine Set-auf einem öffentlichen Feld sowieso.
- ich eigentlich lieber die m_ Präfix auf private Felder, weil es macht Ihre Klasse Methoden leichter zu Lesen. Diese Konventionen verwendet werden, da der code gelesen wird, mehr als Ihr geschrieben... ich denke, das ist im Code Komplett irgendwo?...
- ich Stimme mit Ihnen.. ich mag nicht das "m" - convention, und ich bin glücklich ihn nicht benutzen
Du musst angemeldet sein, um einen Kommentar abzugeben.
Diese kodierrichtlinien sind für die Android-Open-Source-Projekt, das den Kern Android-Plattform. Sie haben zu Folgen Sie diesen Richtlinien, wenn Sie möchten, dass alle Ihre code akzeptiert zu werden in die core-Plattform. Sie können tun, was immer Sie wollen, in Ihren eigenen Anwendungen.
Mit Bezug auf die Richtlinien selbst ich denke, Sie sind sehr vernünftig und ähnlich viele standards in kommerziellen Anwendungen. In der Regel, die Sie verwenden möchten Getter und setter für den öffentlichen Bereich zugreifen und Sie nicht wollen, zu globalen public-Variablen. Nur Globale öffentliche Konstanten sind ok.
Also die kurze Antwort ist Ihnen Folgen für die Open-Source-Projekt, entscheiden Sie, Ihnen zu Folgen, in Sie app.
In Bezug auf Getter\setter, es ist eigentlich empfohlen, um nicht in Android.
Ich fand diese auf der "Designing for Performance" Seite (Abschnitt: Vermeiden Interne Getter/Setter): http://developer.android.com/guide/practices/design/performance.html
Bottom line, Sie folgern, dass Instanz-Feld-lookups effizienter sind als Virtuelle Methode fordert (aufgrund von Optimierungen in der JIT).
Ich denke, ich werde weiterhin zu verwenden, get\setter in meinem code, aber dies wäre eine einfache Möglichkeit, um die Leistung zu verbessern (insbesondere für apps, die eine Menge von Daten-manipulation).