Die meisten modernen Sprachen (die irgendwie interpretiert werden) haben eine Art Bewertungsfunktion . Eine solche Funktion führt einen beliebigen Sprachcode aus, der die meiste Zeit als Hauptargument als Zeichenfolge übergeben wurde (verschiedene Sprachen können der eval-Funktion weitere Funktionen hinzufügen).

Ich verstehe Benutzer sollten nicht ausgeführt werden dürfen (diese Funktion bearbeiten nehmen also direkt oder indirekt beliebige Eingabe von einem beliebigen Benutzer zu übergeben eval), vor allem mit serverseitigen Software, da sie den Prozess bösartigen Code auszuführen zwingen könnte. Auf diese Weise empfehlen uns Tutorials und Communities, eval nicht zu verwenden. Es gibt jedoch viele Male, in denen eval nützlich ist und verwendet wird:

• Benutzerdefinierte Zugriffsregeln für Softwareelemente (IIRC OpenERP verfügt über ein Objekt, ir.ruledas dynamischen Python-Code verwenden kann).
• Benutzerdefinierte Berechnungen und / oder Kriterien (OpenERP verfügt über solche Felder, um benutzerdefinierte Codeberechnungen zu ermöglichen).
• OpenERP-Report-Parser (ja, ich weiß, dass ich Sie mit OpenERP-Dingen ausflippen lasse ... aber es ist das Hauptbeispiel, das ich habe).
• Codierung von Zaubereffekten in einigen RPG-Spielen.

So haben sie eine gute Verwendung, solange sie richtig verwendet werden. Der Hauptvorteil besteht darin, dass Administratoren mit dieser Funktion benutzerdefinierten Code schreiben können, ohne weitere Dateien erstellen und einbinden zu müssen (obwohl die meisten Frameworks, die eval-Funktionen verwenden, auch die Möglichkeit haben, eine Datei, ein Modul, ein Paket usw. anzugeben, aus denen gelesen werden kann).

Eval ist jedoch in der Populärkultur böse. Dinge wie das Einbrechen in Ihr System fallen Ihnen ein.

Es gibt jedoch andere Funktionen, die bei einem Zugriff durch Benutzer schädlich sein können: Aufheben der Verknüpfung, Lesen, Schreiben (Dateisemantik), Speicherzuweisung und Zeigerarithmetik, Datenbankmodellzugriff (auch wenn SQL-injizierbare Fälle nicht berücksichtigt werden).

Im Grunde genommen ist der Code die meiste Zeit, in der ein Code nicht richtig geschrieben oder nicht richtig überwacht wird (Ressourcen, Benutzer, Umgebungen, ...), böse und kann sogar zu wirtschaftlichen Auswirkungen führen.

Aber es gibt etwas Besonderes mit evalFunktionen (unabhängig von der Sprache).

Frage : Gibt es eine historische Tatsache für diese Angst, Teil der Populärkultur zu werden, anstatt den anderen möglicherweise gefährlichen Merkmalen die gleiche Aufmerksamkeit zu widmen?

Eine evalFunktion an sich ist nicht böse, und es gibt einen subtilen Punkt, von dem ich nicht glaube, dass Sie ihn machen:

Das Zulassen, dass ein Programm willkürliche Benutzereingaben ausführt, ist schlecht

Ich habe Code geschrieben, der eine evalArt von Funktion verwendete, und er war sicher: Das Programm und die Parameter waren fest codiert. Manchmal gibt es keine Sprach- oder Bibliotheksfunktion, um das zu tun, was das Programm benötigt, und die Ausführung eines Shell-Befehls ist der kurze Weg. "Ich muss das Codieren in ein paar Stunden beenden, aber das Schreiben von Java / .NET / PHP / was auch immer dauert zwei Tage. Oder ich kann evales in fünf Minuten."

Sobald Sie Benutzern erlauben, alle gewünschten Aktionen auszuführen, selbst wenn sie durch Benutzerrechte oder hinter einem "sicheren" Bildschirm gesperrt sind, erstellen Sie Angriffsmethoden. Jede Woche hat ein zufälliges CMS, eine Blog-Software usw. eine Sicherheitslücke, durch die ein Angreifer eine solche Lücke ausnutzen kann. Sie verlassen sich auf den gesamten Software-Stack, um den Zugriff auf eine Funktion zu schützen, die verwendet werden kann, rm -rf /oder auf etwas anderes Katastrophales (Hinweis: Dieser Befehl ist wahrscheinlich nicht erfolgreich, schlägt jedoch fehl, nachdem er ein bisschen Schaden angerichtet hat).

