4. Probleme mit Bezeichnern

Probleme mit Bezeichnern

  • R

    ich habe Probleme bei der Namensfindung meiner verwendeten Bezeichner. Ich habe zB flg. Klasse:

    #pragma hdrstop

#include <tchar.h>
#include <conio.h>
#include <iostream>
using namespace std;
//---------------------------------------------------------------------------

#pragma argsused

class Messdaten
{
	private:
		float mTemperatur;
		float GetTemperatur(void) {return mTemperatur;}
		void SetTemperatur(float Wert) {mTemperatur = Wert;}
	public:
		Messdaten();
		__property float Temperatur = {read=GetTemperatur, write=SetTemperatur};
};

Messdaten::Messdaten() : mTemperatur(0.0) {}

int _tmain(int argc, _TCHAR* argv[])
{
	Messdaten T1;
	cout << T1.Temperatur << endl;

	getch();
	return 0;
}

    Irgendwie finde ich es so nicht so toll. Ich will ja auch nicht alles Temperatur nennen oder Messwert. Auch die Bezeichnung des Objekts (hier T1 finde ich nicht so passend) Gibts da vielleicht einen Standardoder einen Vorschlag eurerseits? Einen Vektor erzeuge ich dann auch noch der alle Temperaturen aufnimmt. Dort muss ich ja auch wieder einen Namen finden.

    Bei den Komponenten hab ich das Problem gelöst indem ich als Name immer ein kleingeschriebenes Kürzel aus 3 Buchstaben dem Namen vorstelle also zB lab, btn, txt, frm (Label, Button, Edit, Form).

    0
  • ?

    Hallo,

    das kannst du bei Variablen, Methoden, Funktionen oder properties genauso fortsetzen! Der Namensgebung sind doch kaum Grenzen gesetzt.

    LG

    0
  • ?

    Wobei das mit dem T1 wirklich etwas unglücklich ist. Ich mache bei solchen Klassen ein c davor, also cMessdaten und die Instanzierung dann mit cMessdaten Messdaten. Dann hat man ein schönen Aussagekräftigen Objektnamen. An lange Bezeichner gewöhnt man sich. Meiner Meinung nach erhöht es die Lesbarkeit des Codes. Nur bei lokal gültigen Variablennamen wähle ich kurze Bezeichner, da man nur ein paar Zeilen hochscrollen muss, um zu erkennen, um welche Klasse es sich handelt. Bei allem was Formular- oder Unit-weit deklariert ist, verwende ich lange Bezeichner.

    Aber ich glaub, jeder muss da selbst seinen Weg finden. Das ergibt sich einfach im Laufe der Zeit.

    0
  • A

    Joe_M. schrieb:

    Aber ich glaub, jeder muss da selbst seinen Weg finden.

    Bei C++ ist das leider meistens so. In Delphi gibt es die folgenden Namenskonventionen:

    - Alle Bezeichner sind in englischer Sprache
    - benutzerdefinierte Typen beginnen mit 'T' (TComponent, TForm, TPoint)
    - Felder beginnen mit 'F', Setter- und Gettermethoden mit 'Set' und 'Get' (bzw. 'Is' für Getter-Methoden von Boolean-Eigenschaften)
    - Bezeichner sind immer in CamelCase
    - Konstanten beginnen mit 'C' (CMaxValue), String-Konstanten und Resourcestrings mit 'S' (SMyErrorMessage)
    - Exceptions beginnen mit 'E' (EAbstractError, EProgrammerNotFound)
    - Methodennamen sind immer Verben (DoSomething(), FetchData(), ShutUp()), Typnamen sind immer Substantive (TObject, TCustomForm)
    - Funktionsargumente können bei Bedarf mit 'A' präfiziert werden, etwa wenn ein gleichnamiges Property existiert, oder wenn die Konsistenz es erfordert

    Angenehmerweise halten sich in Delphi fast alle daran, was Delphi-Code ein recht konsistentes Erscheinungsbild gibt. In reinem C++-Code bevorzuge ich andere Konventionen, aber wenn ich C++Builder und Typen aus Delphi-RTL und VCL benutze, halte ich mich auch in C++Builder an die Delphi-Namenskonventionen, und diese Vorgehensweise empfehle ich nachdrücklich. Jeder C++Builder-Programmierer kennt diese Konventionen aus der VCL, und er wird keine Schwierigkeiten haben, deine Namensgebung zu verstehen.

    Damit sähe dein Code so aus:

    class TPerformanceData
{
private:
    float FTemperature;
    float GetTemperature (void) { return FTemperature; }
    void SetTemperature (float Value) { FTemperature = Value; }
public:
    TPerformanceData (void);

    __property Temperature = { read = GetTemperature, write = SetTemperature };
};

TPerformanceData::TPerformanceData (void)
 : FTemperature (0.0)
{}

int _tmain (int argc, _TCHAR* argv[])
{
    TPerformanceData performanceData;
    cout << performanceData.Temperature << endl;

    getch();
    return 0;
}

    Unabhängig davon gelten natürlich meine andernorts bereits ausgesprochenen Hinweise, daß der Einsatz von Getter- und Settermethoden unnötig redundant, darüber hinaus die Verwendung von Properties in deinem Fall nicht sinnvoll ist und die Klasse einfach so aussehen könnte und sollte:

    struct TPerformanceData
{
    float Temperature;

    TPerformanceData (void)
     : Temperature (0.0)
    {}
};
    0
Anmelden zum Antworten