OBS/Adminhilfe/Code-Guideline
Dies ist eine zugriffsgeschützte Seite.
- System Überwachung
- DEP deaktivieren
- Darstellung unter Windows 7
- Einwahl auf Windows 2000 Server
- Preislisten
- Datenbank Sicherung
- Customize
- Zentrale
- Support Macro
- Service Debug
- Historienprotokoll (Datenänderung OBS)
- Fernwartungsprobleme
- Startparameter
- Fehler beim Kassenabschluss
- Diverse Informationen
- A ras.pbk
- B Command Line Interpreter
- C File Zilla Benutzer XML erzeugen
- D1 OBS_UPDATE.EXE zum OBS Update Server hochladen
- D2 SUPPORT_MACRO zum OBS Update Server hochladen
- H1 Remote Service Protokoll-Übersicht (Alles)
- H Remote ServiceProtokoll-Übersicht
- I Remote Service Commands
- I1 (Admin) Globaler Hinweis für Updates
- J Liste der OBS Updates
- K Angemeldete Service Firmen
- L Systeminformationen einlesen
- M Kundendaten anzeigen
- M1 Kundendatenbankinformationen anzeigen
- N Kundendaten einlesen
- O Kunden-Update Informationen anzeigen
- P Modul Registrierung OBS
- Q App Verwaltung
- S1 Firmen Statistik Protokolle OBS
- S2 Statistik Notfallkassen
Hier findet Ihr unsere interne Code-Guideline. Bitte nur in Absprache ändern.
Deklarationen
Namensgebungen
Der Name muss immer aussagekräftig und für das gesamte Team verständlich sein. Hier ein paar Faustregeln die beachtet werden sollten.
Types (Classes, Interfaces, Structs)
Der Name sollte eine Nominalphrase sein.
Schlecht: Glücklich (Happy) Gut: Glücklichkeit (Happiness)
Namensräume (Namespaces) nutzen anstatt Prefixe.
Schlecht: SystemOnlineMessage Gut: System::Online::Message
Nur so viele Adjektive nutzen die man braucht.
Schlecht: IAbstractFactoryPatternBase Gut: IFactory
Nutzt keine sinnlosen Phrasen wie “Manager” oder “Helper” in einem Type-Namen.
Wenn man dennoch einen “Manager” oder “Helper” braucht, ist die Deklaration schlecht benannt oder schlecht aufgebaut (designed). Type's sollten sich selbst managen und helfen.
Schlecht: ConnectionManager
XmlHelper
Gut: Connection
XmlDocument, XmlNode, etc.
Wenn eine Klasse schwierig benannt werden kann oder nichts passendes einfällt, versuche eine Metapher zu finden.
Schlecht: IncomingMessageQueue
CharacterArray
SpatialOrganizer
Gut: Mailbox
String
Map
Wenn du eine Metapher nutzt, benutze Sie durchgehend.
Schlecht: Mailbox, DestinationID Gut: Mailbox, Address
Functions (Methods, Procedures)
Sei prägnant.
Schlecht: list.GetNumberOfItems(); Gut: list.Count();
Aber übertreibe nicht.
Schlecht: list.Verify(); Gut: list.ContainsNull();
Abk. sind nicht zielführend.
Schlecht: list.Srt(); Gut: list.Sort();
Bennene Funktionen die etwas tuen mit Verben.
Schlecht: obj.RefCount();
Gut: list.Clear();
list.Sort();
obj.AddReference();
Bennene Funktionen die ein Boolean zurückgeben als Frage.
Schlecht: list.Empty();
Gut: list.IsEmpty();
list.Contains(item);
Benenne Funktionen die nur eine Eigenschaft zurückgeben und nichts ändern mit Nomen.
Schlecht: list.GetCount(); Gut: list.Count();
Nimm keine Namen die mit einem Übergabewert redundant werden.
Schlecht: list.AddItem(item);
handler.ReceiveMessage(msg);
Gut: list.Add(item);
handler.Receive(msg);
Nimm keinen Namen der mit dem Objekt redundant wird.
Schlecht: list.AddToList(item); Gut: list.Add(item);
Beschreibe den Rückgabe-Typ nur dann im Namen, wenn es identische Funktionen mit unterschliedlichen Rückgabe-Typen gibt. (Wird zurzeit nicht durchgeführt)
Schlecht: list.GetCountInt();
Gut: list.GetCount();
message.GetIntValue();
mmessage.GetFloatValue();
Benutzt kein “And” (und) oder “Or” (oder) in einem Funktions-Namen.
Wenn man eine Konjunktion im Namen hat macht die Funktion vermutlich zu viel. Brich die Funktion runter und benenne sie entsprechend.
Schlecht: mail.VerifyAddressAndSendStatus();
Gut: mail.VerifyAddress();
mail.SendStatus();