gnome-devel-docs master - en to de translation catalogue (513 entries)

note: (itstool) path: info/desc
en: Other style guides and books about organizing free software projects
de: Andere Richtlinien und Bücher über die Organisation von Projekten der Freien Software

note: (itstool) path: page/title
en: Additional Materials
de: Zusätzliche Materialien

note: (itstool) path: page/p
en: Here we give you links to other materials that you may want to read. These will teach you a lot about how to work on large distributed teams of free software developers, and about good programming style in general.
de: Hier sind einige Links zu anderen Materialien, die Sie vielleicht lesen wollen. Sie vermitteln Ihnen einen Einblick in die Arbeitsweise weit verstreuter Teams von Entwicklern freier Software sowie über guten Programmierstil im Allgemeinen.

note: (itstool) path: item/p
en: <link href="http://producingoss.com/">Producing Open Source Software</link>, by Karl Fogel. This is a truly excellent book of good practices that free software projects should follow. This is about <em>social aspects</em> of the project: how to treat contributors, how to organize and moderate communication, how to deal with non-profit foundations. If you ask yourself at any time, "how should I deal with $human_situation in the project?", this book may provide the answer.
de: <link href="http://producingoss.com/">Producing Open Source Software</link> von Karl Fogel. Dieses wirklich exzellente Buch enthält empfehlenswerte Vorgehensweisen für Projekte freier Software. Dabei geht es um die <em>sozialen Aspekte</em> des Projekts: Wie behandelt man Mitwirkende, wie organisiert und moderiert man Kommunikation, wie geht man mit Non-Profit-Organisationen um? Falls Sie sich schon einmal gefragt haben: »Wie muss ich mit $menschliche_situation im Projekt umgehen?«, dann könnte dieses Buch die Antwort parat haben.

note: (itstool) path: item/p
en: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. This is an old document, but it still has lots of excellent advice. It talks about C coding style, issues when dealing with plug-in systems, common option names for command-line programs, conventions for Makefiles, and some very GNU-ish details like using Texinfo for documentation.
de: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. Diese alte Dokument enthält viele exzellente Ratschläge. Es behandelt C-Programmierstile, Probleme bei Systemen mit Erweiterungen, Namen für übliche Einstellungen in Befehlszeilen-Programmen, Makefile-Konventionen und einige sehr GNU-spezifische Details wie die Verwendung von Texinfo in Dokumentationen.

note: (itstool) path: item/p
en: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst"> Linux Kernel Coding Style</link>. Explains the rationale for "big indentation", brace placement, concise but unambiguous naming, and centralized exit of functions.
de: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst"> Linux Kernel Coding Style</link>. Erklärt die Gründe für »Tiefe Einrückungen«, Klammernplatzierung, prägnante und eindeutige Benennungen sowie das zentralisierte Verlassen von Funktionen.

note: (itstool) path: info/desc
en: Backwards compatibility in APIs
de: Abwärtskompatibilität in APIs

note: (itstool) path: page/title
en: API stability
de: API-Stabilität

note: (itstool) path: synopsis/title
en: Summary
de: Zusammenfassung

note: (itstool) path: item/p
en: Define API stability guarantees for your project. (<link xref="#stability"/>)
de: Bestimmen Sie API-Stabilitätsgarantien für Ihr Projekt. (<link xref="#stability"/>)

note: (itstool) path: item/p
en: Ensure version numbers are changed as appropriate when API changes. (<link xref="#versioning"/>)
de: Stellen Sie sicher, dass bei API-Änderungen auch die entsprechende Versionsnummer geändert wird. (<link xref="#versioning"/>)

note: (itstool) path: section/title
en: API and ABI
de: API und ABI

note: (itstool) path: section/p
en: At a high level, an API – <em>Application Programming Interface</em> – is the boundary between two components when developing against them. It is closely related to an ABI – <em>Application Binary Interface</em> – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. More concretely, this normally means the C headers of a library form its API, and compiled library symbols its ABI. The difference between an API and ABI is given by compilation of the code: there are certain things in a C header, such as <code>#define</code>s, which can cause a library’s API to change without changing its ABI. But these differences are mostly academic, and for all practical purposes, API and ABI can be treated interchangeably.
de: Auf höherer Ebene ist eine API (<em>Application Programming Interface</em>) die Schnittstelle zwischen zwei Komponenten, die gegeneinander entwickelt werden. Sie ist nah verwandt mit der ABI (<em>Application Binary Interface</em>), der Binärschnittstelle zur Laufzeit. Eine Schnittstelle bestimmt die verschiedenen Möglichkeiten, wie andere Komponenten mit einer Komponente interagieren können. Im Normalfalls stellen die C-Header einer Bibliothek die API und die kompilierten Symbole die ABI einer Bibliothek dar . Der Unterschied zwischen API und ABI kommt vor allem durch die Kompilation des Quelltextes: so befinden sich in einer C-Headerdatei gewisse Sachen wie <code>#define</code>-Anweisungen, die zur Änderung der API führen können, ohne dass sich die ABI ändert. In der Praxis können die Unterschiede zwischen API und ABI aber vernachlässigt werden, weil sie meistens austauschbar behandelbar sind.

note: (itstool) path: section/p
en: Examples of API-incompatible changes to a C function would be to add a new parameter, change the function’s return type, or remove a parameter.
de: Beispiele für API-inkompatible Änderungen einer C-Funktion wären das Hinzufügen eines neuen Parameters, Ändern des Rückgabetyps einer Funktion oder die Entfernung eines Parameters.

note: (itstool) path: section/p
en: However, many other parts of a project can form an API. If a daemon exposes itself on D-Bus, the interfaces exported there form an API. Similarly, if a C API is exposed in higher level languages by use of GIR, the GIR file forms another API — if it changes, any higher level code using it must also change.
de: Aber auch andere Teile eines Projekts können eine API darstellen. Wenn sich ein Daemon über D-Bus exponiert, stellen die dort exportierten Schnittstellen eine API dar. Wenn eine C-API in einer höheren Programmiersprache durch Verwendung von GIR offengelegt wird, dann stellt die GIR-Datei eine andere Form von API dar — wenn sie sich ändert, muss sich auch der gesamte Code ändern, der sich darauf bezieht.

note: (itstool) path: section/p
en: Other examples of more unusual APIs are configuration file locations and formats, and GSettings schemas. Any changes to these could require code using your library to change.
de: Andere Beispiele von eher ungewöhnlichen APIs sind Konfigurationsdateiorte und -formate und GSettings-Schemas. Änderungenen an diesen könnten es erforderlich machen, dass sich auch Code ändern muss, der eine Bibliothek verwendet.

note: (itstool) path: section/title
en: Stability
de: Stabilität

note: (itstool) path: section/p
en: API stability refers to some level of guarantee from a project that its API will only change in defined ways in the future, or will not change at all. Generally, an API is considered ‘stable’ if it commits to backwards-compatibility (defined below); but APIs could also commit to being unstable or even forwards-compatible. The purpose of API stability guarantees is to allow people to use your project from their own code without worrying about constantly updating their code to keep up with API changes. Typical API stability guarantees mean that code which is compiled against one version of a library will run without problems against all future versions of that library with the same major version number — or similarly that code which runs against a daemon will continue to run against all future versions of that daemon with the same major version number.
de: API-Stabilität bezieht sich darauf, inwiefern ein Projekt garantiert, dass sich seine API nur auf bestimmten Wege verändern oder auch nicht mehr verändern wird. Allgemein wird eine API dann als sicher betrachtet, wenn sie sich auf Abwärtskompatibilität festlegt; eine API könnte sich aber auch darauf festlegen, instabil oder aufwärtskompatibel zu sein. Der Zweck einer API-Stabilitätsgarantie ist es anderen zu ermöglichen, ein Projekt in ihrem Code zu verwenden, ohne dass sie sich ständig Sorgen machen müssen, ihren Code dauernd ändern zu müssen, um API-Änderungen zu berücksichtigen. Eine typische API-Stabilitätsgarantie wäre, dass Code, der gegen eine bestimmte Version einer Bibliothek kompiliert wurde, ohne Probleme auch mit zukünftigen Versionen dieser Bibliothek mit derselben Hauptversionsnummer laufen wird — oder auch, dass Code, der gegen einen Daemon programmiert wurde, auch auf zukünftigen Versionen mit derselben Hauptversionsnummer laufen wird.

note: (itstool) path: section/p
en: It is possible to apply different levels of API stability to components within a project. For example, the core functions in a library could be stable, and hence their API left unchanged in future; while the newer, less core functions could be left unstable and allowed to change wildly until the right design is found, at which point they could be marked as stable.
de: Es ist möglich, verschiedene Ebenen von API-Stabilitätsgarantien auf Komponententen innerhalb eines Projekts anzubringen. Zum Beispiel könnten die Kernfunktionalitäten einer Bibliothek stabil sein und deshalb auch deren API unverändert bleiben, während die neueren, sekundäreren Funktionenen instabil bleiben und sich sehr stark ändern dürfen, solange bis das richtige Design gefunden wurde und sie dann als sicher gekennzeichnet werden könnten.

note: (itstool) path: section/p
en: Several types of stability commonly considered:
de: Im Allgemeinen werden verschiedene Typen der Stabilität bezeichnet:

note: (itstool) path: item/title
en: Unstable
de: Instabil (<em>unstable</em>)

note: (itstool) path: item/p
en: The API could change or be removed in future.
de: Die API kann sich ändern oder in der Zukunft geändert werden.

note: (itstool) path: item/title
en: Backwards compatible
de: Backwards compatible (Abwärtskompatibilität)

note: (itstool) path: item/p
en: Only changes which permit code compiled against the unmodified API to continue running against the modified API are allowed (for example, functions cannot be removed).
de: Es sind nur solche Änderungen zulässig, die einem Code, der gegen die unmodifizierte API kompiliert wird, erlauben, auch mit der geänderten API zu laufen (z.B. können keine Funktionen entfernt werden).

note: (itstool) path: item/title
en: Forwards compatible
de: Forwards compatible (Aufwärtskompatibilität)

note: (itstool) path: item/p
en: Only changes which permit code compiled against the modified API to run against the unmodified API are allowed (for example, functions cannot be added).
de: Es sind nur solche Änderungen zulässig, die einem Code, der gegen die modifizierte API kompiliert wird, erlauben, auch mit der vorherigen API zu laufen (z.B. können keine Funktionen hinzugefügt  werden).

note: (itstool) path: item/title
en: Totally stable
de: Gänzlich unveränderlich (<em>totally stable</em>)

note: (itstool) path: item/p
en: No changes are allowed to the API, only to the implementation.
de: Es sind keine Änderungen an der API erlaubt, nur an deren Implementation.

note: (itstool) path: section/p
en: Typically, projects commit to backwards-compatibility when they say an API is ‘stable’. Very few projects commit to total stability because it would prevent almost all further development of the project.
de: Üblicherweise verpflichtet sich ein Projekt zur Abwärtskompatibilität, wenn es meint, eine API wäre 'stabil' (<em>stable</em>). Die wenigsten Projekte verpflichten sich zu einer gänzlichen Unveränderlichkeit (<em>total stability</em>), weil es fast die ganze weitere Entwicklung des Projektes verhindern würde.

note: (itstool) path: section/title (itstool) path: page/title
en: Versioning
de: Versionierung

note: (itstool) path: section/p
en: API stability guarantees are strongly linked to project versioning; both package versioning and libtool versioning. Libtool versioning exists entirely for the purpose of tracking ABI stability, and is explained in detail on the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link> or <link xref="versioning"/>.
de: API-Stabilitätsgarantien sind eng mit der Versionierung des Projekts verknüpft; das betrifft sowohl die Paket- als auch die Libtool-Versionierung. Letztere dient ausschließlich dem Zweck, die API-Stabilität zu überwachen, sie wird detailliert in <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link> oder <link xref="versioning"/> erklärt.

note: (itstool) path: section/p
en: Package versioning (<em>major.minor.micro</em>) is strongly linked to API stability: typically, the major version number is incremented when backwards-incompatible changes are made (for example, when functions are renamed, parameters are changed, or functions are removed). The minor version number is incremented when forwards-incompatible changes are made (for example, when new public API is added). The micro version number is incremented when code changes are made without modifying API. See <link xref="versioning"/> for more information.
de: Paketversionierung (<em>major.minor.micro</em>) ist eng mit API-Stabilität verknüpft: typischerweise, wird die Hauptversionsnummer (<em>major version number</em>) erhöht, wenn eine Änderung nicht mehr abwärtskompatibel ist (zum Beispiel wenn Funktionen umbenannt, Parameter geändert oder Funktionen entfernt werden). Die Nebenversionsnummer (<em>minor version number</em>) wird erhöht, wenn eine Änderung nicht mehr aufwärtskompatibel ist (zum Beispiel wenn eine neue öffentliche API hinzugefügt wird). Die dritte Versionsnummer (<em>micro version number</em>) wird erhöht, wenn die Code-Änderungen ohne Änderung der API möglich sind. Siehe <link xref="versioning"/> für weitere Informationen.

note: (itstool) path: section/p
en: API versioning is just as important for D-Bus APIs and GSettings schemas (if they are likely to change) as for C APIs. See the <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">documentation on D-Bus API versioning</link> for details.
de: API-Versionierung ist genauso wichtig für D-Bus-Schnittstellen und GSettings-Schemas (falls sie sich häufiger ändern) wie für C-Programmierschnittstellen. Siehe die <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">Dokumentation der D-Bus-API-Versionierung</link> für Details.

note: (itstool) path: section/p
en: For GIR APIs, their stability typically follows the C API stability, as they are generated from the C API. One complexity is that their stability additionally depends on the version of gobject-introspection used in generating the GIR, but recent versions have not changed much so this is not a major concern.
de: Die Stabilität von GIR-Schnittstellen orientiert sich normalerweise an der C-API-Stabilität, weil sie aus der C-API generiert werden. Eine Komplikation dabei ist, dass deren Stabilität zusätzlich noch von der Version der GObject-Introspektion abhängt, die zur Generierung der GIR verwendet wurde. Die neueren Versionen von GIR haben sich nicht so sehr geändert, weshalb das kein großer Grund zur Besorgnis sein sollte.

note: (itstool) path: section/title
en: External Links
de: Externe Links

note: (itstool) path: section/p
en: The topic of API stability is covered in the following articles:
de: Das Thema API-Stabilität wird in den folgenden Artikeln behandelt:

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_programming_interface">Wikipedia page on APIs</link>
de: <link href="https://de.wikipedia.org/wiki/Programmierschnittstelle">Wikipedia-Seite zu Programmierschnittstellen</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_binary_interface">Wikipedia page on ABIs</link>
de: <link href="https://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle">Wikipedia-Seite zu Binärschnittstellen</link>

note: (itstool) path: item/p
en: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">D-Bus API versioning documentation</link>
de: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">Dokumentation zur Versionierung der D-Bus-API</link>

note: (itstool) path: info/desc
en: Use of GLib-style asynchronous methods in various situations
de: Verwendung von asynchronen Methoden im Glib-Stil in verschiedenen Situationen

note: (itstool) path: page/title
en: Asynchronous Programming
de: Asynchrone Programmierung

note: (itstool) path: item/p
en: Use asynchronous calls in preference to synchronous calls or explicit use of threads (<link xref="#concepts"/>)
de: Bevorzugen Sie asynchrone gegenüber synchronen Aufrufen oder der expliziten Verwendung von Threads (<link xref="#concepts"/>)

note: (itstool) path: item/p
en: Learn and follow the GLib pattern for declaring asynchronous APIs (<link xref="#api-pattern"/>)
de: Lernen und wenden Sie die GLib-Muster zur Deklaration asynchroner APIs an (<link xref="#api-pattern"/>)

note: (itstool) path: item/p
en: Place callbacks from asynchronous functions in order down the file, so control flow is easy to follow (<link xref="#single-call"/>)
de: Platzieren Sie Callbacks asynchroner Funktionen in der richtigen Reihenfolge innerhalb der Datei, damit dem Kontrollfluss leicht gefolgt werden kann (<link xref="#single-call"/>)

note: (itstool) path: item/p
en: Use the presence of a <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> or <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> to indicate whether an operation is ongoing (<link xref="#single-call"/>, <link xref="#gtask"/>)
de: Verwenden Sie ein <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> oder <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link>, um anzugeben, ob eine Operation gerade läuft (<link xref="#single-call"/>, <link xref="#gtask"/>)

note: (itstool) path: item/p
en: If running operations in parallel, track how many operations are yet to start, and how many are yet to finish — the overall operation is complete once both counts are zero (<link xref="#parallel"/>)
de: Wenn Sie Operationen parallel laufen lassen, sollten Sie verfolgen, wie viele Operationen noch gestartet werden müssen und wieviele noch nicht beendet sind — die übergeordnete Operation ist abgeschlossen, sobald beide Zähler null sind (<link xref="#parallel"/>)

note: (itstool) path: item/p
en: Separate state for operations into ‘task data’ structures for <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code>s</link>, allowing operations to be reused more easily without needing changes to global state handling (<link xref="#gtask"/>)
de: Separieren Sie den Status von Operationen in »Task-Daten«-Strukturen für <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code>s</link>, wodurch Operationen einfacher wiederverwendet werden können, ohne dass Änderungen auf der globalen Statusbehandlung nötig werden (<link xref="#gtask"/>)

note: (itstool) path: item/p
en: Consider how asynchronous methods on an object instance interact with finalization of that instance (<link xref="#lifetimes"/>)
de: Überlegen Sie sich, wie sich asynchrone Methoden einer Objektinstanz verhalten sollen, wenn die Instanz finalisiert wird (<link xref="#lifetimes"/>)

note: (itstool) path: section/title
en: Concepts
de: Konzepte

note: (itstool) path: section/p
en: GLib supports <em>asynchronous</em> programming, where long-running operations can be started, run ‘in the background’, and a callback invoked when they are finished and their results are available. This is in direct contrast to <em>synchronous</em> long-running operations, which are a single function call which blocks program control flow until complete.
de: GLib unterstützt <em>asynchrone</em> Programme, bei denen lang-laufende Operationen gestartet werden können, die dann »im Hintergrund« laufen und einen Callback aufrufen, sobald sie geendet haben und die Ergebnisse verfügbar sind. Dies steht im unmittelbaren Kontrast zu <em>synchronen</em> lang-laufenden Operationen, bei denen ein einzelner Funktionsaufruf den gesamten Programmfluss blockiert, bis er geendet hat.

