Java-Codierungskonvention über statische Methode

Ich glaube, die Java-Kodierungsstandards von Sun (jetzt Oracle) werden häufiger verwendet. Das verwenden Sie auch gerade.

Von Code-Konventionen für die Programmiersprache Java TM :

  

3.1.3 Deklarationen von Klassen und Interfaces

     

Die folgende Tabelle beschreibt die Teile einer Deklaration einer Klasse oder einer Schnittstelle in der Reihenfolge, in der sie stehen   sollte erscheinen.

     

1. Kommentar zur Klasse / Schnittstellendokumentation (/*.../)
  
2. class oder interface Anweisung
  
3. Kommentar zur Implementierung der Klasse / Schnittstelle (/ .../), falls erforderlich
  
4. Klasse ( static ) Variablen
  
5. Instanzvariablen
  
6. Konstruktoren
  
7. Methoden
  

Persönlich verwende ich Option 2 (statische Felder und Methoden vor Instanzelementen und Konstrukten). Für mich ist das sinnvoll, wenn ich eine Datei scanne, weil ich von einem Benutzer einer Klasse auf das statische Material zugreifen kann, ohne eine Instanz zu benötigen. Daher ist es schön, sie vor den Konstruktoren zu sehen, weil mir Konstruktoren bei der Verwendung von statischem Material egal sind.

Nur aus dem GWT-Artikel, den Sie verlinkt haben:

  

Wir erkennen an, dass es viele großartige Ansätze gibt. Wir versuchen nur eine auszuwählen, die zumindest den Java-Kodierungskonventionen von Sun entspricht ...

Also der Stil, den sie benutzen

1. wird für GWT nicht zur allgemeinen Verwendung vorgeschlagen
2. weicht etwas von den Standardkonventionen ab
3. gilt als einer von vielen guten Standards

Also würde ich sagen, wenn es keinen Grund gibt, nicht bei Ihren derzeitigen Konventionen zu bleiben, warum sollten Sie sie ändern?

Die Java-Code-Konventionen schlagen folgendes vor (was im Grunde das ist, was Sie tun bereits tun):

• Klassen (statische) Variablen: Zuerst die öffentlichen Klassenvariablen, dann die geschützte, dann die Paketebene (kein Zugriffsmodifikator) und dann die private
• Instanzvariablen: Erst öffentlich, dann geschützt, dann Paketebene (kein Zugriffsmodifikator) und dann privat
• Konstruktoren
• Methoden: Diese Methoden sollten nach Funktionalität und nicht nach Umfang oder Zugänglichkeit gruppiert werden. Eine private Klassenmethode kann beispielsweise zwischen zwei öffentlichen Instanzmethoden liegen. Ziel ist es, das Lesen und Verstehen des Codes zu erleichtern.

Ich weiß nicht, aber für das, was es wert ist, tue ich, was Sie tun. Konstruktoren oben, Methoden gruppiert nach Funktionalität (ohne Berücksichtigung der Statik) unten. Statische Methoden neigen zur Gruppierung.

Die Ausnahme sind statische Factory-Methoden, die ich anstelle von Konstruktoren verwenden soll - wenn dies der Fall ist, sind sie vor den Konstruktoren und die Ctors sind private / protected.

Es ist natürlich alles eine Frage der Vorliebe ...

Ihre Konvention ist konsistenter mit der Standardreihenfolge in Javadoc (d. h. statische und nicht-statische Methoden zusammen). Das mache ich normalerweise auch.

Jedoch werden innere Klassen oft am Ende einer Klasse platziert, da sie oft "sekundäre" oder "Helfer" -Klassen sind und es seltsam erscheint, sie vor das Hauptfleisch des äußeren zu setzen Klasse.

Ich setze statische Initialisierer und Methoden vor den Konstrukteuren, also denke ich, dass ich Ihrem Zitat folge.

Warum das Unbehagen? Es scheint wie eine kleine Sache.