Gibt es eine historische Tatsache dafür, dass diese Angst Teil der Populärkultur wird, anstatt den anderen möglicherweise gefährlichen Merkmalen die gleiche Aufmerksamkeit zu widmen?

Ja, es gibt einen historischen Präzedenzfall. Aufgrund der zahlreichen Fehler, die im Laufe der Jahre in verschiedenen Softwareprogrammen behoben wurden, mit denen Angreifer beliebigen Code ausführen können, ist die Idee von evalmeistens in Ungnade gefallen. Moderne Sprachen und Bibliotheken verfügen über umfangreiche Funktionen, die evalweniger wichtig sind, und dies ist kein Zufall. Beides vereinfacht die Verwendung von Funktionen und verringert das Risiko eines Exploits.

Vielen potenziell unsicheren Funktionen in gängigen Sprachen wurde große Aufmerksamkeit geschenkt. Ob man mehr Aufmerksamkeit erhält, ist in erster Linie eine Ansichtssache, aber die evalFunktionen haben zweifellos ein nachweisbares Sicherheitsproblem, das leicht zu verstehen ist. Zum einen ermöglichen sie die Ausführung von Betriebssystembefehlen, einschließlich Shell-eingebauter und externer Programme, die Standard sind (z . B. rmoder del). In Kombination mit anderen Exploits kann ein Angreifer möglicherweise eine eigene ausführbare Datei oder ein eigenes Shell-Skript hochladen und über Ihre Software ausführen, wodurch fast alles passieren kann (nichts Gutes).

Das ist ein schwieriges Problem. Software ist komplex, und ein Software-Stack (z. B. LAMP ) besteht aus mehreren Softwareteilen, die auf komplexe Weise miteinander interagieren. Seien Sie vorsichtig, wie Sie Sprachfunktionen wie diese verwenden, und gestatten Sie Benutzern niemals, beliebige Befehle auszuführen.

Ein Teil davon ist einfach, dass Nuancen schwer sind. Es ist einfach zu sagen, dass Sie niemals goto, öffentliche Felder, String-Interpolation für SQL-Abfragen oder eval verwenden. Diese Aussagen sollten nicht so verstanden werden, als gäbe es unter keinen Umständen einen Grund, sie zu verwenden. Es ist jedoch eine gute Idee, sie als Faustregel zu vermeiden.

Von Eval wird dringend abgeraten, da es mehrere häufig auftretende Probleme kombiniert.

Erstens ist es anfällig für Injektionsattacken. Hier ist es wie bei der SQL-Injektion, dass beim Einfügen von benutzergesteuerten Daten in den Code leicht aus Versehen das Einfügen von beliebigem Code möglich ist.

Zweitens neigen Anfänger dazu, mit eval schlecht strukturierten Code zu umgehen. Ein Anfänger-Programmierer könnte Code schreiben, der so aussieht:

x0 = "hello"
x1 = "world"
x2 = "how"
x3 = "are"
x4 = "you?"
for index in range(5):
   print eval("x" + index)

Das funktioniert, ist aber wirklich der falsche Weg, um dieses Problem zu lösen. Offensichtlich wäre es viel besser, eine Liste zu verwenden.

Drittens ist eval typischerweise ineffizient. Es wird viel Mühe aufgewendet, um die Implementierung unserer Programmiersprachen zu beschleunigen. Es ist jedoch schwierig, die Bewertung zu beschleunigen, und ihre Verwendung wirkt sich in der Regel nachteilig auf Ihre Leistung aus.

Eval ist also nicht böse. Wir könnten sagen, dass Eval böse ist, weil es ein eingängiger Weg ist, es zu sagen. Jeder Anfänger sollte sich strikt von eval fernhalten, da eval mit ziemlicher Sicherheit die falsche Lösung ist. Für bestimmte fortgeschrittene Anwendungsfälle ist eval sinnvoll, und Sie sollten es verwenden, aber natürlich auf die Fallstricke achten.

Es läuft darauf hinaus, dass "willkürliche Codeausführung" ein Fachgespräch für "alles können" ist. Wenn jemand in der Lage ist, die Ausführung von willkürlichem Code in Ihrem Code auszunutzen, ist dies im wahrsten Sinne des Wortes die schlimmste Sicherheitslücke, die möglich ist, da er in der Lage ist, alles zu tun, was Ihr System tun kann.