note: (itstool) path: section/p
en: As discussed in <link xref="main-contexts"/> and <link xref="threading#when-to-use-threading"/>, asynchronous operations should be favoured over synchronous ones and over explicit use of threading. They do not block the main context like sychronous operations do; and are easier to use correctly than threads. They often also have a lower performance penalty than spawning a thread and sending work to it.
de: Wie in <link xref="main-contexts"/> und <link xref="threading#when-to-use-threading"/> besprochen, sollten asynchrone Operationen gegenüber synchronen Operationen und explizitem Threading bevorzugt werden. Sie blocken nicht den Hauptkontext wie synchrone Operationen und sind einfacher zu verwenden als Threads. Ebenfalls haben sie oft einen geringeren Leistungsverlust als einen Thread zu erzeugen und Arbeit an ihn zu senden.

note: (itstool) path: section/title
en: API Pattern
de: API-Muster

note: (itstool) path: section/p
en: Asynchronous calls follow a standard pattern in GLib code. For an operation named <code>load_data</code> on the <code>File</code> class in the <code>Foo</code> namespace, there will be:
de: Asynchrone Aufrufe folgen in GLib-Code einem Standardmuster. Für eine Operation namens <code>load_data</code> in der Klasse <code>File</code> im <code>Foo</code>-Namensraum gibt es:

note: (itstool) path: section/p
en: The <code>…</code> parameters to <code>foo_file_load_data_async()</code> are those specific to the operation — in this case, perhaps the size of a buffer to load into. Similarly for <code>foo_file_load_data_finish()</code> they are the operation-specific return values — perhaps a location to return a content type string in this case.
de: Die Parameter<code>…</code> für <code>foo_file_load_data_async()</code> sind die operationsspezifischen Parameter — in diesem Fall vermutlich die Größe eines Puffers, in den geladen werden soll. Äquivalent dazu handelt es sich bei <code>foo_file_load_data_finish()</code> um die operationsspezifischen Rückgabewerte — in diesem Fall vielleicht ein Ort, in dem ein Content-Typ-String zurückgegeben wird.

note: (itstool) path: section/p
en: When <code>foo_file_load_data_async()</code> is called, it schedules the load operation in the background (as a new file descriptor on the <link xref="main-contexts"><code>GMainContext</code></link> or as a worker thread, for example), then returns without blocking.
de: Wenn <code>foo_file_load_data_async()</code> aufgerufen wird, plant es die Laden-Operation im Hintergrund ein (zum Beispiel als ein neuer Dateideskriptor auf dem <link xref="main-contexts"><code>GMainContext</code></link> oder als Arbeits-Thread) und kehrt nicht-blockend zurück.

note: (itstool) path: section/p
en: When the operation is complete, the <code>callback</code> is executed in the same <code>GMainContext</code> as the original asynchronous call. The callback is invoked <em>exactly</em> once, whether the operation succeeded or failed.
de: Sobald die Operation beendet ist, wird der <code>callback</code> im selben <code>GMainContext</code> wie der ursprüngliche asynchrone Aufruf ausgeführt. Der Callback wird <em>genau</em> einmal aufgerufen, egal ob die Operation erfolgreich war oder fehlgeschlagen ist.

note: (itstool) path: section/p
en: From the callback, <code>foo_file_load_data_finish()</code> may be called by the user’s code to retrieve return values and error details, passing the <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html"><code>GAsyncResult</code></link> instance which was passed to the callback.
de: Aus dem Callback heraus kann <code>foo_file_load_data_finish()</code> aufgerufen werden, um Rückgabewerte und Fehlerdetails zu erhalten. Dabei wird die <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html"><code>GAsyncResult</code></link>-Instanz übergeben, die dem Callback übergeben wurde.

note: (itstool) path: section/title
en: Operation Lifetimes
de: Lebensdauer von Operationen

note: (itstool) path: section/p
en: When writing asynchronous operations, it is common to write them as methods of a class. In this case, it is important to define how ongoing operations on a class instance interact with finalization of that instance. There are two approaches:
de: Beim Schreiben von asynchronen Operationen ist es üblich, sie als Klassenmethoden zu definieren. Sie sollten hierbei überlegen, wie laufende Operationen einer Klasseninstanz damit umgehen sollen, wenn die Instanz finalisiert wird. Es gibt zwei Ansätze:

note: (itstool) path: item/title
en: Strong
de: Stark

note: (itstool) path: item/p
en: The ongoing operation keeps a reference to the class instance, forcing it to remain alive for the duration of the operation. The class should provide some kind of ‘close’ or ‘cancel’ method which can be used by other classes to force cancellation of the operation and allow that instance to be finalized.
de: Die laufende Operation erhält eine Referenz der Klasseninstanz, wodurch die Instanz bis zum Ende der Operation am Leben bleibt. Die Klasse sollte dann eine Methode wie »close« oder »cancel« enthalten, die von anderen Klassen verwendet werden kann, um einen Abbruch der Operation zu erzwingen und damit die Instanz zu finalisieren.

note: (itstool) path: item/title
en: Weak
de: Schwach

note: (itstool) path: item/p
en: The ongoing operation does <em>not</em> keep a reference to the class instance, and the class cancels the operation (using <link href="https://developer.gnome.org/gio/stable/GCancellable.html#g-cancellable-cancel"><code>g_cancellable_cancel()</code></link>) in its dispose function.
de: Die laufende Operation erhält <em>keine</em> Referenz der Klasseninstanz. Die Klasse bricht die Operation in ihrer Dispose-Funktion (mittels <link href="https://developer.gnome.org/gio/stable/GCancellable.html#g-cancellable-cancel"><code>g_cancellable_cancel()</code></link>) ab.

note: (itstool) path: section/p
en: Which approach is used depends on the class’ design. A class which wraps a particular operation (perhaps a <code>MyFileTransfer</code> class, for example) might want to use the <em style="strong">weak</em> approach. A class which manages multiple network connections and asynchronous operations on them may use the <em style="strong">strong</em> approach instead. Due to incoming network connections, for example, it might not be in complete control of the scheduling of its asynchronous calls, so the weak approach would not be appropriate — any code dropping a reference to the object could not be sure it was not accidentally killing a new network connection.
de: Welcher Ansatz verwendet wird, hängt vom Design der Klasse ab. Eine Klasse, die eine bestimmte Operation verpackt (vielleicht etwa eine <code>MyFileTransfer</code>-Klasse) könnte den <em style="strong">schwachen</em> Ansatz verwenden. Eine Klasse hingegen, die mehrere Netzwerkverbindungen mit asynchronen Operationen verwaltet, könnte den <em style="strong">starken</em> Ansatz verwenden. Aufgrund eingehender Netzwerkverbindungen könnte sie nicht die vollständige Kontrolle über die asynchronen Aufrufe besitzen. In diesem Fall wäre der schwache Ansatz nicht angebracht, da man versehentlich eine neue Netzwerkverbindung verlieren könnte, wenn man eine Referenz des Objekts freigibt.

note: (itstool) path: section/title
en: Examples of Using Asynchronous Functions
de: Beispiele für die Verwendung asynchroner Funktionen

note: (itstool) path: section/p
en: It is often the case that multiple asynchronous calls need to be used to complete an operation. For example, opening a file for reading, then performing a couple of reads, and then closing the file. Or opening several network sockets in parallel and waiting until they are all open before continuing with other work. Some examples of these situations are given below.
de: Häufig werden mehrere asynchrone Aufrufe benötigt, um eine Operation durchzuführen. Um etwa den Inhalt einer Datei zu lesen, muss man erst die Datei öffnen, dann einige Lese-Befehle ausführen und anschließend die Datei wieder schließen. Ein anderes Beispiel wäre das parallele Öffnen mehrerer Netwerk-Sockets und anschließende Warten, bis alle geöffnet sind, bevor man weiterarbeiten kann. Einige Beispiele für solche Situationen sind im Folgenden aufgeführt.

note: (itstool) path: section/title
en: Single Operation
de: Einzelne Operation

note: (itstool) path: section/p
en: A single asynchronous call requires two functions: one to start the operation, and one to complete it. In C, the demanding part of performing an asynchronous call is correctly storing state between these two functions, and handling changes to that state in the time between those two functions being called. For example, cancellation of an ongoing asynchronous call is a state change, and if not implemented carefully, any UI updates (for example) made when cancelling an operation will be undone by updates in the operation’s callback.
de: Ein einzelner asynchroner Aufruf erfordert zwei Funktionen: eine zum Starten und eine zum Beenden der Operation. Die Herausforderung von asynchronen Aufrufen in C liegt darin, den Status in der Zeit zwischen den beiden Funktionen richtig zu speichern, und Statusänderungen zu behandeln. Das Abbrechen einer laufenden asynchronen Operation ist zum Beispiel eine Statusänderung; wird sie nicht sorgfältig behandelt, könnten Änderungen in der Benutzeroberfläche, die eigentlich durch den Abbruch der Operation entstanden sind, durch den Callback anschließend wieder rückgängig gemacht werden.

note: (itstool) path: example/p
en: This example demonstrates copying a file from one location in the file system to another. The key principles demonstrated here are:
de: Dieses Beispiel demonstriert das Kopieren einer Datei von einem Ort im Dateisystem an einen anderen. Die hier demonstrierten Schlüsselprinzipien sind:

note: (itstool) path: item/p
en: Placing the <code>copy_button_clicked_cb()</code> (start) and <code>copy_finish_cb()</code> (finish) functions in order by using a forward declaration for <code>copy_finish_cb()</code>. This means the control flow continues linearly down the file, rather than getting to the bottom of <code>copy_button_clicked_cb()</code> and resuming in <code>copy_finish_cb()</code> somewhere else in the file.
de: Platzieren der Funktionen <code>copy_button_clicked_cb()</code> (Start) und <code>copy_finish_cb()</code> (Beenden) in dieser Reihenfolge durch Verwendung eines Funktionskopfes (»forward declaration«) für <code>copy_finish_cb()</code>. Dadurch folgt der Kontrollfluss linear den Zeilen der Datei, anstatt erst zum Ende von <code>copy_button_clicked_cb()</code> zu gelangen und anschließend wieder irgendwohin in die Datei zu springen, um in <code>copy_finish_cb()</code> weiterzumachen.

note: (itstool) path: item/p
en: Use of a <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> to allow cancelling the operation after it has started. The code in <code>cancel_button_clicked_cb()</code> is very simple: as the <code>copy_finish_cb()</code> callback is <em>guaranteed</em> to be invoked when the operation completes (even when completing early due to cancellation), all the UI and state updates for cancellation can be handled there, rather than in <code>cancel_button_clicked_cb()</code>.
de: Verwendung einer <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link>, um den Abbruch der Operation nach deren Start zu erlauben. Der Code in <code>cancel_button_clicked_cb()</code> ist sehr einfach: da der Callback von <code>copy_finish_cb()</code> <em>garantiert</em> aufgerufen wird, sobald die Operation geendet hat (auch vorzeitig durch einen Abbruch), können alle Status- und Benutzeroberflächen-Änderungen hier statt in <code>cancel_button_clicked_cb()</code> behandelt werden.

note: (itstool) path: item/p
en: An operation is ongoing exactly while <code>MyObjectPrivate.copy_cancellable</code> is non-<code>NULL</code>, making it easy to track running operations. Note that this means only one file copy operation can be started via <code>copy_button_clicked_cb()</code> at a time. One <code>GCancellable</code> cannot easily be used for multiple operations like this.
de: Eine Operation läuft genau so lange, wie <code>MyObjectPrivate.copy_cancellable</code> nicht <code>NULL</code> ist, weshalb man laufende Operationen leicht verfolgen kann. Beachten Sie, dass daher nicht mehrere Kopiervorgänge gleichzeitig per <code>copy_button_clicked_cb()</code> gestartet werden können. Ein <code>GCancellable</code> kann nicht so einfach für mehrere Operationen wie diese verwendet werden.

note: (itstool) path: example/p
en: For comparison, here is the same code implemented using the <em>synchronous</em> version of <link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-copy"><code>g_file_copy()</code></link>. Note how the order of statements is almost identical. Cancellation cannot be supported here, as the UI is blocked from receiving ‘click’ events on the cancellation button while the copy is ongoing, so <code>NULL</code> is passed to the <code>GCancellable</code> parameter. This is the main reason why this code should <em>not</em> be used in practice.
de: Zum Vergleich ist hier der gleiche Code als <em>synchrone</em> Version von <link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-copy"><code>g_file_copy()</code></link> implementiert. Wie Sie sehen, ist die Reihenfolge der Statements fast identisch. Ein Abbruch kann nicht unterstützt werden, da die Benutzeroberfläche blockiert ist und daher keine »Klick«-Events auf dem Abbruchknopf empfangen kann, während der Kopiervorgang läuft. Deshalb wurde dem <code>GCancellable</code>-Parameter der Wert <code>NULL</code> übergeben. Dies ist der Hauptgrund, weshalb dieser Code <em>nicht</em> verwendet werden sollte.

note: (itstool) path: section/title
en: Operations in Series
de: Operationen in Serie

note: (itstool) path: section/p
en: A common situation is to run multiple asynchronous operations in series, when each operation depends on the previous one completing.
de: Eine typische Situation besteht darin, mehrere asynchrone Operationen hintereinander auszuführen, wobei jede Operation von der Beendigung der vorangegangenen abhängt.

note: (itstool) path: example/p
en: In this example, the application reads a socket address from a file, opens a connection to that address, reads a message, and then finishes.
de: In diesem Beispiel liest die Anwendung eine Socketadresse aus einer Datei aus, öffnet eine Verbindung zu dieser Adresse, liest eine Nachricht und endet dann.

note: (itstool) path: example/p
en: Key points in this example are:
de: Die Hauptpunkte in diesem Beispiel sind:

note: (itstool) path: item/p
en: Each callback is numbered consistently, and they are all placed in order in the file so the code follows sequentially.
de: Jeder Callback ist durchgängig nummeriert und in der richtigen Reihenfolge in der Datei platziert, sodass der Code sequentiell durchläuft.

note: (itstool) path: item/p
en: As in <link xref="#single-call"/>, a single <code>GCancellable</code> indicates that the series of operations is ongoing. Cancelling it aborts the entire sequence.
de: Wie in <link xref="#single-call"/> weist ein einzelnes <code>GCancellable</code> darauf hin, dass die Serie an Operationen gerade läuft. Ein Abbruch beendet die gesamte Serie.

note: (itstool) path: item/p
en: As in <link xref="#single-call"/>, the pending operation is cancelled if the owning <code>MyObject</code> instance is disposed, to prevent callbacks being called later with an invalid <code>MyObject</code> pointer.
de: Wie in <link xref="#single-call"/> wird eine ausstehende Operation abgebrochen, wenn die <code>MyObject</code>-Instanz, zu dem die Operation gehört, entsorgt wird. Dadurch wird vermieden, dass Callbacks später mit einem ungültigen <code>MyObject</code>-Zeiger aufgerufen werden.

note: (itstool) path: example/p
en: <link xref="#gtask"/> gives a version of this example wrapped in a <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> for convenience.
de: <link xref="#gtask"/> zeigt eine Version dieses Beispiels, in dem es in einem <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> eingebettet ist.

note: (itstool) path: section/title
en: Operations in Parallel
de: Parallele Operationen

note: (itstool) path: section/p
en: Another common situation is to run multiple asynchronous operations in parallel, considering the overall operation complete when all its constituents are complete.
de: Eine andere typische Situation besteht darin, mehrere asynchrone Operationen gleichzeitig zu starten, wobei der Vorgang insgesamt als abgeschlossen gilt, wenn alle Bestandteile geendet haben.

note: (itstool) path: example/p
en: In this example, the application deletes multiple files in parallel.
de: In diesem Beispiel entfernt die Anwendung mehrere Dateien parallel.

note: (itstool) path: item/p
en: The number of pending asynchronous operations (ones which have started but not yet finished) is tracked as <code>n_deletions_pending</code>. The <code>delete_files_cb()</code> callback only considers the entire operation complete once this reaches zero.
de: Die Anzahl der laufenden asynchronen Operationen (Operationen, die gestartet aber noch nicht beendet sind) wird in <code>n_deletions_pending</code> verfolgt. Der Callback <code>delete_files_cb()</code> betrachtet die gesamte Operation erst als abgeschlossen, sobald diese Variable null erreicht hat.

note: (itstool) path: item/p
en: <code>n_deletions_to_start</code> tracks deletion operations being started, in case <link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-delete-async"><code>g_file_delete_async()</code></link> manages to use a fast path and complete synchronously (without blocking).
de: <code>n_deletions_to_start</code> enthält die Anzahl der gestarteten Löschen-Operationen für den Fall, dass <link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-delete-async"><code>g_file_delete_async()</code></link> einen Fast Path verwendet und synchron endet (nicht-blockend).

note: (itstool) path: item/p
en: As in <link xref="#single-call"/>, all pending deletions are cancelled if the owning <code>MyObject</code> instance is disposed, to prevent callbacks being called later with an invalid <code>MyObject</code> pointer.
de: Wie in <link xref="#single-call"/> werden ausstehende Operationen abgebrochen, wenn die <code>MyObject</code>-Instanz, zu dem die Operationen gehören, entsorgt wird. Dadurch wird vermieden, dass Callbacks später mit einem ungültigen <code>MyObject</code>-Zeiger aufgerufen werden.

note: (itstool) path: section/title
en: Wrapping with <code>GTask</code>
de: In einen <code>GTask</code> einbetten

note: (itstool) path: section/p
en: Often when an asynchronous operation (or set of operations) becomes more complex, it needs associated state. This is typically stored in a custom structure — but defining a new structure to store the standard callback, user data and cancellable tuple is laborious. <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> eases this by providing a standardized way to wrap all three, plus extra custom ‘task data’.
de: Wenn eine asynchrone Operation (oder mehrere) komplexer wird, benötigt sie einen zugeordneten Status. Dieser ist für gewöhnlich in einer selbst geschriebenen Struktur hinterlegt. So eine Struktur zum Speichern des Standard-Callbacks, der Benutzerdaten sowie der Abbruchfunktion zu definieren erfordert aber eine Menge Arbeit. Der <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> hilft dabei, indem er eine Struktur zum Einbetten dieser drei Teile sowie einige zusätzliche »Task-Daten« vorgibt.

note: (itstool) path: section/p
en: The use of a <code>GTask</code> can replace the use of a <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> for indicating whether an operation is ongoing.
de: Die Nutzung eines <code>GTask</code>s ersetzt die Verwendung eines <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> um anzugeben, ob eine Operation gerade läuft.

note: (itstool) path: example/p
en: This example is functionally the same as <link xref="#series"/>, but refactored to use a <code>GTask</code> to wrap the sequence of operations.
de: Dieses Beispiel ist inhaltlich gleich zu dem in <link xref="#series"/>, verwendet aber einen <code>GTask</code>, um die Serie an Operationen einzubetten.

