Hallo Dejan Yu,
das sehe ich aber etwas anders.
Enums und Konstanten verbannen sehr sicher alle "Magic Numbers" aus den Programmen,
und falls sich mal etwas ändern muss kann ich 100% sicher sein das diese Änderungen auch bis
in die hinterste Ecke ankommen (per Kompiler).
Deshalb sind sie für mich unverzichtbar.
Also z.B.:
Code:
function DemoDingOhneEnums(InVar1 : Integer; InVar2 : String): TDateTime;
begin
if InVar2 = 'ufo' then
InVar1 := InVar1 + 1;
case InVar1 of
1011:
Result := DateTime - (TimeZoneInfo.Bias / 60 / 24);
2012:
Result := DateTime - ((TimeZoneInfo.Bias + TimeZoneInfo.DaylightBias) / 60 / 24);
else
Result := 0;
end;
end;
function DemoDingMITEnums(InVar1 : Integer; InVar2 : String): TDateTime;
begin
if InVar2 = CSTR_DEMO1 then
InVar1 := InVar1 + TIME_ZONE_DELTA;
case InVar1 of
TIME_ZONE_ID_STANDARD:
Result := DateTime - (TimeZoneInfo.Bias / MIN_PER_HOUR / HOURS_PER_DAY);
TIME_ZONE_ID_DAYLIGHT:
Result := DateTime - ((TimeZoneInfo.Bias + TimeZoneInfo.DaylightBias) / MIN_PER_HOUR / HOURS_PER_DAY);
else
Result := RES_ERROR;
end;
end;
Die Enums
Zitat:
CSTR_DEMO1
TIME_ZONE_ID_STANDARD:
TIME_ZONE_ID_DAYLIGHT:
MIN_PER_HOUR
HOURS_PER_DAY
RES_ERROR
Machen diese Funktion viel verständlicher und absolut fehlersicher, ich ersetzt mittlerweile fast
alle 0'en und 1'en als Enum oder Konstante (Ok, ok, auch nicht immer).
Aber ich hoffe mein Punkt wird klar:
- Sobald eine Konstante eine spezielle Funktion erfüllt (siehe MIN_PER_HOUR oder RET_ERROR),
macht es für mich sehr viel Sinn dies in Code festzuschreiben.
Änderung wird dadurch ein Kinderpiel auch über zig Module, einfach Enum anpassen und fertig.
Auch bei neu hinzugefügten Enums lassen sich sehr leicht alle möglichen Einflusspositionen suchen.
Von der besseren Lesbarkeit mal ganz zu schweigen.
Und wer dann doch mal an manchen Stellen die Enums als Integrr oder Strings braucht kann
über die
Rtti (siehe Sir Rufo) dies mittlerweile sehr einfach umwandeln.
Rollo