"Andere möglicherweise schädliche Bugs" können durchaus Grenzen haben, was bedeutet, dass sie per Definition weniger Schaden anrichten können als eine willkürliche Codeausführung, die ausgenutzt wird.

Es gibt einen praktischen und einen theoretischen Grund.

Der praktische Grund ist, dass wir beobachten, dass es häufig Probleme verursacht. Es kommt selten vor, dass die Auswertung zu einer guten Lösung führt, und es kommt häufig zu einer schlechten Lösung, bei der Sie am Ende eine bessere erhalten hätten, wenn Sie vorgetragen hätten, dass die Auswertung nicht existiert und das Problem anders angegangen wären. Der vereinfachte Rat ist es also, ihn zu ignorieren. Wenn Sie einen Fall finden, in dem Sie den vereinfachten Rat ignorieren möchten, hoffen wir, dass Sie ihn ausreichend durchdacht haben, um zu verstehen, warum der vereinfachte Rat nicht anwendbar ist und der allgemeine Fallstricke werden Sie nicht betreffen.

Der theoretischere Grund ist, dass es noch schwieriger ist, Code zu schreiben , der guten Code schreibt , wenn es schwierig ist, guten Code zu schreiben . Unabhängig davon, ob Sie eval verwenden oder SQL-Anweisungen generieren, indem Sie Zeichenfolgen zusammenfügen oder einen JIT-Compiler schreiben, ist das, was Sie versuchen, oft schwieriger als erwartet. Das Potenzial für die Einschleusung von Schadcode ist ein großer Teil des Problems, aber abgesehen davon ist es im Allgemeinen schwieriger, die Richtigkeit Ihres Codes zu ermitteln, wenn Ihr Code erst zur Laufzeit vorhanden ist. Der vereinfachte Rat ist es also, die Dinge für sich zu vereinfachen: "Verwenden Sie parametrisierte SQL-Abfragen", "Verwenden Sie keine eval".

Ein Beispiel für Zaubereffekte: Es ist eine Sache, einen Lua-Compiler (oder was auch immer) oder -Interpreter in Ihr Spiel zu integrieren, damit Spieleentwickler die Zaubereffekte in einer einfacheren Sprache als C ++ (oder was auch immer) beschreiben können. Die meisten "Probleme der Auswertung" treffen nicht zu, wenn Sie nur Code auswerten, der geschrieben und getestet wurde und in das Spiel oder in DLC oder What-Have-You aufgenommen wurde. Das ist nur das Mischen von Sprachen. Die großen Probleme treffen Sie, wenn Sie versuchen, Lua (oder C ++ oder SQL oder Shell-Befehle oder was auch immer) im laufenden Betrieb zu generieren und es durcheinander zu bringen.

Nein, es gibt keine offensichtliche historische Tatsache.

Die Übel der Eval sind von Anfang an klar zu sehen. Andere Funktionen sind leicht gefährlich. Menschen können Daten löschen. Die Leute können Daten sehen, die sie nicht sehen sollten. Menschen können Daten schreiben, die sie nicht sollten. Und sie können die meisten dieser Dinge nur tun, wenn Sie es irgendwie vermasseln und Benutzereingaben nicht validieren.

Mit eval können sie das Pentagon hacken und es so aussehen lassen, als hätten Sie es getan. Sie können Ihre Tastatureingaben überprüfen, um Ihre Passwörter zu erhalten. Vorausgesetzt, eine vollständige Sprache von Turing kann buchstäblich alles tun, wozu Ihr Computer in der Lage ist.

Und Sie können die Eingabe nicht validieren. Es ist ein beliebiger Freiform-String. Die einzige Möglichkeit zur Validierung besteht darin, einen Parser und eine Codeanalyse-Engine für die betreffende Sprache zu erstellen. Viel Glück damit.

Ich denke, es läuft auf die folgenden Aspekte hinaus:

• Notwendigkeit
• (Bewachter) Gebrauch
• Zugriff
• Überprüfbarkeit
• Mehrstufige Angriffe

Notwendigkeit

Hallo zusammen, ich habe dieses extrem coole Bildbearbeitungsprogramm geschrieben (erhältlich für $ 0.02). Nachdem Sie das Bild geöffnet haben, können Sie eine Vielzahl von Filtern auf Ihr Bild anwenden. Sie können einige sogar selbst mit Python (dem Programm, in dem ich die Anwendung geschrieben habe) schreiben. Ich werde nur evalauf Ihre Eingabe verwenden, in dem Vertrauen, dass Sie ein seriöser Benutzer sind.