note: (itstool) path: item/p
en: State which was in <code>MyObjectPrivate</code> in <link xref="#series"/> is now in the <code>ConnectToServerData</code> closure, which is set as the ‘task data’ of the <code>GTask</code> representing the overall operation. This means it’s automatically freed after the operation returns.
de: Der Status, der in <link xref="#series"/> in <code>MyObjectPrivate</code> gespeichert war, befindet sich hier im Funktionsabschluss (»Closure«) <code>ConnectToServerData</code>, der dem <code>GTask</code> als »Task-Daten« übergeben wird und die gesamte Operation repräsentiert. Das bedeutet, dass er automatisch freigegeben wird, sobald die Operation beendet ist.

note: (itstool) path: item/p
en: Furthermore, this means that manipulations of <code>MyObjectPrivate</code> state are limited to the start and end of the sequence of operations, so reusing the task in different situations becomes easier — for example, it is now a lot easier to support running multiple such tasks in parallel.
de: Weiterhin sind Statusänderungen von <code>MyObjectPrivate</code> auf den Beginn und das Ende der Operationen-Sequenz beschränkt. Daher ist es viel einfacher, den Task in verschiedenen Situationen wiederzuverwenden. Beispielsweise ist es viel einfacher, mehrere Operationen gleichzeitig laufen zu lassen.

note: (itstool) path: item/p
en: As the <code>GTask</code> holds a reference to <code>MyObject</code>, it is impossible for the object to be disposed while the sequence of operations is ongoing, so the <code>my_object_dispose()</code> code has been removed. Instead, a <code>my_object_close()</code> method exists to allow any pending operations can be cancelled so <code>MyObject</code> can be disposed when desired.
de: Da der <code>GTask</code> eine Referenz auf <code>MyObject</code> besitzt, kann das Objekt unmöglich entsorgt werden, während die Serie an Operationen gerade läuft. <code>my_object_dispose()</code> wurde daher entfernt. Stattdessen gibt es nun die Methode <code>my_object_close()</code>, mit der ausstehende Operationen abgebrochen werden können, sodass das <code>MyObject</code> auf Wunsch entsorgt werden kann.

note: (itstool) path: credit/name
en: The GTK+ Team
de: Das GTK-Team

note: (itstool) path: info/desc
en: Our guidelines for C code in GNOME
de: Unsere Richtlinien für C-Code in GNOME

note: (itstool) path: page/title
en: C Coding Style
de: C-Programmierstil

note: (itstool) path: page/p
en: This document presents the preferred coding style for C programs in GNOME. While coding style is very much a matter of taste, in GNOME we favor a coding style that promotes consistency, readability, and maintainability.
de: Dieses Dokument präsentiert den bevorzugten Programmierstil für C-Programme in GNOME. Auch wenn das eigentlich Geschmackssache ist, bevorzugen wir in GNOME einen Programmierstil der Konsistenz, Lesbarkeit und Wartbarkeit begünstigt.

note: (itstool) path: page/p
en: We present examples of good coding style as well as examples of bad style that is not acceptable in GNOME. Please try to submit patches that conform to GNOME’s coding style; this indicates that you have done your homework to respect the project’s goal of long-term maintainability. Patches with GNOME’s coding style will also be easier to review!
de: Wir präsentieren Beispiele mit guten Programmierstil sowie mit schlechtem Programmierstil, der in GNOME nicht annehmbar ist. Bitte versuchen Sie Patches einzureichen, die mit dem GNOME-Programmierstil übereinstimmen; das weist darauf hin, dass Sie Ihre Hausaufgaben gemacht haben, um das Projektziel der Langzeit-Wartbarkeit zu respektieren. Patches im GNOME-Programmierstil sind auch einfacher zu rezensieren!

note: (itstool) path: note/p
en: This document is for C code. For other languages, check the <link xref="index">main page</link> of the GNOME Programming Guidelines.
de: Dieses Dokument bezieht sich auf C-Programmcode. Informationen zu anderen Sprachen finden Sie auf der <link xref="index">Hauptseite</link> der GNOME-Programmierrichtlinien.

note: (itstool) path: page/p
en: These guidelines are heavily inspired by GTK’s CODING-STYLE document, the Linux Kernel’s CodingStyle, and the GNU Coding Standards. These are slight variations of each other, with particular modifications for each project’s particular needs and culture, and GNOME’s version is no different.
de: Diese Richtlinien sind stark von GTKs CODING-STYLE-Dokument, dem Programmierstil vom Linux-Kernel und den GNU Coding Standards inspiriert. Dabei sind das jeweils leichte Variationen voneinander, mit bestimmten Anpassungen an die besonderen Bedürfnisse und Gepflogenheiten des jeweiligen Projekts und die GNOMEs Version ist dabei keine Ausnahme.

note: (itstool) path: section/title
en: The Single Most Important Rule
de: Die allerwichtigste Regel

note: (itstool) path: section/p
en: The single most important rule when writing code is this: <em>check the surrounding code and try to imitate it</em>.
de: Die allerwichtigste Regel für das Schreiben von Code ist: <em>Untersuchen Sie den umgebenden Code und versuchen Sie, dessen Stil zu imitieren</em>.

note: (itstool) path: section/p
en: As a maintainer it is dismaying to receive a patch that is obviously in a different coding style to the surrounding code. This is disrespectful, like someone tromping into a spotlessly-clean house with muddy shoes.
de: Für einen Maintainer ist es schrecklich, einen Patch zu bekommen, der vom umgebenden Code stilistisch stark abweicht. Das ist respektlos wie jemand, der in ein blitzsauberes Haus mit schlammigen Schuhen hineintrampelt.

note: (itstool) path: section/p
en: So, whatever this document recommends, if there is already written code and you are patching it, keep its current style consistent even if it is not your favorite style.
de: Was auch immer dieses Dokument empfiehlt, Ihr Stil sollte sich stets am Stil des bereits vorhandenen Codes orientieren, auch wenn es nicht <em>Ihr bevorzugter Stil</em> ist.

note: (itstool) path: section/title
en: Line Width
de: Zeilenbreite

note: (itstool) path: section/p
en: Try to use lines of code between 80 and 120 characters long. This amount of text is easy to fit in most monitors with a decent font size. Lines longer than that become hard to read, and they mean that you should probably restructure your code. If you have too many levels of indentation, it means that you should fix your code anyway.
de: Versuchen Sie, Ihre Zeilen zwischen 80 und 120 Zeichen breit zu halten. Diese Breite passt am besten in die meisten Bildschirme mit einer vernünftigen Schriftgröße. Längere Zeilen sind schwerer zu lesen, außerdem sollten Sie sich in diesem Fall überlegen, ob Sie Ihren Code nicht anders beziehungsweise besser strukturieren sollten. Bei zu vielen Einrückungsebenen sollte Ihr Code ohnehin überarbeitet werden.

note: (itstool) path: section/title
en: Indentation
de: Einrückungen

note: (itstool) path: section/p
en: In general there are two preferred indentation styles for code in GNOME.
de: Allgemein gibt es zwei bevorzugte Einrückungsstile für Code in GNOME.

note: (itstool) path: item/p
en: Linux Kernel style. Tabs with a length of 8 characters are used for the indentation, with K&amp;R brace placement:
de: Linux-Kernel-Stil. Tabulatoren für Einrückungen sind 8 Zeichen breit, mit einer K&amp;R-Klammernplatzierung:

note: (itstool) path: item/p
en: GNU style. Each new level is indented by 2 spaces, braces go on a line by themselves, and they are indented as well.
de: GNU-Stil. Jede neue Ebene wird um zwei Leerzeichen eingerückt, Klammern werden in eine eigene Zeile gesetzt und ebenfalls eingerückt.

note: (itstool) path: section/p
en: Both styles have their pros and cons. The most important things is to <em>be consistent</em> with the surrounding code. For example, the GTK+ library, which is GNOME’s widget toolkit, is written with the GNU style. Nautilus, GNOME’s file manager, is written in Linux kernel style. Both styles are perfectly readable and consistent when you get used to them.
de: Beide Stile haben ihre Vor- und Nachteile. Der wichtigste Punkt ist die <em>Konsistenz</em> zum umgebenden Code. Zum Beispiel ist die GTK-Bibliothek als Widget-Toolkit für GNOME im GNU-Stil geschrieben. Nautilus dagegen, der Dateimanager von GNOME, folgt dem Linux-Kernel-Stil. Beide Stile sind bestens lesbar und konsistent, wenn Sie sie sich daran gewöhnen.

note: (itstool) path: section/p
en: Your first feeling when having to study or work on a piece of code that doesn’t have your preferred indentation style may be, how shall we put it, gut-wrenching. You should resist your inclination to reindent everything, or to use an inconsistent style for your patch. Remember the first rule: <em>be consistent</em> and respectful of that code’s customs, and your patches will have a much higher chance of being accepted without a lot of arguing about the right indentation style.
de: Ihr erstes Gefühl bei der Arbeit an Programmcode, der nicht Ihrem bevorzugten Einrückungsstil folgt, könnte, sagen wir, qualvoll sein. Widerstehen Sie dem Drang, alles neu einrücken zu wollen oder für Ihren Patch einen inkonsistenten Stil zu verwenden. Erinnern Sie sich an die oberste Regel: <em>Konsistenz</em> und Respekt vor den Eigenheiten des fremden Codes und Ihre Patches haben eine ungleich größere Chance, ohne langatmige Diskussionen über den <em>richtigen</em> Einrückungsstil, angenommen zu werden.

note: (itstool) path: section/title
en: Tab Characters
de: Tabulatorzeichen

note: (itstool) path: section/p
en: <em>Do not ever change the size of tabs in your editor</em>; leave them as 8 spaces. Changing the size of tabs means that code that you didn’t write yourself will be perpetually misaligned.
de: <em>Ändern Sie niemals die Tabulatorbreite in Ihrem Editor</em>. Bleiben Sie bei 8 Zeichen. Durch Änderungen der Tabulatorbreite wird Code, den Sie nicht selbst geschrieben haben, immer falsch ausgerichtet.

note: (itstool) path: section/p
en: Instead, set the <em>indentation size</em> as appropriate for the code you are editing. When writing in something other than Linux kernel style, you may even want to tell your editor to automatically convert all tabs to 8 spaces, so that there is no ambiguity about the intended amount of space.
de: Setzen Sie stattdessen die passende Einrückungsgröße für den Code, den Sie ändern. Wenn Sie nicht den Linux-Kernel-Stil verwenden, können Sie ihren Editor auch einstellen, alle Tabulatoren durch 8 Leerzeichen zu ersetzen, um Unklarheiten, wie viel Platz verwendet werden soll, zu vermeiden.

note: (itstool) path: section/title
en: Braces
de: Klammern

note: (itstool) path: section/p
en: Curly braces should not be used for single statement blocks:
de: Geschweifte Klammern sollten nicht für Blöcke mit einzelnen Anweisungen verwendet werden:

note: (itstool) path: section/p
en: The “no block for single statements” rule has only four exceptions:
de: Für die Regel »kein Block für einzelne Anweisungen« gibt es vier Ausnahmen:

note: (itstool) path: item/p
en: In GNU style, if either side of an if-else statement has braces, both sides should, to match up indentation:
de: Beim GNU-Stil sobald eine der beiden Seiten einer <code>if-else</code>-Anweisung eine geschwungene Klammer hat, sollte die andere Seite auch  eine bekommen, um die Einrückung anzupassen:

note: (itstool) path: item/p
en: If the single statement covers multiple lines, e.g. for functions with many arguments, and it is followed by <code>else</code> or <code>else if</code>:
de: Wenn sich die einzelne Anweisung über mehrere Zeilen erstreckt (zum Beispiel bei Funktionen mit vielen Argumenten) und wenn darauf <code>else</code> oder <code>else if</code> folgt:

note: (itstool) path: item/p
en: If the condition is composed of many lines:
de: Wenn die Bedingung aus mehreren Zeilen besteht:

note: (itstool) path: item/p
en: Note that such long conditions are usually hard to understand. A good practice is to set the condition to a boolean variable, with a good name for that variable. Another way is to move the long condition to a function.
de: Bedenken Sie, dass solche langen Bedingungen oft schwer verständlich sind. Eine gute Angewohnheit ist es, die Bedingung in eine boolesche Variable mit einem passenden Namen zu speichern. Eine weitere Möglichkeit wäre die Auslagerung der langen Bedingung in eine Funktion.

note: (itstool) path: item/p
en: Nested <code>if</code>s, in which case the block should be placed on the outermost <code>if</code>:
de: Verschachtelte <code>if</code>s, wobei der Block im äußersten <code>if</code> platziert werden sollte:

note: (itstool) path: section/p
en: In general, new blocks should be placed on a new indentation level, like this:
de: Generell sollten neue Blöcke in eine neue Einrückungsebene gesetzt werden, wie hier:

note: (itstool) path: section/p
en: While curly braces for function definitions should rest on a new line they should not add an indentation level:
de: Während geschweifte Klammern für Funktionsdefinitionen in eine neue Zeile gehören, sollten sie nicht weiter eingerückt werden:

note: (itstool) path: section/title
en: Conditions
de: Bedingungen

note: (itstool) path: section/p
en: Do not check boolean values for equality. By using implicit comparisons, the resulting code can be read more like conversational English. Another rationale is that a ‘true’ value may not be necessarily equal to whatever the <code>TRUE</code> macro uses. For example:
de: Überprüfen Sie boolesche Variablen nicht auf Gleichwertigkeit. Unter Verwendung von impliziten Vergleichen kann der resultierende Code mehr wie umgangssprachliches Englisch gelesen werden. Eine weitere Begründung ist, dass ein Wert, der als '<em>true</em>' evaluiert wird, nicht notwendigerweise mit dem <code>TRUE</code>-Makro gleichwertig ist. Zum Beispiel:

note: (itstool) path: section/p
en: The C language uses the value 0 for many purposes. As a numeric value, the end of a string, a null pointer and the <code>FALSE</code> boolean. To make the code clearer, you should write code that highlights the specific way 0 is used. So when reading a comparison, it is possible to know the variable type. For boolean variables, an implicit comparison is appropriate because it’s already a logical expression. Other variable types are not logical expressions by themselves, so an explicit comparison is better:
de: Die Programmiersprache C verwendet den Wert 0 für zahlreiche Zwecke: als numerischen Wert, als Ende einer Zeichenkette, als Null-Zeiger oder für den booleschen Wert <code>FALSE</code>. Um hier etwas mehr Klarheit zu schaffen, sollte dieser Zweck in Ihrem Code entsprechend hervorgehoben werden. So kann bei Vergleichen der Variablentyp erkannt werden. Für boolesche Variablen ist ein impliziter Vergleich angemessen, da es bereits ein logischer Ausdruck ist. Andere Variablentypen sind nicht direkt logische Ausdrücke, so dass ein expliziter Vergleich besser erscheint:

note: (itstool) path: section/title
en: Functions
de: Funktionen

note: (itstool) path: section/p
en: Functions should be declared by placing the returned value on a separate line from the function name:
de: Funktionen sollten so deklariert werden, dass der Rückgabetyp in einer separaten Zeile vom Funktionsnamen abgesetzt wird:

note: (itstool) path: section/p
en: The argument list must be broken into a new line for each argument, with the argument names right aligned, taking into account pointers:
de: Die Liste der Argumente muss auf mehrere Zeilen aufgeteilt werden, so dass jedes Argument in einer Zeile ist, wobei die jeweiligen Bezeichner unter Berücksichtigung von Zeigern rechtsbündig ausgerichtet werden:

note: (itstool) path: section/p
en: If you use Emacs, you can use <code>M-x align</code> to do this kind of alignment automatically. Just put the point and mark around the function’s prototype, and invoke that command.
de: Wenn Sie Emacs verwenden, können Sie mit <code>M-x align</code> diese Art der Ausrichtung automatisch erledigen lassen. Einfach den ganzen Funktionsprototypen markieren und den Befehl ausführen.

note: (itstool) path: section/p
en: The alignment also holds when invoking a function without breaking the line length limit:
de: Diese Ausrichtung gilt auch bei einem Funktionsaufruf, der die maximale Zeilenlänge nicht überschreiten würde:

note: (itstool) path: section/title
en: Whitespace
de: Leerzeichen

note: (itstool) path: section/p
en: Always put a space before an opening parenthesis but never after:
de: Setzen Sie stets vor einer öffnenden Klammer ein Leerzeichen, aber niemals dahinter:

note: (itstool) path: section/p
en: When declaring a structure type use newlines to separate logical sections of the structure:
de: Bei der Deklaration einer Struktur verwenden Sie einen Zeilenumbruch, um logische Abschnitte der Struktur zu trennen:

note: (itstool) path: section/p
en: Do not eliminate whitespace and newlines just because something would fit on a single line:
de: Entfernen Sie keine Leerzeichen und Zeilenumbrücke, nur weil etwas auch in eine einzelne Zeile passen würde:

note: (itstool) path: section/p
en: Do eliminate trailing whitespace on any line, preferably as a separate patch or commit. Never use empty lines at the beginning or at the end of a file.
de: Entfernen Sie stets angehängte Leerzeichen in jeder Zeile, vorzugsweise mittels separatem Patch oder Commit. Verwenden Sie keine Leerzeilen am Anfang oder am Ende einer Datei.

note: (itstool) path: section/p
en: This is a little Emacs function that you can use to clean up lines with trailing whitespace:
de: Hier ist eine kleine Emacs-Funktion, mit der Sie Zeilen mit angehängten Leerzeichen bereinigen können:

note: (itstool) path: section/title
en: The <code>switch</code> Statement
de: Die <code>switch</code>-Anweisung

note: (itstool) path: section/p
en: A <code>switch</code> should open a block on a new indentation level, and each <code>case</code> should start on the same indentation level as the curly braces, with the case block on a new indentation level:
de: Ein <code>switch</code> sollte einen Block in einer neuen Einrückungsebene öffnen, und jedes <code>case</code> sollte in der gleichen Einrückungsebene beginnen wie die geschweiften Klammern, mit dem <code>case</code>-Block in einer neuen Einrückungsebene:

note: (itstool) path: section/p
en: It is preferable, though not mandatory, to separate the various cases with a newline:
de: Es ist wünschenswert, wenn auch nicht zwingend notwendig, die unterschiedlichen Fälle durch Zeilenumbrüche voneinander zu trennen:

note: (itstool) path: section/p
en: The <code>break</code> statement for the <code>default</code> case is not mandatory.
de: Die <code>break</code>-Anweisung für den <code>default</code>-Fall ist nicht verpflichtend vorgeschrieben.

