Ist es eine schlechte Idee, Entwicklungskürzel in #if DEBUG Blöcke zu setzen?

An einigen Stellen in unserem Code verwenden wir #if DEBUG-Blöcke, um die Entwicklung zu vereinfachen. Dinge wie:Ist es eine schlechte Idee, Entwicklungskürzel in #if DEBUG Blöcke zu setzen?

#if DEBUG 
    serverIP = localhost; 
#else 
    serverIP = GetSetting() 
#endif

oder

private bool isLicensed() 

#if DEBUG 
    return true; 
#endif 

return CheckSetting()

Darüber hinaus gibt es ein paar Orte, wo wir kosmetische Veränderungen wie diese machen:

#if DEBUG 
    background = humorousImage.jpg 
#else 
    background = standardColor 
#endif

Ist es gefährlich auf #if Debug abhängig zu machen Entwicklung einfacher? Wenn ja, was ist eine gültige Verwendung von #if debug?

Quelle

2010-07-14 Bobwise

Es ist eine wirklich schlechte Idee. Wenn Sie versuchen, einen Produktionsfehler zu bekommen, werden Ihre Debug-Klauseln Sie auf jeden Fall stolpern. Sie möchten so nah wie möglich am Code sein, der in der Produktion läuft. In Ihrem Beispiel werden Sie nie einen Fehler in CheckSetting() finden

Durch die Blicke der Dinge ist Ihr Code zu eng gekoppelt. Was Sie tun möchten, ist, Module/Klassen weniger abhängig voneinander zu machen und Test Driven Development zu üben. Siehe auch Inversion of Control (auch Dependency Injection genannt).

Working Effectively with Legacy Code hat einige nützliche Einblicke in die Einführung von TDD.Es gibt auch einige sehr gute Hinweise, wie TDD in verschiedenen Szenarien zu tun ist, in denen es schwierig ist, Dinge zu testen.

Quelle

2010-07-14 20:44:45 leonm

Idealerweise würden Sie diese Einstellungen in Konfigurationsdateien verschieben und die #IF Debug-Direktiven für Tests, Protokollierung und zusätzliche "Debugging" -Tasks beibehalten. Denken Sie auch daran, dass Code für Kunden, den Sie jemals für einen Debug-Build benötigen, sich jetzt völlig anders verhält. Meine zwei Cent.

Quelle

2010-07-14 20:36:33 Flesrouy

Natürlich könnte ein "Debug" -Build so einfach sein wie Debugger Ausgabe in Release-Version zu emittieren. Ich denke, der Hauptgrund dafür ist, dass der Release-Build Fehler enthalten kann, die im Debug-Build nicht vorhanden sind. –

Ich kann nicht sagen, dass ich persönlich daran interessiert bin. Ich arbeite in einer Umgebung, in der unsere Hauptanwendung (für mehr als 400 Benutzer) mehr als 60 Module umfasst und 5 Entwickler an den Projekten arbeiten Und wenn Sie Module freigeben, wissen Sie, dass früher oder später jemand versehentlich ein Debug-Modul freigibt. :)

Quelle

2010-07-14 20:38:41

Einverstanden! Es spielt keine Rolle, wie vorsichtig Sie sind - schließlich könnte es das Licht der Welt erblicken, also lohnt es sich nicht, es zu riskieren. – RQDQ

Klingt so, als ob Sie einen automatisierten Build benötigen, also veröffentlichen Sie keine Dateien, die auf der Workstation eines einzelnen Devs erstellt wurden. –

Sehr wahr - es ist seit einer Weile auf den Karten, Joe! –

Das Problem dabei ist, dass es viel weniger wahrscheinlich ist, Fehler in der #else zu finden.

Im Allgemeinen sollten Ihre Debug-Builds Ihren Releasebuilds so ähnlich wie möglich sein.

Quelle

2010-07-14 20:39:06 SLaks

Die erste gültige Verwendung ich für einen bedingten #if Block hatte:

Wir haben ein neues Lizenz/Aktivierungssystem. Wir benötigen es für lokales Debuggen deaktiviert, aber möchten nicht eine Konfigurationseinstellung verwenden, um es zu deaktivieren - dann könnte der Benutzer das System umgehen, indem er die Konfigurationsdatei ändert!

So verwenden wir eine bedingte Kompilierung Block:

#if !DISABLE_ACTIVATION 
// activation code here 
#endif

Hoffnung, dass das Bild ein bisschen mehr hilft malen ..!

Quelle

2010-07-14 20:39:43

Sie sollten versuchen, die Live-Umgebung und die Entwicklungsumgebung so ähnlich wie möglich zu halten. Vermeiden Sie daher zwei Versionen des Codes.

Eine gültige Verwendung des #if DEBUG Konstrukts zusätzliche Kontrollen im Code zu setzen, was benötigt wird, nicht im Endprodukt:

#if DEBUG 
    if (somehting that normally can't happen) throw new SomeException(); 
#endif

Quelle

2010-07-14 20:40:45 Guffa

Obwohl das mit Debug.Assert() einfacher gemacht werden könnte. –

@Joe: Ja, für dieses einfache Beispiel, aber Sie möchten vielleicht etwas überprüfen, das komplexeren Code erfordert. – Guffa

Mein aktueller Stil ist eine Datei namens aadebug.h, die eine Reihe von bedingten Defines enthält, denen jeweils // vorangestellt werden kann, um sie zu deaktivieren. Die Datei beginnt:

 
//#define DX_DEBUG 
#ifdef DX_DEBUG 
#define DX_SKIP_LOGIN 
// #define DX_ALLOW_BULK_USER_CREATE 
#define DX_CREATE_EXCESS_LOGS 
// #define DX_RANDOM_PROBE_FAILURES 
#define SHORT_KEY_TIMEOUT 
// #define DX_OMIT_NET_VIEWER 
... 
#endif

Wenn DEBUG aktiviert ist, wird die Hauptbildschirmanzeige Code anzeigen „NICHT für den produktiven Einsatz“. Alle Debug-Optionen können deaktiviert werden, indem Sie DX_DEBUG deaktivieren, aber die meisten Optionen werden in der Regel mit individuellen Flags gesteuert. Wenn ich der Meinung bin, dass eine Option ihre Nützlichkeit überlebt hat, entferne ich ihre # ifdefs aus der Quelle und entferne dann die auskommentierte #define aus aadebug.h, aber ansonsten verwende ich die auskommentierten # define's, um zu verfolgen, welche # ifdef-Flags sind noch vorhanden.

Quelle

2010-07-14 21:15:53 supercat

Ist es eine schlechte Idee, Entwicklungskürzel in #if DEBUG Blöcke zu setzen?

Antwort

Verwandte Themen