(später)

Vielen Dank für den Kauf. Wie Sie sehen, funktioniert es genau so, wie ich es versprochen habe. Oh, du willst ein Bild öffnen? Nein, kannst du nicht. Ich werde die readMethode nicht verwenden , da sie etwas unsicher ist. Sparen? Nein, ich werde nicht verwenden write.

Ich versuche zu sagen: Sie benötigen Lese- / Schreibzugriff für fast alle grundlegenden Tools. Gleiches gilt für die Speicherung der Highscores Ihres ach so tollen Spiels.

Ohne Lesen / Schreiben ist Ihr Bildeditor unbrauchbar. Ohne eval? Ich schreibe dir ein benutzerdefiniertes Plugin dafür!

(Bewachter) Gebrauch

Viele Methoden können möglicherweise gefährlich sein. Wie zum Beispiel das readund write. Ein häufiges Beispiel ist ein Webdienst, mit dem Sie Bilder aus einem bestimmten Verzeichnis lesen können, indem Sie den Namen angeben. Der Name kann jedoch ein beliebiger gültiger (relativer) Pfad auf dem System sein, sodass Sie alle Dateien lesen können, auf die der Webdienst Zugriff hat, nicht nur die Bilder. Der Missbrauch dieses einfachen Beispiels wird als "Pfadüberquerung" bezeichnet. Wenn Ihre App die Pfadüberquerung zulässt, ist dies schlecht. Ein, readohne sich dagegen zu verteidigen, kann durchaus als böse bezeichnet werden.

In anderen Fällen steht der String für readjedoch vollständig unter der Kontrolle des Programmierers (möglicherweise fest codiert?). In diesem Fall ist es kaum böse zu gebrauchen read.

Zugriff

Nun ein weiteres einfaches Beispiel mit eval.

Irgendwo in Ihrer Web-App möchten Sie dynamische Inhalte. Sie gestatten den Administratoren die Eingabe von ausführbarem Code. Da die Administratoren vertrauenswürdige Benutzer sind, kann dies theoretisch in Ordnung sein. Stellen Sie einfach sicher, dass Sie keinen Code ausführen, der von Nicht-Administratoren gesendet wurde.

(Das heißt, bis Sie diesen netten Administrator gefeuert haben, aber vergessen haben, seinen Zugriff zu widerrufen. Jetzt wird Ihre Web-App verworfen).

Überprüfbarkeit.

Ein weiterer wichtiger Aspekt ist meiner Meinung nach, wie einfach es ist, Benutzereingaben zu überprüfen.

Benutzereingaben in einem Leseaufruf verwenden? Stellen Sie einfach (sehr) sicher, dass die Eingabe für den Leseaufruf nichts Bösartiges enthält. Normalisieren Sie den Pfad und vergewissern Sie sich, dass sich die geöffnete Datei in Ihrem Medienverzeichnis befindet. Das ist jetzt sicher.

Benutzereingaben bei einem Schreibanruf? Gleich!

SQL-Injektion? Entkomme einfach oder verwende parametrisierte Abfragen und du bist sicher.

Eval? Wie verifizierst du die Eingabe, die für den evalAnruf verwendet wird? Sie können sehr hart arbeiten, aber es ist wirklich sehr schwer (wenn nicht unmöglich), dafür zu sorgen, dass es sicher funktioniert.

Mehrstufige Angriffe

Jetzt müssen Sie jedes Mal, wenn Sie Benutzereingaben verwenden, die Vorteile der Verwendung gegen die Gefahren abwägen. Schützen Sie die Nutzung so weit wie möglich.

Betrachte noch einmal das evalfähige Zeug im Admin-Beispiel. Ich habe dir doch gesagt, dass das in Ordnung ist.

Bedenken Sie nun, dass es in Ihrer Web-App tatsächlich eine Stelle gibt, an der Sie vergessen haben, Benutzerinhalte (HTML, XSS) zu umgehen. Das ist eine geringere Straftat als eine vom Benutzer zugängliche Bewertung. Unter Verwendung des nicht entkoppelten Benutzerinhalts kann ein Benutzer jedoch den Webbrowser eines Administrators übernehmen und über die Administratorsitzung einen möglichen evalBlob hinzufügen , wodurch wiederum der vollständige Systemzugriff ermöglicht wird.