note: (itstool) path: section/p
en: If switching over an enumerated type, a <code>case</code> statement must exist for every member of the enumerated type. For members you do not want to handle, alias their <code>case</code> statements to <code>default</code>:
de: Wenn mit <code>switch</code> über einen Aufzählungstyp geschalten wird, muss es für jeden zulässigen Wert der Aufzählung eine <code>case</code>-Anweisung geben. Für Werte, die nicht extra behandeln werden sollen, kann der jeweilige <code>case</code> zu <code>default</code> geschalten werden:

note: (itstool) path: section/p
en: If most members of the enumerated type should not be handled, consider using an <code>if</code> statement instead of a <code>switch</code>.
de: Wenn die meisten Aufzählungswerte nicht behandelt werden sollen, ist es ratsam eine <code>if</code>-Anweisung statt einem <code>switch</code> zu verwenden.

note: (itstool) path: section/p
en: If a <code>case</code> block needs to declare new variables, the same rules as the inner blocks apply (see above); the <code>break</code> statement should be placed outside of the inner block:
de: Wenn ein <code>case</code>-Block neue Variablen deklarieren muss, gelten dieselben Regeln wie bei inneren Blöcken (siehe oben); die <code>break</code>-Anweisung sollte dabei außerhalb des inneren Blocks platziert werden:

note: (itstool) path: section/title
en: Header Files
de: Header-Dateien

note: (itstool) path: section/p
en: The only major rule for headers is that the function definitions should be vertically aligned in three columns:
de: Die einzige größere Regel für Header ist, dass die Funktionsdefinition vertikal in drei Spalten ausgerichtet sein sollte:

note: (itstool) path: section/p
en: The maximum width of each column is given by the longest element in the column:
de: Die maximale Breite jeder Spalte wird durch das längste Element in der Spalte bestimmt:

note: (itstool) path: section/p
en: It is also possible to align the columns to the next tab:
de: Es ist auch möglich, die Spalten am nächsten Tabulator auszurichten:

note: (itstool) path: section/p
en: As before, you can use <code>M-x align</code> in Emacs to do this automatically.
de: Wie schon erwähnt, erledigt Emacs dies mit <code>M-x align</code> automatisch.

note: (itstool) path: section/title
en: GObject Classes
de: GObject-Klassen

note: (itstool) path: section/p
en: GObject class definitions and implementations require some additional coding style notices, and should always be <link xref="namespacing#gobject">correctly namespaced</link>.
de: GObject-Klassendefinitionen und -implementierungen erfordern zusätzliche Programmierstil-Hinweise und sollten immer im <link xref="namespacing#gobject">richtigen Namensraum</link> sein.

note: (itstool) path: section/p
en: Typedef declarations should be placed at the beginning of the file:
de: Typedef-Deklarationen sollten am Anfang der Datei platziert werden:

note: (itstool) path: section/p
en: This includes enumeration types:
de: Hierzu gehören auch Aufzählungstypen:

note: (itstool) path: section/p
en: And callback types:
de: Und Callback-Typen:

note: (itstool) path: section/p
en: Instance structures should be declared using <code>G_DECLARE_FINAL_TYPE</code> or <code>G_DECLARE_DERIVABLE_TYPE</code>:
de: Instanzstrukturen sollten mit <code>G_DECLARE_FINAL_TYPE</code> oder <code>G_DECLARE_DERIVABLE_TYPE</code> deklariert werden:

note: (itstool) path: section/p
en: Interfaces must have the following macros:
de: Für Schnittstellen sind die folgenden Makros zu verwenden:

note: (itstool) path: td/p
en: Macro
de: Makro

note: (itstool) path: td/p
en: Expands to
de: Expandiert zu

note: (itstool) path: section/title
en: Memory Allocation
de: Speicherreservierung

note: (itstool) path: section/p
en: When dynamically allocating data on the heap use <code>g_new()</code>.
de: Verwenden Sie <code>g_new()</code> zum Reservieren von dynamischen Speicher.

note: (itstool) path: section/p
en: See <link xref="memory-management"/> for more details.
de: In <link xref="memory-management"/> finden Sie weitere Details.

note: (itstool) path: section/title
en: Macros
de: Makros

note: (itstool) path: section/p
en: Try to avoid private macros unless strictly necessary. Remember to <code>#undef</code> them at the end of a block or a series of functions needing them.
de: Versuchen Sie, auf private Makros zu verzichten, wenn diese nicht zwingend notwendig sind. Denken Sie an das <code>#undef</code> am Ende eines Blocks oder einer Serie an Funktionen, die die Makros benötigen.

note: (itstool) path: section/p
en: Inline functions are usually preferable to private macros.
de: Im Allgemeinen sind Inlinefunktionen gegenüber privaten Makros zu bevorzugen.

note: (itstool) path: section/p
en: Public macros should not be used unless they evaluate to a constant.
de: Auf öffentliche Makros sollten Sie außer zum Evaluieren einer Konstante verzichten.

note: (itstool) path: section/title
en: Public API
de: Öffentliche API

note: (itstool) path: section/p
en: Avoid exporting variables as public API, since this is cumbersome on some platforms. It is always preferable to add getters and setters instead. Also, beware global variables in general.
de: Vermeiden Sie das Exportieren von Variablen als öffentliche API, da dies auf einigen Plattformen umständlich ist. Fügen Sie stattdessen Getter und Setter hinzu. Vermeiden Sie generell globale Variablen.

note: (itstool) path: section/p
en: Non-exported functions that are needed in more than one source file should be prefixed with an underscore (‘_’), and declared in a private header file. For example, <code>_mylib_internal_foo()</code>.
de: Nicht exportierten Funktionen, die in mehr als einer Quelldatei benötigt werden, sollte ein Unterstrich (_) vorangestellt und diese in der privaten Header-Datei deklariert werden. Zum Beispiel <code>_mylib_internal_foo()</code>.

note: (itstool) path: section/p
en: Underscore-prefixed functions are never exported.
de: Funktionen mit vorangestelltem Unterstrich werden niemals exportiert.

note: (itstool) path: section/p
en: Non-exported functions that are only needed in one source file should be declared static.
de: Nicht-exportierte Funktionen, die nur in einer Quelldatei benötigt werden, sollten als statisch deklariert werden.

note: (itstool) path: license/p
en: This work is licensed under a <_:link-1/>.
de: Dieses Werk ist unter der <_:link-1/> lizensiert.

note: (itstool) path: license/p
en: As a special exception, the copyright holders give you permission to copy, modify, and distribute the example code contained in this document under the terms of your choosing, without restriction.
de: Als besondere Ausnahme gewähren die Inhaber des Urheberrechts die Erlaubnis, den Beispiel-Code in diesem Dokument ohne Einschränkungen unter den Bedingungen Ihrer Wahl zu kopieren, zu verändern und weiterzugeben.

note: (itstool) path: page/title
en: Databases
de: Datenbanken

note: (itstool) path: item/p
en: Use databases for appropriate use cases: not configuration data (use GSettings). (<link xref="#when-to-use-databases"/>)
de: Verwenden Sie Datenbanken für die entsprechenden Anwendungsfälle: Nicht für Konfigurationsdaten (verwenden Sie dann GSettings). (<link xref="#when-to-use-databases"/>)

note: (itstool) path: item/p
en: Choose between GOM and GVDB based on whether indexing is required. (<link xref="#when-to-use-databases"/>)
de: Wählen Sie zwischen GOM und GVDB, abhängig davon, ob Indizierung erforderlich ist (<link xref="#when-to-use-databases"/>).

note: (itstool) path: section/title
en: When to Use Databases
de: Anwendungsfälle für Datenbanken

note: (itstool) path: section/p
en: GOM should be used if you need advanced features, especially indexing. GVDB should be used otherwise.
de: GOM sollte verwendet werden, wenn Sie erweiterte Funktionsmerkmale benötigen, insbesondere Indizierung. Anderenfalls verwenden Sie GVDB.

note: (itstool) path: section/title
en: Using GOM
de: Verwendung von GOM

note: (itstool) path: section/p
en: Providing a GOM tutorial is beyond the scope of this document, but a <link href="https://developer.gnome.org/gom/">reference manual is available</link>.
de: Die Bereitstellung eines GOM-Tutorials würde den Rahmen dieses Dokuments sprengen, aber ein <link href="https://developer.gnome.org/gom/">Referenzhandbuch ist verfügbar</link>.

note: (itstool) path: section/title
en: SQL Injection
de: SQL-Einschleusung

note: (itstool) path: section/title
en: Using GVDB
de: GVDB verwenden

note: (itstool) path: info/desc
en: Adding documentation to libraries and APIs
de: Dokumentation zu Bibliotheken und APIs hinzufügen

note: (itstool) path: page/title (itstool) path: section/title
en: Documentation
de: Dokumentation

note: (itstool) path: item/p
en: Use gtk-doc with up-to-date settings for API documentation. (<link xref="#gtk-doc"/>)
de: Verwenden Sie gtk-doc mit aktuellen Einstellungen für API-Dokumentation. (<link xref="#gtk-doc"/>)

note: (itstool) path: item/p
en: Enable gtk-doc tests. (<link xref="#keeping-up-to-date"/>)
de: Test mit gtk-doc aktivieren. (<link xref="#keeping-up-to-date"/>)

note: (itstool) path: section/p
en: The preferred documentation system for GNOME libraries is <link href="http://www.gtk.org/gtk-doc/">gtk-doc</link>, which extracts inline comments from the code to let you build a <link href="http://docbook.org/">DocBook</link> document and collection of HTML pages. These can then be read in <link href="https://wiki.gnome.org/Apps/Devhelp">Devhelp</link>. A lot of GNOME’s infrastructure is built to handle with documentation written using gtk-doc.
de: Das bevorzugte Dokumentationssystem für GNOME-Bibliotheken ist <link href="http://www.gtk.org/gtk-doc/">gtk-doc</link>, welches eingebettete Kommentare aus dem Code entpackt und daraus ein <link href="http://docbook.org/">DocBook</link>-Dokument und HTML-Seiten erstellen kann. Diese können in <link href="https://wiki.gnome.org/Apps/Devhelp">Devhelp</link> gelesen werden. Ein großer Teil der Infrastruktur von GNOME ist darauf ausgelegt, mit Dokumentation umzugehen, die mit gtk-doc erstellt wurde.

note: (itstool) path: section/title
en: Build System
de: Build-System

note: (itstool) path: section/p
en: If the package version is needed to be substituted into the documentation, create a file named <file>docs/version.xml.in</file>, containing:
de: Falls es nötig ist, die Paketversion in der Dokumentation anzupassen, erstellen Sie eine Datei namens <file>docs/version.xml.in</file>, die Folgendes enthält:

note: (itstool) path: section/p
en: Add it to <code>AC_CONFIG_FILES</code> in <file>configure.ac</file>, then include it into the main documentation file (<file>*-docs.xml</file>) using: <code>&lt;!ENTITY version SYSTEM "version.xml"&gt;</code> in the <code>DOCTYPE</code> at the top of the document. The package version can then be used inline as <code>&amp;version;</code>.
de: Fügen Sie sie zu <code>AC_CONFIG_FILES</code> in <file>configure.ac</file> hinzu und schließen Sie sie folgendermaßen in die Haupt-Dokumentationsdatei (<file>*-docs.xml</file>) ein: <code>&lt;!ENTITY version SYSTEM "version.xml"&gt;</code> in the <code>DOCTYPE</code> am Anfang des Dokuments. Die Paketversion kann dann als <code>&amp;version;</code> in den Text eingebettet werden.

note: (itstool) path: section/title
en: Standard Layout
de: Standard-Layout

note: (itstool) path: section/p
en: Using a standard layout for the table of contents, sections, appendices, etc. means the same <file><var>project-name</var>-docs.xml</file> template can be reused with few changes between projects. It also means the documentation layout is similar across all projects, making it more familiar to developers.
de: Wenn Sie ein Standard-Layout für das Inhaltsverzeichnis, die Abschnitte, Anhänge usw. verwenden, können Sie die gleiche <file><var>Projektname</var>-docs.xml</file>-Vorlage mit wenigen Änderungen für andere Projekte verwenden. Es hat auch den Effekt, dass das Dokumentationslayout über Projektgrenzen hinweg gleich ist und dadurch den Entwicklern mehr vertraut ist.

note: (itstool) path: section/p
en: The following layout is suggested:
de: Das folgende Layout ist zu empfehlen:

note: (itstool) path: listing/title
en: <file><var>project-name</var>-docs.xml</file>
de: <file><var>Projektname</var>-docs.xml</file>

note: (itstool) path: listing/desc
en: A template top-level gtk-doc file for a project
de: Vorlage für eine gtk-doc-Datei der obersten Ebene

note: (itstool) path: section/title
en: Licensing
de: Lizenzierung

note: (itstool) path: section/p
en: It is important to make the license used for API references clear, especially if they contain code examples which could be copied around.
de: Es ist wichtig, die für die API-Referenzen verwendete Lizenz klar zu stellen, insbesondere dann, wenn der Code Beispiele enthält, die frei kopiert werden dürfen.

note: (itstool) path: section/p
en: Typically, projects use the same license for their API reference as for the project’s code itself, to avoid confusion. Some other projects use CC-BY-SA 3.0 for all their reference documentation. The choice is yours.
de: Typischerweise verwenden Projekte meist die gleiche Lizenz für ihre API-Referenzen wie für den Projektcode selbst, um Verwirrung zu vermeiden. Andere Projekte verwenden CC-BY-SA 3.0 für sämtliche Referenzdokumentation. Die Wahl liegt bei Ihnen.

note: (itstool) path: section/title
en: Public APIs
de: Öffentliche APIs

note: (itstool) path: section/p
en: All public APIs must have gtk-doc comments. For functions, these should be placed in the source file, directly above the function.
de: Alle öffentlichen APIS müssen gtk-doc-Kommentare haben. Für Funktionen sollten diese in der Quelldatei direkt über der Funktion platziert werden.

note: (itstool) path: section/p
en: Instead of:
de: Anstelle von:

note: (itstool) path: section/title
en: Symbol Versioning
de: Symbol-Versionierung

note: (itstool) path: section/p (itstool) path: example/p
en: For example:
de: Zum Beispiel:

note: (itstool) path: section/title
en: D-Bus APIs
de: D-Bus-APIs

note: (itstool) path: section/p
en: The DocBook files can be included in the main <file>*-docs.xml</file> file using:
de: Die DocBook-Dateien können folgendermaßen in die Datei <file>*-docs.xml</file> eingeschlossen werden:

note: (itstool) path: section/title
en: Keeping Documentation Up to Date
de: Dekumentation aktuell halten

note: (itstool) path: section/p
en: These tests should always be enabled, by adding the following to your gtk-doc <file>Makefile.am</file>:
de: Diese Tests sollten immer aktiviert werden. Fügen Sie Folgendes zu <file>Makefile.am</file> für gtk-doc hinzu:

note: (itstool) path: section/p
en: They will then be run as part of <cmd>make check</cmd>.
de: Die Tests werden dann innerhalb von <cmd>make check</cmd> ausgeführt.

note: (itstool) path: info/desc
en: Accessing the file system
de: Zugriff auf das Dateisystem

note: (itstool) path: page/title
en: File System Access
de: Dateisystemzugriff

note: (itstool) path: item/p
en: Use asynchronous I/O for file access. (<link xref="#asynchronous-io"/>)
de: Verwenden Sie asynchrone Ein-/Ausgaben für den Dateizugriff. (<link xref="#asynchronous-io"/>)

note: (itstool) path: item/p
en: Always use appropriate functions to construct file names and paths. (<link xref="#file-path-construction"/>)
de: Verwenden Sie stets entsprechende Funktionen, um Dateinamen und Pfade zu konstruieren. (<link xref="#file-path-construction"/>)

note: (itstool) path: item/p
en: Validate file paths are in the expected directories before using them. (<link xref="#path-validation-and-sandboxing"/>)
de: Überprüfen Sie Dateipfade in den erwarteten Ordnern, bevor Sie sie verwenden. (<link xref="#path-validation-and-sandboxing"/>)

note: (itstool) path: item/p
en: Use mandatory access control profiles to enforce constraints on file access. (<link xref="#path-validation-and-sandboxing"/>)
de: Verwenden Sie obligatorische Zugriffskontrollprofile, um Beschränkungen für den Dateizugriff zu erzwingen. (<link xref="#path-validation-and-sandboxing"/>)

note: (itstool) path: section/title
en: Asynchronous I/O
de: Asynchrone Ein-/Ausgaben

note: (itstool) path: section/p
en: Files in the user’s home directory do <em>not</em> count as local, as they could be on a networked file system.
de: Dateien im persönlichen Ordner des Benutzers gelten <em>nicht</em> als lokal, da sie sich auf einem Netzwerk-Dateisystem befinden könnten.

note: (itstool) path: section/title
en: File Path Construction
de: Konstruktion von Dateipfaden

note: (itstool) path: section/title
en: Path Validation and Sandboxing
de: Pfad-Validierung und Sandboxing

note: (itstool) path: info/desc
en: Runtime error handling and reporting
de: Umgang mit und Melden von Laufzeitfehlern

note: (itstool) path: section/title
en: GError Usage
de: Verwendung von GError

note: (itstool) path: section/p
en: The GLib API documentation contains a <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#glib-Error-Reporting.description">full tutorial for using GError</link>.
de: Die GLib-API-Dokumentation enthält ein <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#glib-Error-Reporting.description">vollständiges Tutorial zur Verwendung von GError</link>.

note: (itstool) path: info/desc
en: Linked lists and container types
de: Verknüpfte Listen und Containertypen

note: (itstool) path: section/title
en: GList Usage
de: Verwendung von GList

note: (itstool) path: info/desc (itstool) path: page/title
en: GNOME Programming Guidelines
de: GNOME Programmierungsrichtlinien

[ctx: link:trail]
note: (itstool) path: info/title
en: Programming Guidelines
de: Programmierrichtlinien

note: (itstool) path: page/p
en: This article contains several guidelines and suggestions for programmers working in and with the GNOME stack. This is intended for programmers to know about the development processes, conventions and philosophies behind GNOME applications and the stack of libraries supporting them. By knowing “the way things are done” in the GNOME ecosystem, it is hoped that programmers will find use of GNOME APIs and development of new applications easier and more natural, and will produce code which is legible and maintainable over a long period of time by a diverse team of programmers.
de: Dieser Artikel enthält einige Richtlinien und Vorschläge für Programmierer, die im und mit dem GNOME-Stack arbeiten. Ziel ist es, Entwickler mit den Prozessen, Konventionen und Philosophien hinter den GNOME-Anwendungen und den zugehörigen Bibliotheken vertraut zu machen. Die Hoffnung ist, dass Programmierer, die wissen »wie Dinge hier funktionieren« im GNOME-Ökosystem, sich besser mit den GNOME-APIs auseinandersetzen und neue Anwendungen entwickeln können, und damit letztlich lesbaren Code schreiben, der über lange Zeit von einem diversen Team an Programmierern verwaltet werden kann.

