return value: best practice?
wergor 07.01.2017 - 23:12 2768 7
wergor
connoisseur de mimi
|
ich habe auf der einen seite funktionen deren return value im normalfall 0 und im fehlerfall != 0 ist, und auf der anderen seite funktionen deren return value im normalfall true und im fehlerfall false ist. z.b: /*starts the focuser's homing prcedure.
@return: bits are set on errors:
//MSB - - - - - - LSB
// x x x x x x x x
// | | | | | | | |
// | | | | | | | - invalid home position value - < 0.
// | | | | | | - invalid home position value - > max step.
// | | | | | - not used.
// | | | | - not used.
// | | | - not used.
// | | - homing already in progress.
// | - not used.
// - no home switch specified.*/
uint8_t findHome();
/*
@param sensor: temperature sensor to use for temperature compensation.
@return: true if a valid sensor number was given, false otherwise.*/
bool setTempCompSensor(uint8_t sensor);
der code läuft auf einem arduino und die return- werte werden über die serielle schnittstelle an den PC gesendet, true / false wird als 1 / 0 gesendet. mir erscheint es seltsam, dass in einem fall 0 = "OK" und != 0 = fehler, aber im anderen fall 0 = fehler, 1 = "OK" bedeutet. gibts eine "best practice" für so einen fall?
|
Blaues U-boot
blupp, blupp
|
ich bin kein programmierer, aber afaik wird je nach datentyp null, 0, false und/oder kein wert/keine kommunikation als fehler definiert. dann müsste alles konsistent zusammenpassen. in der sicherheitstechnik ist false ein fehler (somit sind die schalter öffner), da man damit auch gleich nen kabelbruch mitnimmt.
|
mat
AdministratorLegends never die
|
In deinem Beispiel hast du bei der ersten Funktion ein Bit-Flag für eine Kombination aus Fehlern. Das geht nicht anders, die Funktion gibt beim Fehlerfall immer true zurück, weil ja mindestens ein Bit gesetzt ist. Ist kein Bit gesetzt, also kein Fehler gefunden worden, dann ist die Zahl 0.
Übersichtlicher Code ist durch gute Benennung von Datentypen, Variablen und Macros meiner Meinung nach immer möglich, auch wenn technische Details wie diese es manchmal schwer machen.
Ist das C/C++?
|
wergor
connoisseur de mimi
|
ist C++. das bitflag wird als zahl an den PC gesendet und dort wieder bitweise untersucht. im fehlerfall z.b. return wert 34, und der treiber kann dann am bitflag- muster auslesen welche fehler aufgetreten sind.
|
mat
AdministratorLegends never die
|
Das ist dann schon korrekt so. Man könnte die Fehler mit einem struct und Bitfield-Einteilungen schöner aufteilen bzw. kann man dann auch am struct selbst sehen, dass es sich um ein Bitflag handelt: typedef struct Bitfield
{
bool error1:1;
bool error2:1;
bool error3:1;
bool error4:1;
bool error5:1;
bool error6:1;
bool error7:1;
bool error8:1;
} BITFIELD;
// Wenn die Funktion von einer Library ist und nicht von dir, dann musst du selbst casten:
uint8_t nRet = homeFind();
BITFIELD bfRet = *(BITFIELD *)&nRet;
Zusätzlich dann noch ein paar passende Macros wie zB: #define BITFLAG_SUCCESS(ret) ((ret) == 0)
#define BITFLAG_OK 0
if (BITFLAG_SUCCESS(homeFind()))
{
...
}
if (homeFind() == BITFLAG_OK)
{
...
}
Für Boolean-Return-Werte brauchst du keine Macros machen, die sind eh klar. Macros würde ich nur bei numerischen Return-Werten mit Bedeutung definieren.
|
Vinci
hatin' on summer
|
|
wergor
connoisseur de mimi
|
danke für den bitfield tipp, das werde ich im auge behalten. aktuell brauche ich es nicht, weil die return- werte vom arduino selbst nicht ausgewertet, sondern nur an den PC geschickt werden. @vinci ich verstehe gerade nicht was du meinst, sry.
|
Vinci
hatin' on summer
|
errno ist Teil des C Standards und enthält Integer Fehlercodes. Die gängige Praxis innerhalb des Standards (und beispielsweise bei Kernel Modulen, die mit embedded am ehesten vergleichbar sind) ist somit
== 0 für alles gut != 0 für Fehler
|