Ich arbeite seit einiger Zeit an einer grundlegenden C ++ - Bibliothek, und es gibt eine Vielzahl von Ideen, die den Prozess des Schreibens und Verwaltens von Code wirklich vereinfachen könnten. Eine davon ist das Konzept der Einführung einiger Makros, die dabei helfen, Aussagen zu vereinfachen, die sehr oft vorkommen, die aber etwas komplizierter sind als nötig.
Zum Beispiel habe ich dieses grundlegende Makro entwickelt, um den gebräuchlichsten Typ von for-Schleife zu vereinfachen:
%Vor%Damit könntest du jene klobigen Schleifen ersetzen, von denen du so viel siehst:
%Vor%Mit etwas viel einfacher zu schreiben und sogar etwas effizienter:
%Vor%Ist es eine gute Idee, Konventionen wie diese zu verwenden? Gibt es Probleme mit verschiedenen Arten von Compilern? Wäre es einfach zu verwirrend für jemanden, der mit den Makros nicht vertraut ist?
IMHO das ist im Allgemeinen eine schlechte Idee. Sie ändern im Wesentlichen die bekannte und verstandene Syntax zu etwas Ihrer eigenen Erfindung. Es dauert nicht lange, bis Sie feststellen, dass Sie die Sprache neu erfunden haben . :)
Nein, keine gute Idee.
%Vor%Es ist jedoch eine gute Idee, häufig verwendeten Code in wiederverwendbare Komponenten umzuwandeln und dann wiederzuverwenden statt zu kopieren. Sie sollten dies tun, indem Sie Funktionen ähnlich den Standardalgorithmen wie std :: find () schreiben. Zum Beispiel:
%Vor%Dies ist ein viel sicherer Ansatz:
%Vor% Ich denke, Sie haben mit Ihrer Beispielverwendung ein starkes Argument gegen dieses Makro geliefert. Sie haben den Schleifeniteratortyp von int in unsigned long geändert. Das hat nichts damit zu tun, wie viel Tipparbeit Sie machen wollen. Warum also ändern?
Diese umständliche Schleife legt den Startwert, den Endwert, den Typ und den Namen des Iterators fest. Selbst wenn wir davon ausgehen, dass der letzte Teil immer ++name ist, und wir sind glücklich, dabei zu bleiben, haben Sie zwei Möglichkeiten - entfernen Sie etwas von der Flexibilität oder tippen Sie jedes Mal alles aus. Sie haben sich entschieden, die Flexibilität zu entfernen, aber Sie scheinen diese Flexibilität auch in Ihrer Codebasis zu verwenden.
Ich würde sagen, es hängt davon ab, ob Sie erwarten, dass jemand anders Ihren Code verstehen muss. Wenn du nur da drin sein wirst, sehe ich kein Problem mit den Makros.
Wenn jemand anders jemals diesen Code sehen muss, dann werden die Makros Probleme verursachen. Die andere Person wird nicht wissen, was sie sind oder was sie tun (egal wie lesbar und offensichtlich sie Ihnen erscheinen) und wird nach ihnen suchen müssen, wenn sie ihnen begegnen. Das Ergebnis wird sein, Ihren Code für jeden außer Ihnen unlesbar zu machen - jeder, der es benutzt, muss im Grunde eine neue Sprache und ein neues Programm gleichzeitig lernen.
Und da die Chancen, dass Sie nur mit dem Code zu tun haben, ziemlich Null sind, wenn Sie hoffen, dass der Code eine Bibliothek ist, die für mehr als nur Ihren persönlichen Gebrauch bestimmt ist, dann würde ich mit don gehen 't .
In Unix finde ich, dass ich zu der Zeit, wenn ich einen Alias für einen Befehl erstellen möchte, die ganze Zeit verwende, der Befehl an meinen Fingern ist, und es mir schwerer fällt, mich an die Syntax meines Alias zu erinnern ursprünglicher Befehl.
Das gleiche gilt hier - wenn Sie ein Idiom so sehr verwenden, dass Sie ein Makro dafür erstellen möchten, liegt das Idiom auf Ihren Fingern und verursacht Ihnen mehr Schmerz als nur den Code zu tippen.
>Das Entfernen der for-Schleifen ist im Allgemeinen eine gute Idee - aber sie nicht durch Makros zu ersetzen. Ich würde mir stattdessen die Standard-Bibliotheksalgorithmen ansehen.
Abgesehen von den Wartungsproblemen, die von anderen erwähnt werden, wird es Ihnen auch schwer fallen, den Makrocode zu durchbrechen und durchzugehen.
Ein Bereich, in dem Makros akzeptabel sein könnten, wäre das Füllen großer Datenstrukturen mit Konstanten / Würfeln (wenn es zu viel Tipparbeit ermöglicht). Normalerweise würden Sie solchen Code nicht einfach durchgehen.
Steve Jessop macht einen guten Punkt. Makros haben ihre Verwendung. Wenn ich seine Aussagen darlege, würde ich so weit gehen und sagen, dass das Argument für oder gegen Makros auf "Es kommt auf" zurückgeht. Wenn Sie Ihre Makros ohne sorgfältige Überlegung erstellen, riskieren Sie, dass zukünftige Wartungen schwieriger werden. Auf der anderen Seite erfordert die Verwendung der wxWidgets-Bibliothek die Verwendung von Bibliothek bereitgestellten Makros, um Ihren Code mit der GUI-Bibliothek zu verbinden. In diesem Fall senken die Makros die Eintrittsbarriere für die Verwendung der Bibliothek, da Magie, deren Innereien irrelevant für das Verständnis sind, wie mit der Bibliothek zu arbeiten ist, vor dem Benutzer verborgen ist. In diesem Fall wird der Benutzer davor bewahrt, Dinge zu verstehen, die er wirklich nicht wissen muss, und kann argumentiert werden, dass dies eine "gute" Verwendung von Makros ist. Außerdem dokumentiert wxWidgets eindeutig, wie diese Makros verwendet werden sollen. Stellen Sie also sicher, dass das, was Sie verbergen, nicht etwas ist, das von jemand anderem verstanden werden muss.
Oder, wenn es nur für Ihren Zweck ist, klopfen Sie sich selbst aus.
Es ist eine Frage, wo Sie Ihren Wert bekommen. Tippst du diese 15 zusätzlichen Zeichen in deine Loops? Was verlangsamt deine Entwicklung? Wahrscheinlich nicht. Wenn Sie mehrere Zeilen verwirrender, unvermeidbarer Textbausteine überall auftauchen, können und sollten Sie nach Möglichkeiten suchen, sich nicht zu wiederholen, wie z. B. nützliche Funktionen erstellen, Klassenhierarchien bereinigen oder Vorlagen verwenden.
Aber es gelten die gleichen Optimierungsregeln für das Schreiben von Code wie für das Ausführen von Code: Das Optimieren kleiner Dinge mit wenig Wirkung ist nicht wirklich eine gute Nutzung von Zeit oder Energie.
Tags und Links macros c++ coding-style project-planning