note: (itstool) path: page/p
en: This guide has a two-fold purpose:
de: Diese Richtlinie verfolgt zweierlei Zweck:

note: (itstool) path: item/p
en: To give you good suggestions on how to write code for GNOME or using GNOME technologies. This will help you write code that is consistent with best practices, and that will be accepted by the community. This will also lead to code that is a pleasure to work on.
de: Wir wollen Ihnen praxisgerechte Empfehlungen für die Programmierung für GNOME oder mittels GNOME-Technologien geben. Dies wird Ihnen helfen, konsistenten Code zu schreiben, der von der Gemeinschaft akzeptiert wird. Als Nebeneffekt wird Ihnen die Programmierung so auch mehr Spaß machen.

note: (itstool) path: item/p
en: To transmit the knowledge we have gotten over the years on how to keep the GNOME project sustainable, even when people’s contributions increase or decrease.
de: Wir wollen unser über die Jahre gewonnenes Wissen weitervermitteln, wie das GNOME-Projekt nachhaltig geführt wird, auch wenn die Beiträge der Mitwirkenden schwanken.

[ctx: link:trail]
note: (itstool) path: info/title
en: General Guidelines
de: Allgemeine Richtlinien

note: (itstool) path: section/title
en: General Guidelines
de: Allgemeine Richtlinien

[ctx: link:trail]
note: (itstool) path: info/title
en: Maintainer Guidelines
de: Maintainer-Richtlinien

note: (itstool) path: section/title
en: Maintainer Guidelines
de: Maintainer-Richtlinien

[ctx: link:trail]
note: (itstool) path: info/title
en: Specific How-Tos
de: Spezifische How-Tos

note: (itstool) path: section/title
en: Specific How-Tos
de: Spezifische How-Tos

[ctx: link:trail]
note: (itstool) path: info/title
en: References
de: Referenzen

note: (itstool) path: section/title
en: References
de: Referenzen

note: (itstool) path: section/title
en: API Design
de: API-Design

note: (itstool) path: info/desc
en: Logging debug and information output from libraries and programs
de: Protokollierung von Debugging- und Informationsausgaben von Bibliotheken und Programmen

note: (itstool) path: page/title
en: Logging
de: Protokollierung

note: (itstool) path: item/p
en: Use the GLib logging framework instead of logging directly to stderr and stdout. (<link xref="#glib-logging-framework"/>)
de: Verwenden Sie das Protokollierungs-Framework aus GLib, anstatt direkt in stderr und stdout zu schreiben (<link xref="#glib-logging-framework"/>).

note: (itstool) path: item/p
en: If systemd can be a dependency of the project, consider logging directly to the journal. (<link xref="#journald-integration"/>)
de: Wenn Systemd eine Abhängigkeit des Projekts sein kann, dann sollten Sie erwägen, direkt in dessen Journal zu protokollieren (<link xref="#journald-integration"/>).

note: (itstool) path: item/p
en: Do not implement log rotation and deletion; leave that to system services. (<link xref="#log-rotation"/>)
de: Implementieren Sie keine Protokollumwälzung und -löschung; überlassen Sie dies den Systemd-Diensten (<link xref="#log-rotation"/>).

note: (itstool) path: section/title
en: GLib Logging Framework
de: Protokollierungs-Framework aus GLib

note: (itstool) path: section/title
en: Exceptions
de: Ausnahmen

note: (itstool) path: section/title
en: journald Integration
de: journald-Integration

note: (itstool) path: section/p
en: For more information, see this <link href="http://0pointer.de/blog/projects/journal-submit.html">article on logging to the journal</link>.
de: Weitere Informationen finden Sie in diesem <link href="http://0pointer.de/blog/projects/journal-submit.html">Artikel zur Protokollierung in das Journal</link>.

note: (itstool) path: section/title
en: Log Rotation
de: Protokollumwälzung

note: (itstool) path: section/title
en: What is <code>GMainContext</code>?
de: Was ist <code>GMainContext</code>?

note: (itstool) path: section/title
en: What is <code>GMainLoop</code>?
de: Was ist <code>GMainLoop</code>?

note: (itstool) path: td/p
en: Do not use
de: Verwenden sie nicht

note: (itstool) path: td/p
en: Use instead
de: sondern stattdessen

note: (itstool) path: section/title
en: Using <code>GMainContext</code> in a Library
de: Verwendung von <code>GMainContext</code> in einer Bibliothek

note: (itstool) path: section/title
en: Principles of Invocation
de: Aufrufprinzipien

note: (itstool) path: example/p
en: For example, instead of using the following when emitting a signal:
de: Zum Beispiel kann anstelle des Folgenden zum Senden eines Signals …

note: (itstool) path: example/code
en: 
    guint param1;  /* arbitrary example parameters */
    gchar *param2;
    guint retval = 0;
    
    g_signal_emit_by_name (my_object, "some-signal",
                           param1, param2, &amp;retval);
de: 
    guint param1;  /* willkürliche Beispielparameter */
    gchar *param2;
    guint retval = 0;
    
    g_signal_emit_by_name (my_object, "irgendein-Signal",
                           param1, param2, &amp;retval);

note: (itstool) path: example/p
en: The following can be used:
de: … Folgendes verwendet werden:

note: (itstool) path: example/code
en: 
    static guint
    emit_some_signal (GObject     *my_object,
                      guint        param1,
                      const gchar *param2)
    {
      guint retval = 0;
    
      g_assert (g_main_context_is_owner (expected_main_context));
    
      g_signal_emit_by_name (my_object, "some-signal",
                             param1, param2, &amp;retval);
    
      return retval;
    }
de: 
    static guint
    emit_some_signal (GObject     *my_object,
                      guint        param1,
                      const gchar *param2)
    {
      guint retval = 0;
    
      g_assert (g_main_context_is_owner (expected_main_context));
    
      g_signal_emit_by_name (my_object, "irgendein-Signal",
                             param1, param2, &amp;retval);
    
      return retval;
    }

note: (itstool) path: page/title
en: Memory Management
de: Speicherverwaltung

note: (itstool) path: synopsis/p
en: Key principles, in no particular order:
de: Schlüsselprinzipien, nicht in bestimmter Reihenfolge:

note: (itstool) path: section/title
en: Principles of Memory Management
de: Prinzipien der Speicherverwaltung

note: (itstool) path: td/p
en: Function name
de: Funktionsname

note: (itstool) path: td/p
en: Convention 1 (standard)
de: Konvention 1 (Standard)

note: (itstool) path: td/p
en: Convention 2 (alternate)
de: Konvention 2 (alternativ)

note: (itstool) path: td/p
en: Convention 3 (<cmd>gdbus-codegen</cmd>)
de: Konvention 3 (<cmd>gdbus-codegen</cmd>)

note: (itstool) path: td/p
en: No transfer
de: Keine Übertragung

note: (itstool) path: td/p
en: Any transfer
de: Jede Übertragung

note: (itstool) path: td/p
en: Full transfer
de: Vollständige Übertragung

note: (itstool) path: td/p
en: Unused
de: Nicht verwendet

note: (itstool) path: td/p
en: set
de: gesetzt

note: (itstool) path: section/title
en: Assignments
de: Zuweisungen

note: (itstool) path: td/p
en: Assignment from/to
de: Zuweisungen von/nach

note: (itstool) path: td/p
en: Pure assignment.
de: Reine Zuweisung.

note: (itstool) path: section/title
en: Function Calls
de: Funktionsaufrufe

note: (itstool) path: td/p
en: Call from/to
de: Aufruf von/nach

note: (itstool) path: td/p
en: Transfer full parameter
de: Übertragen des vollständigen Parameters

note: (itstool) path: td/p
en: Transfer none parameter
de: Keine Parameter übertragen

note: (itstool) path: td/p
en: Copy or move the source for the parameter.
de: Kopieren oder verschieben Sie die Quelle für den Parameter.

note: (itstool) path: td/p
en: Pure parameter passing.
de: Reine Parameterübergabe.

note: (itstool) path: td/p
en: Copy the source for the parameter.
de: Kopieren Sie die Quelle für den Parameter.

note: (itstool) path: section/title
en: Function Returns
de: Funktionsrückgaben

note: (itstool) path: td/p
en: Return from/to
de: Rückkehr von/nach

note: (itstool) path: td/p
en: Transfer full return
de: Transfer-Vollrückgabe

note: (itstool) path: td/p
en: Transfer none return
de: Transfer keine Rückgabe

note: (itstool) path: td/p
en: Pure variable return.
de: Reine Variabelnrückgabe.

note: (itstool) path: td/p
en: Invalid. The source needs to be freed, so the return value would use freed memory — a use-after-free error.
de: Ungültig. Die Quelle muss freigegeben werden, so dass der Rückgabewert den freigegebenen Speicher verwenden würde – ein use-after-free-Fehler.

note: (itstool) path: td/p
en: Copy the source for the return.
de: Kopieren Sie die Quelle für die Rückgabe.

note: (itstool) path: td/code
en: return copy (unowned_src)
de: Kopie zurückgeben (unowned_src)

note: (itstool) path: td/p
en: Pure variable passing.
de: Reine Variabelnweitergabe.

note: (itstool) path: section/title
en: Reference Counting
de: Referenzenzählung

note: (itstool) path: section/p
en: A similar function exists for <code>GPtrArray</code>: <link href="https://developer.gnome.org/glib/stable/glib-Pointer-Arrays.html#g-ptr-array-new-with-free-func"> <code>g_ptr_array_new_with_free_func()</code></link>.
de: Eine ähnliche Funktion existiert für <code>GPtrArray</code>: <link href="https://developer.gnome.org/glib/stable/glib-Pointer-Arrays.html#g-ptr-array-new-with-free-func"> <code>g_ptr_array_new_with_free_func()</code></link>.

note: (itstool) path: section/title
en: Container Types
de: Containertypen

note: (itstool) path: section/title
en: Verification
de: Überprüfung

note: (itstool) path: section/p
en: See <link xref="tooling#valgrind"/> for more information on using Valgrind.
de: Weitere Informationen zur Nutzung von Valgrind finden Sie in <link xref="tooling#valgrind"/>.

note: (itstool) path: info/desc
en: Avoiding symbol conflicts between libraries by namespacing all APIs
de: Vermeiden von Symbolkonflikten zwischen Bibliotheken durch Namensunterschied aller APIs

note: (itstool) path: page/title
en: Namespacing
de: Namensräume

note: (itstool) path: section/title
en: GObject APIs
de: GObject-APIs

note: (itstool) path: item/p
en: Functions should use <code>lower_case_with_underscores</code>.
de: Funktionen sollten <code>kleinschreibung_mit_unterstrichen</code> verwenden.

note: (itstool) path: item/p
en: Structures, types and objects should use <code>CamelCaseWithoutUnderscores</code>.
de: Strukturen, Typen und Objekte sollten <code>SchreibungMitBinnenmajuskelnOhneUnterstriche</code> verwenden.

note: (itstool) path: item/p
en: Macros and constants should use <code>UPPER_CASE_WITH_UNDERSCORES</code>.
de: Makros und Konstanten sollten <code>GROSSSCHREIBUNG_MIT_UNTERSTRICHEN</code> verwenden.

note: (itstool) path: item/p
en: All methods of a class should also be prefixed with the class name.
de: Allen Methoden einer Klasse sollte der Klassenname vorangestellt sein.

note: (itstool) path: item/p
en: <code>WblSchema</code> structure
de: <code>WblSchema</code>-Struktur

note: (itstool) path: item/p
en: <code>WblSchemaClass</code> structure
de: <code>WblSchemaClass</code>-Struktur

note: (itstool) path: item/p
en: <code>WBL_TYPE_SCHEMA</code> macro
de: <code>WBL_TYPE_SCHEMA</code>-Makro

note: (itstool) path: item/p
en: <code>WBL_IS_SCHEMA</code> macro
de: <code>WBL_IS_SCHEMA</code>-Makro

note: (itstool) path: item/p
en: <code>wbl_schema_get_type</code> function
de: <code>wbl_schema_get_type</code>-Funktion

note: (itstool) path: item/p
en: <code>wbl_schema_new</code> function
de: <code>wbl_schema_new</code>-Funktion

note: (itstool) path: item/p
en: <code>wbl_schema_load_from_data</code> function
de: <code>wbl_schema_load_from_data</code>-Funktion

note: (itstool) path: page/title
en: Parallel Installability
de: Parallele Installierbarkeit

note: (itstool) path: synopsis/p
en: If two packages can be parallel installed, then they have no filenames in common, and people developing against the package always compile against the version they expected. This applies to daemons, utility programs and configuration files as it does to header files and library binaries.
de: Wenn zwei Pakete parallel installiert werden, haben Sie keine gemeinsamen Dateinamen, und Entwickler, die auf dem Paket aufbauen, kompilieren stets gegen die erwartete Version. Dies gilt auch für Daemons, Dienstprogramme und Konfigurationsdateien sowie Header-Dateien und Bibliothek-Binärdateien.

note: (itstool) path: item/p
en: Ensure all versions of a library are parallel installable. (<link xref="#justification"/>)
de: Stellen Sie sicher, dass alle Versionen einer Bibliothek parallel installierbar sind. (<link xref="#justification"/>)

note: (itstool) path: item/p
en: Version all files installed by a library. (<link xref="#solution"/>)
de: Versionieren Sie alle Dateien, die von einer Bibliothek installiert werden. (<link xref="#solution"/>)

note: (itstool) path: item/p
en: Keep package version numbers separate from soname or libtool version numbers. Be clear which part of the package version number changes with the API. (<link xref="#version-numbers"/>)
de: Definieren Sie die Paketversionsnummer separat vom Sonamen oder der libtool-Versionsnummer. Seien Sie sich bewusst, welcher Teil der Paketversionsnummer sich mit der API ändert. (<link xref="#version-numbers"/>)

note: (itstool) path: item/p
en: Install C header files to <file><var>$(includedir)</var>/lib<var>library</var>-<var>version</var>/<var>library</var>/</file>. (<link xref="#header-files"/>)
de: Installieren Sie C-Header-Dateien in <file><var>$(includedir)</var>/lib<var>Bibliothek</var>-<var>Version</var>/<var>Bibliothek</var>/</file>. (<link xref="#header-files"/>)

note: (itstool) path: item/p
en: Install library binaries to <file><var>$(libdir)</var>/lib<var>library</var>-<var>version</var>.so.<var>soname</var></file>. (<link xref="#libraries"/>)
de: Installieren Sie Bibliothek-Binärdateien in <file><var>$(libdir)</var>/lib<var>library</var>-<var>version</var>.so.<var>soname</var></file>. (<link xref="#libraries"/>)

note: (itstool) path: item/p
en: Install pkg-config files to <file><var>$(libdir)</var>/pkgconfig/<var>library</var>-<var>version</var>.pc</file>. (<link xref="#pkg-config"/>)
de: Installieren Sie pkg-config-Dateien in <file><var>$(libdir)</var>/pkgconfig/<var>Bibliothek</var>-<var>Version</var>.pc</file>. (<link xref="#pkg-config"/>)

note: (itstool) path: item/p
en: Make configuration files forwards and backwards compatible, or install them to <file><var>$(sysconfdir)</var>/<var>library</var>-<var>version</var>/</file>. (<link xref="#configuration-files"/>)
de: Sorgen Sie dafür, dass Konfigurationsdateien aufwärts- und abwärtskompatibel sind oder installieren Sie sie in <file><var>$(sysconfdir)</var>/<var>Bibliothek</var>-<var>Version</var>/</file>. (<link xref="#configuration-files"/>)

note: (itstool) path: item/p
en: Set <code>GETTEXT_PACKAGE</code> to <code><var>library</var>-<var>version</var></code>. (<link xref="#gettext"/>)
de: Setzen Sie <code>GETTEXT_PACKAGE</code> auf <code><var>Bibliothek</var>-<var>Version</var></code>. (<link xref="#gettext"/>)

note: (itstool) path: item/p
en: Include a version number in all D-Bus interface names, service names and object paths. For example: <code>org.domain.<var>Library</var><var>Version</var>.<var>Interface</var></code>, <code>org.domain.<var>Library</var><var>Version</var></code> and <code>/org/domain/<var>Library</var><var>Version</var>/</code>. (<link xref="#dbus"/>)
de: Schließen Sie eine Versionsnummer in alle D-Bus-Schnittstellennamen, Dienstnamen und Objektpfade ein. Zum Beispiel: <code>org.domain.<var>Library</var><var>Version</var>.<var>Interface</var></code>, <code>org.domain.<var>Library</var><var>Version</var></code> und <code>/org/domain/<var>Library</var><var>Version</var>/</code>. (<link xref="#dbus"/>)

note: (itstool) path: item/p
en: Install daemon binaries to <file><var>$(libexecdir)</var>/<var>library</var>-daemon-<var>version</var></file>. (<link xref="#programs"/>)
de: Installieren Sie Daemon-Binaries in <file><var>$(libexecdir)</var>/<var>Bibliothek</var>-daemon-<var>Version</var></file>. (<link xref="#programs"/>)

note: (itstool) path: item/p
en: Install utility binaries to <file><var>$(bindir)</var>/<var>library</var>-utility-<var>version</var></file> and install symbolic links to <file><var>$(bindir)</var>/<var>library</var>-utility</file>. (<link xref="#programs"/>)
de: Installieren Sie Hilfs-Binärdateien in <file><var>$(bindir)</var>/<var>library</var>-utility-<var>version</var></file> und platzieren Sie symbolische Links in <file><var>$(bindir)</var>/<var>library</var>-utility</file>. (<link xref="#programs"/>)

note: (itstool) path: section/title
en: Justification
de: Begründung

note: (itstool) path: section/p
en: All public libraries should be designed to be parallel installed to ease API breaks later in the life of the library. If a library is used by multiple projects, and wants to break API, either all of the projects must be ported to the new API in parallel, or some of them will no longer be installable at the same time as the others, due to depending on conflicting versions of this library.
de: Alle öffentlichen Bibliotheken sollten so entworfen sein, dass sie parallel installiert werden können, damit eventuelle spätere API-Inkompatibilitäten leichter abgefangen werden können. Wenn eine Bibliothek von mehreren Projekten verwendet wird und eine inkompatible Änderung an der API einführt, müssen alle Projekte zeitgleich auf die neue API migrieren, da sie sonst aufgrund der unterschiedlichen Versionsabhängigkeiten nicht länger gemeinsam installierbar sind.

