Ist es sinnvoll, den Code in Blöcke zu unterteilen?

Nun, es ist sicherlich eine gute Methode, den Umfang der Variablen so weit wie möglich einzuschränken. Es ist weniger wahrscheinlich, dass sie unnötigerweise wiederverwendet werden, und Sie definieren sie eher, wenn Sie sie deklarieren, wodurch Fehler aufgrund undefinierter Variablen vermieden werden. Es gibt auch viele Fälle, in denen Sie ein Objekt haben, das etwas tut, während es konstruiert wird und wenn es zerstört wird, und Sie möchten das Gebiet (z. B. die Sanduhr in MFC wird angezeigt, während das Objekt vorhanden ist und verschwindet, wenn es in MFC zerstört wird) (Objekte zum Sperren und Freigeben von Mutexen sind ein weiteres gutes Beispiel), und in solchen Fällen ist es sinnvoll, die Variablen mit Klammern zu definieren. Es gibt also viele Fälle, in denen es sinnvoll ist, Code-Blöcke speziell für Scope-Variablen zu erstellen.

Allerdings gibt es einige Probleme, dies schwer zu tun.

1. Es kann schwierig werden, zu lesen, wenn Sie viele Codeblöcke innerhalb einer Funktion haben.

2. Wenn Sie zu sehr versuchen, Variablen so eng wie möglich zu skalieren, stoßen Sie auf Probleme, wenn Sie Variablen deklarieren müssen, die früher ein größeres Scoping benötigen, als dies sonst möglich wäre, und sie nicht immer beim Deklarieren definieren können.

3. Funktionen drücken oft aus, was Sie viel besser machen möchten.

Daher kann die Verwendung von zusätzlichen Klammern für den Geltungsbereich von Variablen eine gute Übung sein (das Reduzieren des Bereichs von Variablen, so viel wie vernünftigerweise möglich ist), aber in vielen Fällen ist es viel besser, den Code in mehrere Funktionen aufzuteilen. Code kann viel einfacher zu verstehen sein, wenn Sie Funktionen als beliebige Codeblöcke benannt haben. Wenn Sie in einer Position sind, in der Sie sehr viele separate Code-Blöcke innerhalb einer Funktion deklarieren möchten, sollten Sie in mehrere Funktionen aufteilen. Dies gilt insbesondere dann, wenn jeder dieser Blöcke direkt in der Funktion liegt und nicht verschachtelt weiter. Also, Fälle von

wäre wahrscheinlich besser in mehrere Funktionen aufgeteilt als separate Blöcke.

Es gibt sicherlich Zeiten, in denen separate Blöcke gut und nützlich sein können, aber im Allgemeinen separate Funktionen wären besser.

Wenn Ihre Funktion mehrere Dinge tut, die lang genug sind, dass Sie diese Dinge in Blöcke wie diese aufteilen würden, dann sollten Sie die Funktion wahrscheinlich in mehrere kleinere Funktionen aufteilen.

Natürlich gibt es Szenarien, in denen die Einführung eines neuen Scope Blocks nützlich ist. Wenn Sie beispielsweise ein scoped_lock verwenden, um ein Mutex oder ein anderes Synchronisationsobjekt zu sperren, können Sie sicherstellen, dass Sie die Sperre nur so kurz wie nötig halten, indem Sie einen Bereichsblock einfügen.

Implementation Patterns von Kent Beck hat ein sehr gutes Kapitel zu diesem Thema. Das Aufteilen in Blöcke hilft beim Refactoring in separate Funktionen.

Zum Beispiel so etwas

wird

Das erste, was ich tun würde, wenn ich damit konfrontiert werde, ist Refactoring zu erwägen, um die Funktion in kleinere zusammenhängende Funktionen aufzuteilen.

Letztendlich kommt es auf die Lesbarkeit an. Wenn der Code jedoch besser lesbar ist, ist es wahrscheinlich eine gute Idee. Wenn es andererseits Leute verwirrt, die Ihren Code betrachten, dann sollten Sie es wahrscheinlich vermeiden.

Wenn Sie eine Methode haben, die mehrere verwandte Dinge tut, würde ich sagen, dass sie das Prinzip der einfachen Verantwortung bricht. SRP bezieht sich auf Objekte, aber ich möchte das gleiche Denken auf Methoden und Funktionen gleichermaßen anwenden. Es wäre gute Praxis, jedes "Ding", das die Methode macht, in separate Methoden (wahrscheinlich privat oder geschützt) zu kleben und diese in Ihre aktuelle Methode einzubinden. Weitere Informationen finden Sie im Verfahren zum Extrahieren von Methoden .

Alles, was Sie tun können, um Ihren Code lesbarer zu machen, ist eine gute Idee! Kleinere Funktionen, die eine Sache erledigen, sind besser lesbar als lange Funktionen, die viele Dinge tun. Sie sind auch wiederverwendbarer.