Sie haben es wahrscheinlich schon benutzt. Es ist dieser ganz besondere Tag in HTML, der es ermöglicht, dass der Leerraum innerhalb der Tags tatsächlich berücksichtigt wird. Zum Beispiel sind vier Leerzeichen tatsächlich vier Leerzeichen! Das ist anders, als HTML normalerweise funktioniert, wo Leerzeichen „kollabieren“ (die vier Leerzeichen werden zu einem). Der <pre>-Tag ist in der Tat nützlich.
Verwenden Sie den `code`-Tag innen?
Das „pre“ eines <pre>-Tags bedeutet wörtlich „vorformatiertes Text“ – was nichts über die Art des Textes aussagt. Ein <code>-Tag sagt semantisch aus, dass der Text darin Code ist. Das ergibt für mich Sinn! Ich benutze ihn immer, wenn ich Codeblöcke platziere, was meiner Erfahrung nach der wichtigste Anwendungsfall ist.

Beachten Sie, dass sich vor dem Textbeginn im obigen Block ein Zeilenumbruch befindet. Dieser Zeilenumbruch **wird gerendert**, was sehr störend sein kann. Es gibt keine großartige CSS-Möglichkeit, damit umzugehen. Der beste Weg ist, den Text einfach auf derselben Zeile wie den <pre>-Tag zu beginnen oder den führenden Leerraum programmatisch zu entfernen.

Auswahl einer Schriftart
Da der primäre Anwendungsfall des <pre>-Tags Codeblöcke sind und Code im Allgemeinen in einer Monospace-Schriftart geschrieben wird, ist die Festlegung einer Monospace-font-family wahrscheinlich eine gute Idee.
Glücklicherweise legt die „User-Agent-Stylesheet“ (die Stile, die Sie im Browser erhalten, ohne eigene CSS hinzuzufügen) bereits font-family: monospace; fest. Sie könnten also auch gar nichts tun. Oder Sie könnten kreativ werden.
Es gibt einen Artikel aus dem Jahr 2009 von Michael Tuck, der „Font-Stacks“ untersuchte. Das heißt, man listet eine Reihe von Schriftarten in einer einzigen font-family-Deklaration auf, sodass die idealsten Optionen zuerst kommen und dann zu weniger idealen Optionen übergehen. Sein Beispiel-Stack für Monospace-Schriftarten berücksichtigt plattformübergreifend vorinstallierte Schriftarten
font-family: Consolas, "Andale Mono WT", "Andale Mono", "Lucida Console", "Lucida Sans Typewriter", "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Liberation Mono", "Nimbus Mono L", Monaco, "Courier New", Courier, monospace;

Ich bin mir nicht sicher, wie dieser Stack heute auf allen Plattformen noch Bestand hat, aber es sieht nach einem guten Anfang aus.
Alternativ könnten Sie Ihre eigene benutzerdefinierte @font-face-Schriftart laden und verwenden (Font-Stacks gelten weiterhin). Oder Sie nutzen einen Service. Typekit bietet 23 Monospace-Schriftarten, während ich dies schreibe.
Umbrechen oder nicht umbrechen?
Das ist eher eine persönliche Präferenz. Persönlich bin ich gespalten.
Beim Programmieren in meinem Code-Editor bevorzuge ich es, wenn lange Zeilen, die die Breite des sichtbaren Bereichs überschreiten, auf die nächste Zeile umgebrochen werden (anstatt horizontale Scrollbalken zu verursachen). Beim Betrachten von Code in Artikeln bevorzuge ich es, dass der Code nicht umgebrochen wird. Seltsam, ich weiß. Auf CodePen machen wir es zu einer Benutzeroption, da die Welt in dieser Frage so gespalten ist, was sie bevorzugt.

Beim Styling müssen Sie die Entscheidung treffen. Wenn Sie sich für das Umbrechen entscheiden, können Sie glücklicherweise die einzigartige Fähigkeit des <pre>-Tags zur Beibehaltung von Leerraum beibehalten *und* das Umbrechen erhalten, wie hier
pre { white-space: pre-wrap; }
Wenn Sie sich gegen das Umbrechen entscheiden, müssen Sie nichts tun. Außer, Sie sollten bedenken, was bei wirklich langen Zeilen passiert. Wirklich lange Zeilen werden problemlos aus Containern mit fester Breite ausbrechen oder die Breite von Containern unerwartet strecken. Um das zu verhindern, würde ich mindestens vorschlagen
pre { overflow-x: auto; }