note: (itstool) path: section/p
en: This is unmaintainable, and asking all the projects to port to a new API at the same time is hard to organize and demoralizing, as most API breaks do not bring large new features which would motivate porting.
de: Das ist aus Betriebssicht nicht vertretbar. Außerdem ist die Anforderung, dass alle Projekte unmittelbar auf die neue API portieren müssen, schwer zu organisieren und dürfte zu Unmut führen, da die meisten API-Änderungen keinen großen neuen Funktionen einführen, die eine Portierung motivieren würden.

note: (itstool) path: section/p
en: The solution is to ensure that all libraries are parallel installable, allowing the old and new versions of the API to be installed and compiled against at the same time, without conflicts. Building in support for this kind of parallel installation is much easier to do at the start of a project than it is to do retroactively.
de: Die Lösung ist daher, dass alle Bibliotheken parallel installierbar sein müssen: alte und neue Versionen der API müssen ohne Konflikte gleichzeitig installiert und gegeneinander kompiliert sein. Es ist deutlich einfacher, dieses System von paralleler Installierbarkeit von Beginn an zu unterstützen, als es später nachträglich einzuführen.

note: (itstool) path: section/p
en: This eliminates the ‘chicken and egg’ problem of porting a collection of applications from one version of a library to the next, and makes breaking API a lot simpler for library maintainers, which can allow for more rapid iteration and development of new features if they desire.
de: Es eliminiert das »Henne und Ei«-Problem, eine Reihe an Anwendungen von einer Bibliotheksversion auf die nächste zu portieren und erlaubt es den Maintainern von Bibliotheken, API-Änderungen einfacher einzuführen, wodurch schlussendlich schnellere Iterationen und Entwicklungsprozesse ermöglicht werden.

note: (itstool) path: section/p
en: The alternative, and equally valid, solution is for the library to never break API — the approach taken by <code>libc</code>.
de: Eine ebenfalls valide Alternative hierzu ist, dass die Bibliothek niemals API-Inkompatibilitäten einführt. Dieser Ansatz wird von <code>libc</code> verfolgt.

note: (itstool) path: section/title
en: Solution
de: Lösung

note: (itstool) path: section/p
en: The solution to the problem is essentially to rename the library, and in most cases the nicest way to do so is to include the version number in the path of every file it installs. This means multiple versions of the library can be installed at the same time.
de: Die Lösung für dieses Problem besteht im Prinzip darin, die Bibliothek umzubenennen. In den meisten Fällen ist es hier am einfachsten, die Versionsnummer in den Pfad jeder installierten Datei einzubinden. Dadurch können mehrere Versionen der Bibliothek gleichzeitig installiert sein.

note: (itstool) path: section/p
en: For example, say that library <code>Foo</code> traditionally installs these files:
de: Nehmen wir an, die Bibliothek <code>Foo</code> installiert traditionell diese Dateien:

note: (itstool) path: section/p
en: You might modify <code>Foo</code> version 4 to install these files instead:
de: Nun können Sie Version 4 von <code>Foo</code> so anpassen, dass sie stattdessen diese Dateien installiert:

note: (itstool) path: section/p
en: It could then be parallel installed with version 5:
de: Es kann dann parallel mit Version 5 installiert werden:

note: (itstool) path: section/p
en: This is easily supported using <link href="http://www.freedesktop.org/wiki/Software/pkg-config/"> <cmd>pkg-config</cmd></link>: <file>foo-4.pc</file> would add <file>/usr/include/foo-4</file> to the include path and <file>libfoo-4.so</file> to the list of libraries to link; <file>foo-5.pc</file> would add <file>/usr/include/foo-5</file> and <file>libfoo-5.so</file>.
de: Sie können dieses Verhalten mit <link href="http://www.freedesktop.org/wiki/Software/pkg-config/"> <cmd>pkg-config</cmd></link> umsetzen: <file>foo-4.pc</file> würde <file>/usr/include/foo-4</file> in den include-Pfad und <file>libfoo-4.so</file> zu der Bibliothekenliste hinzufügen; <file>foo-5.pc</file> würde <file>/usr/include/foo-5</file> und <file>libfoo-5.so</file> hinzufügen.

note: (itstool) path: section/title
en: Version Numbers
de: Versionsnummern

note: (itstool) path: section/p
en: The version number that goes in filenames is an <em>ABI/API</em> version. It should not be the full version number of your package — just the part which signifies an API break. If using the standard <code><var>major</var>.<var>minor</var>.<var>micro</var></code> scheme for project versioning, the API version is typically the major version number.
de: Die Versionsnummer in den Dateipfaden ist eine <em>ABI/API</em>-Version. Es sollte sich nicht um die vollständige Versionsnummer Ihres Pakets handeln, sondern nur um den Teil, der die API-Kompatibilität angibt. Wenn Sie das Standard-Schema <code><var>major</var>.<var>minor</var>.<var>micro</var></code> für Ihre Projektversionierung verwenden, wird die API-Version typischerweise durch die Major-Versionsnummer angegeben.

note: (itstool) path: section/p
en: Minor releases (typically where API is added but <em>not</em> changed or removed) and micro releases (typically bug fixes) do not affect <link xref="api-stability">API backwards compatibility</link> so do not require moving all the files.
de: Minor-Veröffentlichungen (bei denen für gewöhnlich APIs hinzugefügt, aber <em>nicht</em> verändert oder entfernt werden) sowie Micro-Veröffentlichungen (für gewöhnlich Fehlerbehebungen) betreffen nicht die <link xref="api-stability">API-Abwärtskompatibilität</link> und erfordern daher nicht, dass alle Dateien verschoben werden.

note: (itstool) path: section/p
en: The examples in the following sections assume that the API version and soname are exported from <file>configure.ac</file> using the following code:
de: Die Beispiele in den nachfolgenden Abschnitten gehen davon aus, dass die API-Version und der Soname mit dem folgenden Code aus der <file>configure.ac</file> entnommen werden:

note: (itstool) path: listing/title
en: API Versioning in Autoconf
de: API-Versionierung in Autoconf

note: (itstool) path: listing/desc
en: Code to export the API version and soname from <file>configure.ac</file>
de: Code zum Exportieren der API-Version und soname aus <file>configure.ac</file>

note: (itstool) path: section/title
en: C Header Files
de: C-Headerdateien

note: (itstool) path: section/p
en: Header files should always be installed in a versioned subdirectory that requires an <cmd>-I</cmd> flag to the C compiler. For example, if my header is <file>foo.h</file>, and applications do this:
de: Header-Dateien sollten immer in einen versionierten Unterordner installiert werden, der eine <cmd>-I</cmd>-Flag an den C-Compiler erfordert. Wenn zum Beispiel Ihr Header <file>foo.h</file> heißt und Ihre Anwendungen Folgendes tun:

note: (itstool) path: section/p
en: then I should install these files:
de: dann sollten Sie diese Dateien installieren:

note: (itstool) path: section/p
en: Applications should pass the flag <cmd>-I/usr/include/foo-4</cmd> or <cmd>-I/usr/include/foo-5</cmd> to the C compiler. Again, this is facilitated by using <cmd>pkg-config</cmd>.
de: Anwendungen sollten die Flags <cmd>-I/usr/include/foo-4</cmd> oder <cmd>-I/usr/include/foo-5</cmd> an den Compiler übergeben. Zur Erinnerung: dies wird mittels <cmd>pkg-config</cmd> realisiert.

note: (itstool) path: section/p
en: Note the extra <file>foo/</file> subdirectory. This namespaces the <code mime="text/x-csrc">#include</code> to avoid file naming collisions with other libraries. For example, if two different libraries install headers called <file>utils.h</file>, which one gets included when you use <code mime="text/x-csrc">#include &lt;utils.h&gt;</code>?
de: Beachten Sie den zusätzlichen Unterordner <file>foo/</file>. Dieser legt den Namensraum <code mime="text/x-csrc">#include</code> an, um Dateinamen-Konflikte mit anderen Bibliotheken zu vermeiden. Wenn zum Beispiel zwei verschiedene Bibliotheken Header namens <file>utils.h</file> installieren: welcher wird verwendet, wenn Sie <code mime="text/x-csrc">#include &lt;utils.h&gt;</code> schreiben?

note: (itstool) path: section/p
en: There’s some temptation to keep one of the header files outside of any subdirectory:
de: Es klingt verlockend, eine der Header-Dateien außerhalb eines Unterordners zu platzieren:

note: (itstool) path: section/p
en: The problem there is that users are always accidentally getting the wrong header, since <cmd>-I/usr/include</cmd> seems to find its way onto compile command lines with some regularity. If you must do this, at least add a check to the library that detects applications using the wrong header file when the library is initialized.
de: Das Problem hierbei ist aber, dass Nutzer immer aus Versehen den falschen Header abbekommen, da <cmd>-I/usr/include</cmd> immer mal wieder seinen Weg in die Kompilierungsbefehle findet. Wenn Sie Ihre Header-Dateien dennoch unbedingt so platzieren müssen, sollten Sie in Ihrer Bibliothek wenigstens einen Check hinzufügen, der überprüft, ob Anwendungen bei der Initialisierung der Bibliothek den falschen Header verwenden.

note: (itstool) path: section/p
en: Versioned header files can be installed from automake using the following code:
de: Versionierte Header-Dateien können in automake über den folgenden Code installiert werden:

note: (itstool) path: listing/title
en: Header Files in Automake
de: Header-Dateien in Automake

note: (itstool) path: listing/desc
en: Code to install versioned header files from <file>Makefile.am</file>
de: Code, um versionierte Header-Dateien über <file>Makefile.am</file> zu installieren

note: (itstool) path: section/p
en: As well as correct versioning, all APIs in installed headers should be <link xref="namespacing">namespaced correctly</link>.
de: Zusätzlich zur korrekten Versionierung sollten alle APIs in installierten Header-Dateien die <link xref="namespacing">richtigen Namensräume</link> besitzen.

note: (itstool) path: section/title
en: Libraries
de: Bibliotheken

note: (itstool) path: section/p
en: Library object files should have a versioned name. For example:
de: Bibliothek-Objektdateien sollten einen versionierten Namen besitzen. Zum Beispiel:

note: (itstool) path: section/p
en: This allows applications to get exactly the one they want at compile time, and ensures that versions 4 and 5 have no files in common.
de: Dies erlaubt Anwendungen, die richtige Version zur Kompilierungszeit zu erhalten und stellt sicher, dass die Versionen 4 und 5 keine gemeinsamen Namen besitzen.

note: (itstool) path: section/p
en: Versioned libraries can be built and installed from automake using the following code:
de: Versionierte Bibliotheken können in automake über den folgenden Code gebaut und installiert werden:

note: (itstool) path: listing/title
en: Libraries in Automake
de: Bibliotheken in Automake

note: (itstool) path: listing/desc
en: Code to build and install versioned libraries from <file>Makefile.am</file>
de: Code, um versionierte Bibliotheken über <file>Makefile.am</file> zu bauen und installieren

note: (itstool) path: section/title
en: Library sonames
de: Bibliothek-Sonamen

note: (itstool) path: section/p
en: Library sonames (also known as libtool version numbers) only address the problem of runtime linking previously-compiled applications. They don’t address the issue of compiling applications that require a previous version, and they don’t address anything other than libraries.
de: Bibliothek-Sonamen (auch als libtool-Versionsnummern bekannt) adressieren nur das Problem, dass bereits früher kompilierte Versionen zu Anwendungen verlinkt werden. Sie adressieren nicht das Problem, wenn kompilierende Anwendungen vorherige Versionen benötigen, und betreffen ausschließlich Bibliotheken.

note: (itstool) path: section/p
en: For this reason, sonames should be used, but <em>in addition</em> to versioned names for libraries. The two solutions address different problems.
de: Aus diesem Grund sollten Sonamen zwar verwendet werden, allerdings <em>zusätzlich</em> zu versionierten Bibliotheksnamen. Beide Lösungen gehen unterschiedliche Probleme an.

note: (itstool) path: section/title
en: pkg-config Files
de: pkg-config-Dateien

note: (itstool) path: section/p
en: pkg-config files should have a versioned name. For example:
de: pkg-config-Dateien sollten einen versionierten Namen besitzen. Zum Beispiel:

note: (itstool) path: section/p
en: Since each pkg-config file contains versioned information about the library name and include paths, any project which depends on the library should be able to switch from one version to another simply by changing their pkg-config check from <file>foo-4</file> to <file>foo-5</file> (and doing any necessary API porting).
de: Da jede pkg-config-Datei versionierte Informationen über den Bibliotheksnamen und die include-Pfade enthält, sollte jedes Projekt, das von der Bibliothek abhängt, von einer Version auf die nächste wechseln können, indem sie einfach ihren pkg-config-Check von <file>foo-4</file> auf <file>foo-5</file> ändert (und eventuelle API-Änderungen portiert).

note: (itstool) path: section/p
en: Versioned pkg-config files can be installed from autoconf and automake using the following code:
de: Versionierte pkg-config-Dateien können über Autoconf und Automake mit dem folgenden Code installiert werden:

note: (itstool) path: listing/title
en: pkg-config Files in Autoconf and Automake
de: pkg-config-Dateien in Autoconf und Automake

note: (itstool) path: listing/desc
en: Code to install versioned pkg-config files from <file>configure.ac</file> and <file>Makefile.am</file>
de: Code, um versionierte pkg-config-Dateien über <file>configure.ac</file> und <file>Makefile.am</file> zu installieren

note: (itstool) path: section/title
en: Configuration Files
de: Konfigurationsdateien

note: (itstool) path: section/p
en: From a user standpoint, the best approach to configuration files is to keep the format both <link xref="api-stability">forward and backward compatible</link> (both library versions understand exactly the same configuration file syntax and semantics). Then the same configuration file can be used for all versions of the library, and no versioning is needed on the configuration file itself.
de: Für den Nutzer ist der beste Ansatz für Konfigurationsdateien, ihr Format <link xref="api-stability">aufwärts- und abwärtskompatibel</link> zu halten (beide Bibliotheksversionen erlauben die genau gleiche Konfigurationsdatei-Syntax und -Semantik). Damit kann die gleiche Konfigurationsdatei für alle Versionen der Bibliothek verwendet werden, und die Konfigurationsdatei selbst muss nicht versioniert werden.

note: (itstool) path: section/p
en: If you can’t do that, the configuration files should simply be renamed, and users will have to configure each version of the library separately.
de: Falls das nicht möglich ist, sollten die Konfigurationsdateien schlicht umbenannt werden, und Nutzer müssen jede Version separat konfigurieren.

note: (itstool) path: section/title
en: Gettext Translations
de: Gettext-Übersetzungen

note: (itstool) path: section/p
en: If you use gettext for translations in combination with autoconf and automake, normally things are set up to install the translations to <file>/usr/share/locale/<var>lang</var>/LC_MESSAGES/<var>package</var></file>. You’ll need to change <var>package</var>. The convention used in GNOME is to put this in <file>configure.ac</file>:
de: Wenn Sie für Übersetzungen gettext im Kombination mit autoconf und automake verwenden, werden Übersetzungen für gewöhnlich in <file>/usr/share/locale/<var>lang</var>/LC_MESSAGES/<var>package</var></file> installiert. Sie müssen dabei <var>package</var> ändern. Die GNOME-Konvention ist, dafür <file>configure.ac</file> zu verwenden:

note: (itstool) path: section/p
en: Then use <code>GETTEXT_PACKAGE</code> as the package name to pass to <code mime="text/x-csrc">bindtextdomain()</code>, <code mime="text/x-csrc">textdomain()</code>, and <code mime="text/x-csrc">dgettext()</code>.
de: Verwenden Sie <code>GETTEXT_PACKAGE</code> als den Paketnamen, der an <code mime="text/x-csrc">bindtextdomain()</code>, <code mime="text/x-csrc">textdomain()</code> und <code mime="text/x-csrc">dgettext()</code> übergeben wird.

note: (itstool) path: section/title
en: D-Bus Interfaces
de: D-Bus-Schnittstellen

note: (itstool) path: section/p
en: A D-Bus interface is another form of API, similar to a C API except that resolution of the version is done at runtime rather than compile time. Versioning D-Bus interfaces is otherwise no different to C APIs: version numbers must be included in interface names, service names and object paths.
de: Eine D-Bus-Schnittstelle ist eine andere Form von API, ähnlich zu einer C-API mit der Ausnahme, dass die Versionsauflösung zur Laufzeit statt beim Kompilieren stattfindet. Abgesehen davon werden D-Bus-Schnittstellen genauso wie C-APIs versioniert: Versionsnummern müssen in den Namen der Schnittstelle und Diensten sowie in den Objektpfaden enthalten sein.

note: (itstool) path: section/p
en: For example, for a service <code>org.example.Foo</code> exposing interfaces <code>A</code> and <code>B</code> on objects <code>Controller</code> and <code>Client</code>, versions 4 and 5 of the D-Bus API would look like this:
de: Für einen Dienst <code>org.example.Foo</code>, der die Schnittstellen <code>A</code> und <code>B</code> auf den Objekten <code>Controller</code> und <code>Client</code> bereitstellt, würden die Versionen 4 und 5 der D-Bus-API wie folgt aussehen:

note: (itstool) path: list/title
en: Service Names
de: Dienstnamen

note: (itstool) path: list/title
en: Interface Names
de: Schnittstellennamen

note: (itstool) path: list/title
en: Object Paths
de: Objektpfade

note: (itstool) path: section/title
en: Programs, Daemons and Utilities
de: Programme, Daemons und Dienstprogramme

note: (itstool) path: section/p
en: Desktop applications generally do not need to be versioned, as they are not depended on by any other modules. Daemons and utility programs, however, interact with other parts of the system and hence need versioning.
de: Desktop-Anwendungen müssen für gewöhnlich nicht versioniert werden, da keine anderen Module von ihnen abhängen. Daemons und Dienstprogramme interagieren hingegen mit anderen Teilen des Systems und erfordern daher eine Versionierung.

note: (itstool) path: section/p
en: Given a daemon and utility program:
de: Es sei ein Daemon und ein Dienstprogramm vorhanden:

note: (itstool) path: section/p
en: these should be versioned as:
de: diese sollten wie folgt versioniert werden:

note: (itstool) path: section/p
en: You may want to install a symbolic link from <file>/usr/bin/foo-lookup-utility</file> to the recommended versioned copy of the utility, to make it more convenient for users to use.
de: Vermutlich möchten Sie einen symbolischen Link von <file>/usr/bin/foo-lookup-utility</file> zur empfohlenen versionierten Kopie des Dienstes setzen, um Nutzern die Verwendung zu vereinfachen.