(Dieselbe mehrstufige Attacke kann mit SQL-Injection anstelle von XSS durchgeführt werden, oder es werden beliebige Datei-Schreibvorgänge ausgeführt, die den ausführbaren Code ersetzen, anstatt zu verwenden. eval)

Damit diese Funktion überhaupt funktioniert, muss eine Reflektionsebene vorhanden sein, die den vollständigen Zugriff auf den internen Status des gesamten Programms ermöglicht.

Für interpretierte Sprachen kann ich einfach den Interpreter-Status verwenden, der einfach ist, aber in Kombination mit JIT-Compilern die Komplexität noch erheblich erhöht.

Ohne evalkann der JIT-Compiler häufig nachweisen, dass auf die lokalen Daten eines Threads nicht von einem anderen Code aus zugegriffen wird. Daher ist es durchaus akzeptabel, Zugriffe neu zu ordnen, Sperren auszulassen und häufig verwendete Daten für längere Zeit zwischenzuspeichern. Wenn ein anderer Thread eine evalAnweisung ausführt , muss möglicherweise der laufende JIT-kompilierte Code damit synchronisiert werden. Daher benötigt der JIT-generierte Code plötzlich einen Fallback-Mechanismus, der innerhalb eines vernünftigen Zeitraums zur nicht optimierten Ausführung zurückkehrt.

Diese Art von Code weist in der Regel viele subtile, schwer zu reproduzierende Fehler auf und schränkt gleichzeitig die Optimierung im JIT-Compiler ein.

Für kompilierte Sprachen ist der Kompromiss sogar noch schlimmer: Die meisten Optimierungen sind verboten, und ich muss umfangreiche Symbolinformationen und einen Interpreter bereithalten, sodass sich die zusätzliche Flexibilität im Allgemeinen nicht lohnt - es ist oft einfacher, eine Schnittstelle zu einigen internen zu definieren Strukturen, zB durch eine Skript geben Ansicht und Controller gleichzeitigen Zugriff auf das Programm des Modells .

Ich lehne die Prämisse ab, evaldie als böser als Zeigerarithmetik oder gefährlicher als direkter Speicher- und Dateisystemzugriff angesehen wird. Ich kenne keinen vernünftigen Entwickler, der das glauben würde. Darüber hinaus werden Sprachen, die Zeigerarithmetik / direkten Speicherzugriff unterstützen, normalerweise nicht unterstützt evalund umgekehrt. Ich bin mir also sicher, wie oft ein solcher Vergleich überhaupt relevant wäre.

Dies evalkönnte jedoch eine bekanntere Sicherheitsanfälligkeit sein, da sie von JavaScript unterstützt wird. JavaScript ist eine Sandbox-Sprache ohne direkten Speicher- oder Dateisystemzugriff, sodass diese Sicherheitsanfälligkeiten nur Schwachstellen in der Sprachimplementierung selbst ausschließen. Evalist daher eines der gefährlichsten Merkmale der Sprache, da es die Möglichkeit der Ausführung von willkürlichem Code eröffnet. Ich glaube, dass viel mehr Entwickler in JavaScript als in C / C ++ evalentwickeln. Daher ist es für die Mehrheit der Entwickler einfach wichtiger, sich dessen bewusst zu sein, als dass Pufferüberläufe auftreten.

Kein seriöser Programmierer würde Eval als "böse" bezeichnen. Es ist einfach ein Programmierwerkzeug wie jedes andere. Die Angst vor dieser Funktion hat nichts mit der Populärkultur zu tun. Es ist einfach ein gefährlicher Befehl, der häufig missbraucht wird und schwerwiegende Sicherheitslücken einführt und die Leistung beeinträchtigt. Aus eigener Erfahrung würde ich sagen, dass es selten ein Programmierproblem gibt, das auf andere Weise nicht sicherer und effizienter gelöst werden kann. Die Programmierer, die am wahrscheinlichsten eval verwenden, sind diejenigen, die wahrscheinlich am wenigsten dafür qualifiziert sind, dies sicher zu tun.

Allerdings gibt es Sprachen, in denen die Verwendung von eval angebracht ist. Perl fällt mir ein. Ich persönlich finde jedoch, dass es in anderen, moderneren Sprachen, die die strukturierte Ausnahmebehandlung von Haus aus unterstützen, nur sehr selten benötigt wird.

Ich denke, dass Sie im folgenden Teil Ihrer Frage (Hervorhebung meiner) recht gut darauf eingehen:

Sie haben eine gute Verwendung, solange sie richtig verwendet werden

Für die 95%, die es richtig benutzen, ist alles gut und schön; aber es wird immer Leute geben, die es nicht richtig benutzen. Einige davon werden auf Unerfahrenheit und mangelnde Fähigkeiten zurückzuführen sein, der Rest wird böswillig sein.

Es wird immer Leute geben, die Grenzen überschreiten und Sicherheitslücken finden wollen - manche für gut, manche für schlecht.

Was das historische Faktum betrifft, so evalermöglichen Typfunktionen im Wesentlichen die Ausführung von beliebigem Code, der zuvor in populären Web-CMS, Joomla! . Mit Joomla! Wenn mehr als 2,5 Millionen Websites weltweit mit Strom versorgt werden , kann dies nicht nur den Besuchern dieser Websites, sondern auch der Infrastruktur, auf der sie gehostet werden, und der Reputation der Websites / Unternehmen, die ausgenutzt wurden, großen Schaden zufügen.

Der Joomla! Ein Beispiel mag einfach sein, aber es wurde aufgezeichnet.

Es gibt einige gute Gründe, von der Verwendung abzuraten eval(obwohl einige für bestimmte Sprachen spezifisch sind).

• Die von verwendete Umgebung (lexikalisch und dynamisch) evalist häufig überraschend (das heißt, Sie denken, sie eval(something here)sollte eine Sache tun, aber sie tut eine andere, was möglicherweise Ausnahmen auslöst).
• Es gibt häufig einen besseren Weg, um das Gleiche zu erreichen (die Verkettung konstruierter lexikalischer Abschlüsse ist manchmal eine bessere Lösung, aber das kann durchaus Common-Lisp-spezifisch sein).
• Es ist viel zu einfach, unsichere Daten auszuwerten (obwohl dies meistens verhindert werden kann).

Ich persönlich würde nicht so weit gehen zu sagen, dass es böse ist, aber ich werde immer die Verwendung von evalCode in Frage stellen , mit Formulierungen wie "Haben Sie hier einen Code in Betracht gezogen ?" (wenn ich Zeit habe, mindestens einen vorläufigen Ersatz zu machen), oder "sind Sie sicher, dass eine Bewertung hier wirklich die beste Lösung ist?" (wenn ich nicht).

In Minskys Society of Mind , Kapitel 6.4, sagt er

Es gibt eine Möglichkeit, wie ein Geist sich selbst beobachten und trotzdem verfolgen kann, was passiert. Teilen Sie das Gehirn in zwei Teile, A und B. Verbinden Sie die Ein- und Ausgänge des A-Gehirns mit der realen Welt - so kann es spüren, was dort passiert. Aber verbinde das B-Gehirn überhaupt nicht mit der Außenwelt; Schließen Sie es stattdessen so an, dass das A-Gehirn die Welt des B-Gehirns ist!

Wenn ein Programm (B) ein anderes Programm (A) schreibt, funktioniert es als Metaprogramm. Gegenstand von B ist Programm A.

Es gibt ein C-Programm. Das ist derjenige in deinem Kopf, der Programm B schreibt.

Die Gefahr ist, dass es jemanden (C ') mit böser Absicht geben kann, der in diesen Prozess eingreifen kann, so dass Sie Dinge wie SQL-Injection erhalten.

Die Herausforderung besteht darin, Software intelligenter zu machen, ohne sie auch gefährlicher zu machen.

Sie haben hier viele gute Antworten und der Hauptgrund ist eindeutig, dass die Ausführung von willkürlichem Code schlecht ist. Ich möchte jedoch einen weiteren Faktor hinzufügen, den andere nur am Rande von:

Es ist wirklich schwierig, Probleme mit Code zu beheben, der aus einer Textzeichenfolge ausgewertet wird. Ihre normalen Debugging-Tools sind so gut wie direkt aus dem Fenster und Sie sind auf die Nachverfolgung oder das Echo der alten Schule reduziert. Offensichtlich ist das nicht so wichtig, wenn Sie ein Fragment in einem Einzeiler haben, das Sie möchten, evalaber als erfahrener Programmierer können Sie wahrscheinlich eine bessere Lösung dafür finden, wohingegen die Codegenerierung in größerem Maßstab irgendwo anders sein kann als eine Evaluierungsfunktion wird zu einem potenziell nützlichen Verbündeten.