Sie könnten sogar eine max-height und einen vollständigen overflow: auto; in Betracht ziehen, wenn Sie abweisend hohe Codeblöcke vermeiden möchten.
Vielleicht automatisch erweitern?
Manche Leute, vielleicht sogar Sie, mögen weder Zeilenumbrüche noch horizontale Scrollbalken. Es mag eine Lösung geben! Sie können Ihre <pre>-Blöcke auf die Standardbreite des Container-Elements belassen, aber ihnen erlauben, sich bei Interaktion zu erweitern.
pre:hover, pre:focus { width: min-content; }

Wird das jemals in eine E-Mail gelangen?
Vielleicht landet der HTML-Code, den Sie schreiben, auf die eine oder andere Weise in einer E-Mail. Pre-Tags können in E-Mails gefährlich sein, da Ihre CSS nicht auf E-Mails angewendet wird (was beim Umbrechen helfen kann), sodass der standardmäßige Nicht-Umbrechttest erfolgt und lange Zeilen E-Mail-Layouts zerstören können.
Auf CSS-Tricks musste ich, als ich den E-Mail-Newsletter automatisch aus dem RSS-Feed generierte, einen speziellen RSS-Feed generieren, der den HTML-Code verarbeitete und sicherstellte, dass Inline-Styles auf alle <pre>-Tags erzwungen wurden, wie hier
<pre style=”white-space: pre-wrap;”></pre>
So tat ich alles, um sicherzustellen, dass Codeblöcke mit langen Zeilen das Layout nicht zerstören würden.
Benötigen Sie Syntax-Hervorhebung?
Es mangelt nicht an Syntax-Hervorhebungsoptionen. Sie können online danach suchen. Persönlich bin ich ein Fan von Prism.js, weil…
- Es hat eine kleine Dateigröße
- Es hat keine Abhängigkeiten
- Es hat sinnvolle Klassennamen
- Es ermöglicht Ihnen, eine Kopie mit nur den benötigten Elementen anzupassen.

Das Einzige, wofür ich Prism.js aufgeben würde, wäre eine clevere Möglichkeit, die <span>s (für die Farbgebung verwendet) serverseitig einzufügen.
Beschriften Sie die Sprache?
Ich persönlich sehe gerne Codeblöcke, die mit der jeweiligen Sprache identifiziert sind.
So wie das

Eine Möglichkeit, dies zu tun, ist die Beschriftung mit einem data-* Attribut (vielleicht einem, das Ihr Syntax-Highlighter bereits erfordert) und dann die Anzeige dieses Attributs, wie hier
pre[data-lang]::before { content: attr(data-lang); display: block; }
Ich glaube nicht, dass das eine besonders zugängliche Methode ist, daher kann vielleicht jemand in den Kommentaren etwas dazu sagen. Vielleicht wäre ein title-Attribut besser?
Steuerung des Abstands
Wenn Sie *tatsächliche* Tabulatorzeichen in den Textblöcken innerhalb von <pre>-Tags verwenden (nicht nur mehrere Leerzeichen, die wie Tabs aussehen), werden Sie vielleicht überrascht sein, wie breit diese Tabulatorzeichen gerendert werden.
Tabs werden standardmäßig als *8 Leerzeichen breit* gerendert, lächerlicherweise.

Es scheint, dass 4 Leerzeichen in Programmierumgebungen üblicher sind. Glücklicherweise können Sie dies nach Belieben steuern.
pre { tab-width: 4; }
Persönlich mag ich sowieso Leerzeichen ;).
Andere Optionen
Es ist keine triviale Aufgabe, Codeblöcke schön auf einer Website darzustellen, aber es ist sehr gut machbar. Wenn Sie die Aufgabe lieber jemand anderem überlassen möchten, bietet CodePen Embedded Pens, die Codeblöcke schön (zusammen mit einer Vorschau) anzeigen können, und eingebettete GitHub Gists sind ebenfalls beliebt.