note: (itstool) path: info/desc
en: Contract programming with checks on function input and output
de: Vertragsprogrammierung mit Überprüfung der Funktionsein- und -ausgabe

note: (itstool) path: page/title (itstool) path: section/title
en: Pre- and Post-Conditions
de: Vor- und Nach-Zustände

note: (itstool) path: item/title
en: Assertions
de: Zusicherungen

note: (itstool) path: item/p
en: Check for programmer errors and abort the program on failure.
de: Auf Programmierfehler prüfen und das Programm im Problemfall abbrechen lassen.

note: (itstool) path: item/title
en: Validation
de: Überprüfung

note: (itstool) path: item/p
en: Do not use threads if at all possible. (<link xref="#when-to-use-threading"/>)
de: Verwenden Sie, wenn möglich, keine Threads. (<link xref="#when-to-use-threading"/>)

note: (itstool) path: item/p
en: If threads have to be used, use <code>GTask</code> or <code>GThreadPool</code> and isolate the threaded code as much as possible. (<link xref="#using-threading"/>)
de: Wenn Threads notwendig sind, verwenden Sie <code>GTask</code> oder <code>GThreadPool</code> und isolieren Sie den betreffenden Code so weit wie möglich. (<link xref="#using-threading"/>)

note: (itstool) path: section/title
en: When to Use Threading
de: Anwendungsfälle für Threading

note: (itstool) path: example/p
en: With an implementation something like:
de: Mit einer Implementation ähnlich wie:

note: (itstool) path: section/title
en: Using Threading
de: Threading verwenden

note: (itstool) path: info/desc
en: Using the right tool for various tasks
de: Das richtige Werkzeug für verschiedene Aufgaben

note: (itstool) path: item/p
en: Compile frequently with a second compiler. (<link xref="#gcc-and-clang"/>)
de: Kompilieren Sie häufig mit einem zweiten Compiler. (<link xref="#gcc-and-clang"/>)

note: (itstool) path: section/title
en: GCC and Clang
de: GCC und Clang

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> to the <file>m4/</file> directory of your project.
de: Kopieren Sie <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> in den Ordner <file>m4/</file> Ihres Projekts.

note: (itstool) path: item/p
en: Add <code>AX_VALGRIND_CHECK</code> to <file>configure.ac</file>.
de: Fügen Sie <code>AX_VALGRIND_CHECK</code> zu <file>configure.ac</file> hinzu.

note: (itstool) path: item/p
en: Add <code>@VALGRIND_CHECK_RULES@</code> to the <file>Makefile.am</file> in each directory which contains unit tests.
de: Fügen Sie <code>@VALGRIND_CHECK_RULES@</code> zur Datei <file>Makefile.am</file> in jedem Ordner hinzu, der Unit-Tests enthält.

note: (itstool) path: section/p
en: Suppression files are supported by the <code>AX_VALGRIND_CHECK</code> macro:
de: Unterdrückungsdateien werden vom <code>AX_VALGRIND_CHECK</code>-Makro unterstützt:

note: (itstool) path: section/p
en: A full tutorial on using memcheck is <link href="http://valgrind.org/docs/manual/mc-manual.html">here</link>.
de: Ein vollständiges Tutorial zu Memcheck finden Sie <link href="http://valgrind.org/docs/manual/mc-manual.html">hier</link>.

note: (itstool) path: section/title
en: cachegrind and KCacheGrind
de: cachegrind und KCacheGrind

note: (itstool) path: section/p
en: A full tutorial on using cachegrind is <link href="http://valgrind.org/docs/manual/cg-manual.html">here</link>.
de: Ein vollständiges Tutorial zu Cachegrind finden Sie <link href="http://valgrind.org/docs/manual/cg-manual.html">hier</link>.

note: (itstool) path: section/title
en: helgrind and drd
de: helgrind und drd

note: (itstool) path: section/p
en: Full tutorials on using helgrind and drd are <link href="http://valgrind.org/docs/manual/hg-manual.html">here</link> and <link href="http://valgrind.org/docs/manual/drd-manual.html"> here</link>.
de: Vollständiges Tutorials zu Helgrind und drd finden Sie <link href="http://valgrind.org/docs/manual/hg-manual.html">hier</link> und <link href="http://valgrind.org/docs/manual/drd-manual.html"> hier</link>.

note: (itstool) path: section/p
en: A full tutorial on using sgcheck is <link href="http://valgrind.org/docs/manual/sg-manual.html">here</link>.
de: Ein vollständiges Tutorial zu sgcheck finden Sie <link href="http://valgrind.org/docs/manual/sg-manual.html">hier</link>.

note: (itstool) path: section/title
en: gcov and lcov
de: gcov und lcov

note: (itstool) path: section/p
en: To add <code>AX_CODE_COVERAGE</code> support to a project:
de: So fügen Sie Unterstützung für <code>AX_CODE_COVERAGE</code> zu einem Projekt hinzu:

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> to the <file>m4/</file> directory of your project.
de: Kopieren Sie <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> in den <file>m4/</file>-Ordner Ihres Projekts.

note: (itstool) path: item/p
en: Add <code>AX_CODE_COVERAGE</code> to <file>configure.ac</file>.
de: Fügen Sie <code>AX_CODE_COVERAGE</code> zu <file>configure.ac</file> hinzu.

note: (itstool) path: item/p
en: Add <code>@CODE_COVERAGE_RULES</code> to the top-level <file>Makefile.am</file>.
de: Fügen Sie <code>@CODE_COVERAGE_RULES</code> zur Datei <file>Makefile.am</file> der obersten Ebene hinzu.

note: (itstool) path: section/p
en: Documentation on using gcov and lcov is <link href="http://ltp.sourceforge.net/coverage/lcov.php">here</link>.
de: Dokumentation zur Verwendung von gcov und lcov finden Sie <link href="http://ltp.sourceforge.net/coverage/lcov.php">hier</link>.

note: (itstool) path: section/title
en: Address, Thread and Undefined Behavior Sanitizers
de: Adress-, Thread- und undefinierte Verhaltenssanitizer

note: (itstool) path: section/p
en: A full tutorial on using Clang is <link href="http://clang-analyzer.llvm.org/scan-build.html">here</link>.
de: Ein vollständiges Tutorial zu Clang finden Sie <link href="http://clang-analyzer.llvm.org/scan-build.html">hier</link>.

note: (itstool) path: info/desc
en: Designing software to be tested and writing unit tests for it
de: Entwerfen von zu testender Software und Schreiben von Komponententests.

note: (itstool) path: page/title
en: Unit Testing
de: Unit-Testung

note: (itstool) path: section/title
en: Writing Unit Tests
de: Schreiben von Unit Tests

note: (itstool) path: section/title
en: Installed Tests
de: Installierte Tests

note: (itstool) path: section/p
en: To add support for installed-tests, add the following to <file>configure.ac</file>:
de: Um Unterstützung für installierte Tests hinzuzufügen, fügen Sie Folgendes zu <file>configure.ac</file> hinzu:

note: (itstool) path: section/title
en: Test Generation
de: Testgenerierung

note: (itstool) path: section/p
en: The topic of software testability is covered in the following articles:
de: Das Thema Software-Testbarkeit wird in den folgenden Artikeln behandelt:

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Software_testability">Software testability</link>
de: <link href="https://de.wikipedia.org/wiki/Testbarkeit">Software-Testbarkeit</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Dependency_injection">Dependency injection</link>
de: <link href="https://de.wikipedia.org/wiki/Dependency_Injection">Dependency injection</link>

note: (itstool) path: info/desc
en: Source code version control with git
de: Quellcode-Versionsverwaltung mit Git

note: (itstool) path: page/title
en: Version Control
de: Versionsverwaltung

note: (itstool) path: synopsis/p
en: git is used for version control for all GNOME projects. This page assumes good working knowledge of git; some introductory material is available <link href="https://www.atlassian.com/git/tutorials/">here</link>, and a <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">git cheatsheet is here</link>.
de: Git ist das Versionskontrollsystem aller GNOME-Projekte. Auf dieser Seite nehmen wir an, dass Sie bereits gute praktische Erfahrungen mit git besitzen. Einführungsmaterialien finden Sie <link href="https://www.atlassian.com/git/tutorials/">hier</link>, ein Cheatsheet finden Sie außerdem <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">hier</link>.

note: (itstool) path: item/p
en: Make atomic, revertable commits. (<link xref="#guidelines-for-making-commits"/>)
de: Erstellen Sie atomare, reversible Commits. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Include full reasoning in commit messages, plus links to relevant bug reports or specifications. (<link xref="#guidelines-for-making-commits"/>)
de: Nehmen Sie alle Hintergründe in die Commit-Nachrichten auf, einschließlich Verweise auf Fehlerberichte und Spezifikationen. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Keep large changes, such as renames, in separate commits. (<link xref="#guidelines-for-making-commits"/>)
de: Stecken Sie große Änderungen wie Umbenennungen in separate Commits. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Merge changes from feature branches by rebasing. (<link xref="#use-of-git"/>)
de: Führen Sie Änderungen aus Feature-Branchen durch Rebasen zusammen. (<link xref="#use-of-git"/>)

note: (itstool) path: section/title
en: Use of Git
de: Verwendung von Git

note: (itstool) path: section/p
en: Most GNOME repositories follow these rules:
de: Die meisten GNOME-Repositories folgen diesen Regeln:

note: (itstool) path: item/p
en: No forced pushes. Except for branches with the <code>wip/</code> prefix (work-in-progress), the commits’ history must not be modified, as contributors rely on it.
de: Keine erzwungenen Pushes. Mit Ausnahme von Branches mit dem <code>wip/</code>-Präfix (»Work in Progress«) darf der Commit-Verlauf nicht geändert werden, da sich Mitwirkende darauf verlassen.

note: (itstool) path: item/p
en: Rebase commits rather than merging, to have a linear history (which is easier to follow).
de: Rebasen Sie Commits eher als Mergen, um die History linear zu halten (welcher einfacher zu folgen ist)

note: (itstool) path: item/p
en: Work on feature branches on GNOME git in <code>wip/</code> branches, then rebase on master and fast-forward merge the changes. It is a good practice to also add your nickname to the branch name, as <code>wip/nickname/feature</code>.
de: Arbeiten Sie im GNOME-git mit Feature-Branches (<code>wip/</code>-Präfix), rebasen Sie anschließend auf dem master-Branch und führen Sie die Änderungen mit einem fast-forward-Merge zusammen. Es hat sich ebenfalls bewährt, dass Sie Ihren Nutzernamen in der Form <code>wip/nickname/feature</code> zum Branch hinzufügen.

note: (itstool) path: item/p
en: Hide <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">sausage making</link> by squashing commits before merging.
de: Verstecken Sie Ihre <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">Wurstherstellung</link>, indem Sie Commits vor dem Merge zusammenlegen (»squash«).

note: (itstool) path: section/title
en: Guidelines for Making Commits
de: Richtlinien für Commits

note: (itstool) path: section/p
en: Commits should be as small as possible, but no smaller. Each commit should address a single issue, containing only changes related to that issue. The message for each commit should describe the issue, explain what causes it, and explain how it has been fixed if it is not obvious. If the commit is associated with a bug report, the full URI for the bug report should be put on a line by itself at the bottom of the commit message. Similarly, the ID for the git commit (from <cmd>git log --oneline</cmd>) should be copied into the bug report once the commit has been pushed, so it is easy to find one from the other.
de: Commits sollten so klein wie möglich sein, aber nicht kleiner. Jeder Commit sollte ein einzelnes Problem adressieren und nur dazu unmittelbar relevante Änderungen enthalten. Die Commit-Nachricht sollte das Problem beschreiben, die Ursache erklären sowie die Lösung aufzeigen, sofern diese nicht offensichtlich ist. Bezieht sich der Commit auf einen Fehlerbericht, sollte in der letzten Zeile der Commit-Nachricht die vollständige URI des Berichts stehen. Ebenso sollte die Commit-Kennung (zu erhalten mittels <cmd>git log --oneline</cmd>) in den Fehlerbericht kopiert werden, sobald der Commit hochgeladen wurde.

note: (itstool) path: section/p
en: The changes in each commit should be easy to read. For example, they should not unnecessarily change whitespace or indentation. Large, mechanical changes, such as renaming a file or function, should be put in separate commits from modifications to code inside that file or function, so that the latter changes do not get buried and lost in the former.
de: Die Änderungen in jedem Commit sollten einfach zu lesen sein. Zum Beispiel sollten keine unnötigen Änderungen an den Leerzeichen oder Einrückungen enthalten sein. Große, mechanische Änderungen wie das Umbenennen einer Datei oder Funktion sollten in einem eigenen Commit separat von inhaltlichen Änderungen am Code in der Datei oder Funktion stattfinden, damit letztere nicht verloren gehen.

note: (itstool) path: section/p
en: The following principles give the reasoning for all the advice above:
de: Die folgenden Prinzipien erklären die soeben aufgezeigten Ratschläge:

note: (itstool) path: item/p
en: Each commit should take the repository from one working state to another, otherwise <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">bisection</link> is impossible.
de: Jeder Commit überträgt das Repository von einem funktionierenden Zustand in einen anderen. Anderenfalls ist <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">Bisection</link> unmöglich.

note: (itstool) path: item/p
en: Each commit should be individually revertable. If it later turns out that the commit was a bad idea, <cmd>git revert <var>commit ID</var></cmd> should take the repository from a working state to another working state.
de: Jeder Commit sollte in sich reversibel sein. Sollte sich später herausstellen, dass der Commit keine gute Idee war, sollte ein <cmd>git revert <var>commit ID</var></cmd> das Repository von einem funktionierenden Zustand in einen anderen übertragen.

note: (itstool) path: item/p
en: The reasoning for each commit, and its relationship to external resources like specifications and bug reports, should be clear, to the extent that commits written by one developer a year in the past should still be understandable by a second developer without having to trace through the changes and work out what they do.
de: Die Hintergründe jedes Commits und seine Beziehungen zu externen Ressourcen wie Spezifikationen und Fehlerberichten sollten klar sein. Ein Entwickler sollte noch ein Jahr später in der Lage sein zu verstehen, was ein anderer Entwickler gemacht hat, ohne sich durch alle Änderungen wühlen zu müssen.

note: (itstool) path: item/p
en: Each commit should be written once, and designed to be read many times, by many reviewers and future programmers.
de: Jeder Commit sollte einmalig geschrieben und dann vielfach gelesen werden können, von vielen Reviewern und künftigen Entwicklern.

note: (itstool) path: section/title
en: Merging Procedure
de: Merge-Prozess

note: (itstool) path: section/p
en: To merge a feature branch named <code>my-branch</code> into master, use the following commands:
de: Um einen Feature-Branch namens <code>my-branch</code> in den master-Branch zu mergen, verwenden Sie die folgenden Befehle:

note: (itstool) path: item/p
en: <link href="http://git-scm.com/docs/gittutorial">Official git tutorial</link>
de: <link href="http://git-scm.com/docs/gittutorial">Offizielles Git-Tutorial</link>

note: (itstool) path: item/p
en: <link href="https://try.github.io/">Interactive git tutorial</link>
de: <link href="https://try.github.io/">Interaktives Git-Tutorial</link>

note: (itstool) path: item/p
en: <link href="http://www.git-tower.com/learn/">git-tower tutorial</link>
de: <link href="http://www.git-tower.com/learn/">Tutorial zu git-tower</link>

note: (itstool) path: info/desc
en: Versioning and releasing libraries and applications
de: Versionierung und Veröffentlichung von Bibliotheken und Anwendungen

note: (itstool) path: synopsis/p
en: Module versioning differs for libraries and applications: libraries need a libtool version specified in addition to their package version. Applications just have a package version.
de: Die Versionierung von Modulen unterscheidet sich zwischen Bibliotheken und Anwendungen: Anwendungen benötigen eine Paketversion, Bibliotheken zusätzlich dazu eine libtool-Version.

note: (itstool) path: item/p
en: Libraries and applications have a package version of the form <em>major.minor.micro</em>. (<link xref="#package-versioning"/>)
de: Bibliotheken und Anwendungen besitzen eine Paketversion der Form <em>major.minor.micro</em>. (<link xref="#package-versioning"/>)

note: (itstool) path: item/p
en: Libraries additionally have a libtool version of the form <em>current:revision:age</em>. (<link xref="#libtool-versioning"/>)
de: Bibliotheken besitzen zusätzlich eine libtool-Version der Form <em>current:revision:age</em>. (<link xref="#libtool-versioning"/>)

note: (itstool) path: item/p
en: Version numbers should be updated for each release (using release and post-release increments). (<link xref="#release-process"/>)
de: Versionsnummern müssen für jede Veröffentlichung aktualisiert werden (mittels Release- und Post-Release-Erhöhung). (<link xref="#release-process"/>)

note: (itstool) path: item/p
en: Package versions should be incremented for feature changes or additions. (<link xref="#package-versioning"/>)
de: Paketversionen sollten für Änderungen an bestehenden Funktionen oder neue Funktionsmerkmale erhöht werden. (<link xref="#package-versioning"/>)

note: (itstool) path: item/p
en: Libtool versions should be updated for API changes or additions. (<link xref="#libtool-versioning"/>)
de: Libtool-Versionen sollten bei Änderungen an der API aktualisiert werden. (<link xref="#libtool-versioning"/>)

note: (itstool) path: item/p
en: Even/odd <em>minor</em> package versions can be used respectively for stable/unstable releases. (<link xref="#stable-unstable-versions"/>)
de: Gerade/ungerade <em>Minor</em>-Paketversionen weisen auf stabile/instabile Veröffentlichungen hin. (<link xref="#stable-unstable-versions"/>)

note: (itstool) path: section/title
en: Package Versioning
de: Paket-Versionierung

note: (itstool) path: section/p
en: Both libraries and applications have a package version of the form <em>major.minor.micro</em>.
de: Sowohl Bibliotheken als auch Anwendungen haben eine Paketversion der Form <em>major.minor.micro</em>.

note: (itstool) path: section/p
en: The package version number is that passed to <code>AC_INIT()</code>, and the one which is typically known as the project’s version number. For example, the Debian package for a library will use the library’s package version (though may also include the major version number in the package name to allow for <link xref="parallel-installability">parallel installability</link>). Package versions are updated by the following rules:
de: Bei der Paketversionsnummer handelt es sich um die Nummer, die an <code>AC_INIT()</code> übergeben wird und typischerweise als die Projektversionsnummer bekannt ist. Das Debian-Paket einer Bibliothek verwendet beispielsweise die Paketversion der Bibliothek (sie könnte allerdings auch die Major-Versionsnummer im Paketnamen verwenden, um <link xref="parallel-installability">parallele Installierbarkeit</link> zum ermöglichen). Paketversionen werden unter Berücksichtigung der folgenden Regeln aktualisiert:

note: (itstool) path: item/p
en: If breaking <link xref="api-stability">API compatibility</link> in a library, or making a large change to an application which affects everything (such as a UI redesign), increment major and set minor and micro to 0.
de: Wenn Sie in einer Bibliothek <link xref="api-stability">inkompatible API-Änderungen</link> vornehmen oder Ihre Anwendung weitreichende Änderungen erhält (z.B. eine komplett neue Benutzeroberfläche), dann erhöhen Sie die Major-Version und setzen Minor und Micro auf 0.

note: (itstool) path: item/p
en: Otherwise, if changing or adding a feature, or adding any API, increment minor and set micro to 0.
de: Anderenfalls, wenn Sie Funktionsmerkmale ändern oder hinzufügen, oder eine neue API hinzufügen, dann erhöhen Sie die Minor-Version und setzen Micro auf 0.

note: (itstool) path: item/p
en: Otherwise (if making a release containing only bug fixes and translation updates), increment micro.
de: Anderenfalls (wenn Ihre Veröffentlichung nur Fehlerbehebungen und aktualisierte Übersetzungen enthält), dann erhöhen Sie die Micro-Version.

note: (itstool) path: section/p
en: Note that the minor version number should be updated if any API is added.
de: Beachten Sie, dass die Minor-Versionsnummer aktualisiert werden sollte, sobald eine API hinzugefügt wird.

note: (itstool) path: section/title
en: Libtool Versioning
de: Libtool-Versionierung

note: (itstool) path: section/p
en: Libraries have two version numbers: a libtool version which tracks ABI backwards compatibility (see <link xref="api-stability"/>), and a package version which tracks feature changes. These are normally incremented in synchronization, but should be kept separate because ABI backwards compatibility is not necessarily related to feature changes or bug fixes. Furthermore, the two version numbers have different semantics, and cannot be automatically generated from each other.
de: Bibliotheken besitzen zwei Versionsnummern: eine libtool-Version, die die ABI-Abwärtskompatibilität verfolgt (siehe <link xref="api-stability"/>), und eine Paketversion, die Funktionsänderungen verfolgt. Für gewöhnlich werden beide Versionen gemeinsam erhöht, sollten aber separat gespeichert werden, da die ABI-Abwärtskompatibilität nicht zwangsläufig mit Funktionsänderungen oder Fehlerbehebungen zusammenhängt. Außerdem haben die beiden Versionsnummern unterschiedliche inhaltliche Bedeutungen und können nicht automatisch aus der jeweils anderen generiert werden.

note: (itstool) path: section/p
en: A good overview of libtool versioning, and the differences from package versioning, is given in the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>; another is in the <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool manual</link>.
de: Eine gute Übersicht zur Versionierung von libtools und die Unterschiede zur Paketversionierung finden Sie in den <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>; eine andere ist im <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool-Handbuch</link> zu finden.

note: (itstool) path: section/p
en: To update the libtool version, follow the algorithm given in the comments below. This is a typical <file>configure.ac</file> snippet for setting up libtool versioning:
de: Um die libtool-Version zu aktualisieren, befolgen Sie den nachfolgenden Algorithmus. Dies ist ein typischer Ausschnitt aus einer <file>configure.ac</file>-Datei, um die libtool-Versionierung festzulegen:

note: (itstool) path: section/p
en: The following snippet can be used in a <file>Makefile.am</file> to pass that version info to libtool:
de: Der folgende Code kann in <file>Makefile.am</file> verwendet werden, um die Versionsnummer an libtool zu übergeben:

note: (itstool) path: section/title
en: Stable and Unstable Package Versions
de: Stabile und instabile Paketversionen

note: (itstool) path: section/p
en: Most GNOME modules follow a convention for stable and unstable releases. The minor version is even for stable releases and is odd for unstable releases. For example, the 3.20.* versions are stable, but the 3.19.* versions are unstable. The 3.19.* versions can be seen as alpha and beta releases of the 3.20 version.
de: Die meisten GNOME-Module folgen einer Konvention für stabile und instabile Veröffentlichungen. Die Minor-Version ist bei stabilen Veröffentlichungen gerade und bei instabilen Veröffentlichungen ungerade. Ein Beispiel: die 3.20.*-Versionen sind stabil, die 3.19.*-Versionen hingegen nicht. Die 3.19.*-Versionen können als Alpha- und Beta-Veröffentlichungen der 3.20-Version betrachtet werden.

note: (itstool) path: section/p
en: A new micro <em>stable</em> version (e.g. 3.20.0 → 3.20.1) doesn’t add new features, only translation updates and bug fixes. On the other hand, <em>unstable</em> micro releases (e.g. 3.19.1 → 3.19.2) can add API, or change or remove API which was added in a previous micro release in that minor series.
de: Eine neue <em>stabile</em> Micro-Version (z.B. 3.20.0 → 3.20.1) fügt keine neuen Funktionsmerkmale hinzu, sondern enthält nur Fehlerbehebungen und aktualisierte Übersetzungen. <em>Instabile</em> Micro-Versionen (z.B. 3.19.1 → 3.19.2) dürfen andererseits eine neue API hinzufügen oder bestehende APIs ändern oder entfernen, die in einer vorhergehenden Micro-Version der gleichen Minor-Serie hinzugefügt wurden.

note: (itstool) path: section/p
en: The libtool version should be updated only for stable package versions.
de: Die libtool-Version sollte nur bei stabilen Paketversionen aktualisiert werden.

note: (itstool) path: section/title
en: Release Process
de: Veröffentlichungsprozess

note: (itstool) path: section/p
en: The standard process for making a release of a module increments the libtool version (if the module is a library) at the time of release, then increments the package version number immediately afterwards (this is called a post-release increment).
de: Der Standardprozess zur Erstellung einer Veröffentlichung eines Modus beinhaltet die Erhöhung der libtool-Version (wenn es sich um eine Bibliothek handelt) zum Veröffentlichungszeitpunkt, und erhöht unmittelbar anschließend die Paketversionsnummer (dies wird »post-release increment« genannt).

note: (itstool) path: section/p
en: Updating the libtool versions at the time of release means that they are only incremented once for all ABI changes in a release. The use of post-release increment for package versions means the package version number is not outdated (still equal to the previous release) during the development cycle.
de: Die libtool-Version zum Zeitpunkt der Veröffentlichung zu aktualisieren, bedeutet, dass alle ABI-Änderungen in der Veröffentlichung durch nur eine Erhöhung abgedeckt sind. Die Paketversion unmittelbar nach Veröffentlichung zu aktualisieren bedeutet, dass die Paketversionsnummer im Entwicklungszyklus nicht veraltet ist (sie ist immer noch gleich mit der vorgehenden Veröffentlichung).

note: (itstool) path: section/p
en: The release process (based on the <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME release process</link>):
de: Der Release-Prozess (basierend auf dem <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME Release-Prozess</link>):

note: (itstool) path: item/p
en: Make sure code is up to date: <cmd>git pull</cmd>
de: Stellen Sie sicher, dass der Code aktuell ist: <cmd>git pull</cmd>

note: (itstool) path: item/p
en: Make sure you have no local changes: <cmd>git status</cmd>
de: Stellen Sie sicher, dass es keine lokalen Änderungen gibt: <cmd>git status</cmd>

note: (itstool) path: item/p
en: If the release is for a stable package version, increment the libtool version number in <file>configure.ac</file> (if it exists)
de: Falls es sich um ein Release einer stabilen Paketversion handelt, erhöhen Sie die libtool-Versionsnummer in <file>configure.ac</file> (falls vorhanden)

note: (itstool) path: item/p
en: Add an entry to the <file>NEWS</file> file
de: Fügen Sie einen Eintrag zur <file>NEWS</file>-Datei hinzu

note: (itstool) path: item/p
en: Run <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> and ensure it succeeds
de: Führen Sie <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> aus und prüfen Sie, ob es erfolgreich durchläuft

note: (itstool) path: item/p
en: Fix any issues which come up, commit those changes, and restart at step 3
de: Lösen Sie gegebenenfalls auftretende Probleme, committen Sie die Änderungen und wiederholen Sie ab Schritt 3

note: (itstool) path: item/p
en: If <cmd>make distcheck</cmd> finishes with “[archive] is ready for distribution”, run <cmd>git commit -a -m "Release version x.y.z"</cmd> (where ‘x.y.z’ is the package version number)
de: Wenn <cmd>make distcheck</cmd> mit »[archive] is ready for distribution« beendet, führen Sie <cmd>git commit -a -m "Release version x.y.z"</cmd> aus (wobei »x.y.z« die Versionsnummer des Pakets ist)

note: (itstool) path: item/p
en: Run <cmd>git push</cmd>
de: Führen Sie <cmd>git push</cmd> aus

note: (itstool) path: item/p
en: If that fails due to other commits having been pushed in the meantime, run <cmd>git pull</cmd> to merge your commit on the branch followed by a second <cmd>git push</cmd>. This is an exception to the GNOME guideline to have a linear Git history (<link xref="version-control#use-of-git"/>). If you prefer to have a linear history, you need to restart at step 1.
de: Falls dies fehlschlägt, weil in der Zwischenzeit andere Commits hochgeladen wurden, führen Sie <cmd>git pull</cmd> aus, mergen Sie die Änderungen und laden diese per <cmd>git push</cmd> hoch. Hierbei handelt es sich um eine Ausnahme von den GNOME-Richtlinien für einen linearen Git-Verlauf (<link xref="version-control#use-of-git"/>). Wenn Sie einen linearen Verlauf bevorzugen, müssen Sie wieder bei Schritt 1 anfangen.

note: (itstool) path: item/p
en: Tag the release: <cmd>git tag -s x.y.z</cmd> (where ‘x.y.z’ is the package version number)
de: Markieren Sie die Veröffentlichung: <cmd>git tag -s x.y.z</cmd> (wobei »x.y.z« die Versionsnummer des Pakets ist)

note: (itstool) path: item/p
en: Run <cmd>git push origin x.y.z</cmd> (where ‘x.y.z’ is the package version number)
de: Führen Sie <cmd>git push origin x.y.z</cmd> aus (wobei »x.y.z« die Versionsnummer des Pakets ist)

note: (itstool) path: section/p
en: The release is now complete, and the post-release version increment can be done:
de: Damit haben Sie den Release beendet und die nachfolgende Versionserhöhung kann erfolgen:

note: (itstool) path: item/p
en: Increment the package version number in <file>configure.ac</file>
de: Erhöhen Sie die Paketversionsnummer in <file>configure.ac</file>

note: (itstool) path: item/p
en: Run <cmd>git commit -a -m "Post-release version increment"</cmd>
de: Führen Sie <cmd>git commit -a -m "Post-release version increment"</cmd> aus

note: (itstool) path: section/p
en: The package archive generated by <cmd>make distcheck</cmd> can now be uploaded to download.gnome.org or distributed in other ways.
de: Das von <cmd>make distcheck</cmd> erzeugte Paketarchiv kann nun zu download.gnome.org hochgeladen oder auf andere Weise verteilt werden.

note: (itstool) path: info/desc
en: Good, readable code keeps the project maintainable
de: Guter, lesbarer Code erhält die Wartungsfähigkeit des Projekts

note: (itstool) path: page/title
en: The Importance of Writing Good Code
de: Die Bedeutung von gutem Code

note: (itstool) path: page/p
en: GNOME is a very ambitious free software project, and it is composed of many software packages that are more or less independent of each other. A lot of the work in GNOME is done by volunteers: although there are many people working on GNOME full-time or part-time for here, volunteers still make up a large percentage of our contributors. Programmers may come and go at any time and they will be able to dedicate different amounts of time to the GNOME project. People’s “real world” responsibilities may change, and this will be reflected in the amount of time that they can devote to GNOME.
de: GNOME ist ein ambitioniertes Freies Softwareprojekt und besteht aus vielen Softwarepaketen, die mehr oder weniger unabhängig voneinander sind. Ein beträchtlicher Anteil der Arbeit in GNOME wird von Freiwilligen übernommen. Auch wenn viele Menschen in Voll- oder Teilzeit an GNOME arbeiten, machen Freiwillige dennoch einen Großteil an den Mitwirkenden aus. Programmierer kommen und gehen wieder, und widmen GNOME unterschiedlich viel Zeit. Das »echte Leben« der Menschen ändert sich vielleicht und wirkt sich darauf aus, viele Zeit sie in GNOME stecken können und wollen.

note: (itstool) path: page/p
en: Software development takes long amounts of time and painstaking effort. This is why most part-time volunteers cannot start big projects by themselves; it is much easier and more rewarding to contribute to existing projects, as this yields results that are immediately visible and usable.
de: Softwareentwicklung erfordert viel Zeit und Mühe. Daher können Teilzeit-Mitwirkende nur selten alleine große Projekte starten. Es ist viel einfacher und belohnender, wenn sie zu bestehenden Projekten beitragen, weil dies schnell zu sichtbaren und nützlichen Ergebnissen führt.

note: (itstool) path: page/p
en: Thus, we conclude that it is very important for existing projects to make it as easy as possible for people to contribute to them. One way of doing this is by making sure that programs are easy to read, understand, modify, and maintain.
de: Daraus schlussfolgern wir, dass bestehende Projekte es so einfach wie möglich für Menschen machen müssen, an ihnen mitzuwirken. Ein Teilaspekt davon ist, sicherzustellen, dass die Programme einfach zu lesen, verstehen, ändern und warten sind.

note: (itstool) path: page/p
en: Messy code is hard to read, and people may lose interest if they cannot decipher what the code tries to do. Also, it is important that programmers be able to understand the code quickly so that they can start contributing with bug fixes and enhancements in a short amount of time. Source code is a form of <em>communication</em>, and it is more for people than for computers. Just as someone would not like to read a novel with spelling errors, bad grammar, and sloppy punctuation, programmers should strive to write good code that is easy to understand and modify by others.
de: Unordentlicher Code ist schwer zu lesen und führt dazu, dass Menschen das Interesse an ihm verlieren, wenn sie ihn nicht verstehen können. Es ist weiterhin wichtig, dass Programmierer den Code verstehen können, damit sie bereits nach kurzer Zeit durch Fehlerbehebungen und Verbesserungen mitwirken können. Quellcode ist eine Form von <em>Kommunikation</em> und für Menschen gedacht - nicht für Rechner. So wie Sie vermutlich keinen Roman mit lauter Rechtschreibfehlern, schlechter Grammatik und nachlässig gesetzter Interpunktion lesen möchten, sollten auch Programmierer guten Code schreiben, der leicht von anderen Leuten verstanden und bearbeitet werden kann.

note: (itstool) path: page/p
en: The following are some important qualities of good code:
de: Im folgenden finden Sie einige wichtige Qualitätsmerkmale von gutem Code:

note: (itstool) path: item/title
en: Cleanliness
de: Übersichtlichkeit

note: (itstool) path: item/p
en: Clean code is easy to read with minimum effort. This lets people start to understand it easily. This includes the coding style itself (brace placement, indentation, variable names), and the actual control flow of the code.
de: Übersichtlicher Code ist mit geringem Aufwand leicht zu lesen. Dritte können ihn einfach verstehen. Darunter fällt der Programmierstil selbst (Platzierung von geschweiften Klammern, Einrückung, Variablennamen) und der eigentliche Kontrollfluss im Code.

note: (itstool) path: item/title
en: Consistency
de: Konsistenz

note: (itstool) path: item/p
en: Consistent code makes it easy for people to understand how a program works. When reading consistent code, one subconsciously forms a number of assumptions and expectations about how the code works, so it is easier and safer to make modifications to it. Code that <em>looks</em> the same in two places should <em>work</em> the same, too.
de: Konsistenter Code erlaubt zu verstehen, wie ein Programm funktioniert. Beim Lesen von konsistentem Code erstellt man unbewusst einige Annahmen und Erwartungen, wie der Code funktioniert, sodass man leichter Änderungen einpflegen kann. Code, der an unterschiedlichen Orten gleich <em>aussieht</em>, sollte auch gleich <em>funktionieren</em>.

note: (itstool) path: item/title
en: Extensibility
de: Erweiterbarkeit

note: (itstool) path: item/p
en: General-purpose code is easier to reuse and modify than very specific code with lots of hardcoded assumptions. When someone wants to add a new feature to a program, it will obviously be easier to do so if the code was designed to be extensible from the beginning. Code that was not written this way may lead people into having to implement ugly hacks to add features.
de: Allgemeiner Code ist einfacher wiederzuverwenden und zu ändern als sehr spezifischer Code mit vielen hartcodierten Annahmen. Wenn jemand einem Programm eine neue Funktion hinzufügen möchte, ist dies natürlich einfacher, wenn der Code von Anfang an erweiterbar ist. Code, der nicht auf diese Weise geschrieben wurde, kann dazu führen, dass Menschen hässliche Hacks implementieren müssen, um Funktionen hinzuzufügen.

note: (itstool) path: item/title
en: Correctness
de: Korrektheit

note: (itstool) path: item/p
en: Finally, code that is designed to be correct lets people spend less time worrying about bugs, and more time enhancing the features of a program. Users also appreciate correct code, since nobody likes software that crashes. Code that is written for correctness and safety (i.e. code that explicitly tries to ensure that the program remains in a consistent state) prevents many kinds of silly bugs.
de: Korrekter Code führt dazu, dass man weniger Zeit mit Fehlersuche verbringt, die man stattdessen in neue Funktionsmerkmale stecken kann. Auch Nutzer schätzen korrekten Code, denn niemand mag Programmabstürze. Code, der auf Korrektheit und Stabilität ausgelegt ist (also Code, der explizit versucht sicherzustellen, dass der Programmstatus erhalten bleibt), verhindert alle möglichen ärgerlichen Fehler.

note: (itstool) path: section/title
en: Book References
de: Bücher

note: (itstool) path: item/p
en: <link href="http://www.cc2e.com">Code Complete</link>, by Steve McConnell.
de: <link href="http://www.cc2e.com">Code Complete</link> von Steve McConnell.

note: (itstool) path: item/p
en: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, by Martin Fowler.
de: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link> von Martin Fowler.

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
de: <link href="https://de.wikipedia.org/wiki/Entwurfsmuster_(Buch)"> Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software </link> von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides.

note: (itstool) path: item/p
en: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>, by Arthur Riel.
de: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link> von Arthur Riel.
