Programmierstil - Versionsgeschichte

Serols: Änderungen von 2003:E6:773F:A300:4C0E:AC9A:EDBF:B0FB (Diskussion) rückgängig gemacht (HG) (3.4.12)

2024-07-02T15:25:40Z

Änderungen von 2003:E6:773F:A300:4C0E:AC9A:EDBF:B0FB (Diskussion) rückgängig gemacht (HG) (3.4.12)

← Nächstältere Version		Version vom 2. Juli 2024, 17:25 Uhr
Zeile 1:		Zeile 1:
	[[Ein ~~Käfig voller Helden\|Ein]]~~ '''Programmierstil''' (engl. ''code conventions'', ''coding conventions'', ''coding standards'') ist in der [[Programmierung]] das Erstellen von [[Quellcode]] nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von [[Softwarequalität]], der insbesondere die [[Verständlichkeit]] und [[Wartbarkeit]] von [[Software]], dies sind Kriterien für Softwarequalität gem. [[ISO/IEC 9126]] (aktualisiert durch [[ISO/IEC 25000]]) unterstützen soll.		Ein '''Programmierstil''' (engl. ''code conventions'', ''coding conventions'', ''coding standards'') ist in der [[Programmierung]] das Erstellen von [[Quellcode]] nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von [[Softwarequalität]], der insbesondere die [[Verständlichkeit]] und [[Wartbarkeit]] von [[Software]], dies sind Kriterien für Softwarequalität gem. [[ISO/IEC 9126]] (aktualisiert durch [[ISO/IEC 25000]]) unterstützen soll.

	Ein Programmierstil und die Vorgaben dazu regeln, ''„wie“'' ein Programm, d. h. sein Quellcode, in formaler und struktureller Hinsicht gestaltet sein soll – unabhängig davon, ''„was“'' das Programm leisten soll. Dabei wirken drei Aspekte zusammen:		Ein Programmierstil und die Vorgaben dazu regeln, ''„wie“'' ein Programm, d. h. sein Quellcode, in formaler und struktureller Hinsicht gestaltet sein soll – unabhängig davon, ''„was“'' das Programm leisten soll. Dabei wirken drei Aspekte zusammen:
Zeile 7:		Zeile 7:

	In einem umfassenderen Sinn gelten auch die [[Programmierparadigma\|Programmierparadigmen]] als (fundamentaler) Programmierstil.<ref>Andreas Schwill, Uni Paderborn: [http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf ''Programmierstile im Anfangsunterricht'']</ref> <!-- auch: http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Methoden_der_KI/WS0001/methki06.pdf und: http://ddi.cs.uni-potsdam.de/Lehre/UebersichtInfoSST/Programmierstile.pdf -->		In einem umfassenderen Sinn gelten auch die [[Programmierparadigma\|Programmierparadigmen]] als (fundamentaler) Programmierstil.<ref>Andreas Schwill, Uni Paderborn: [http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf ''Programmierstile im Anfangsunterricht'']</ref> <!-- auch: http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Methoden_der_KI/WS0001/methki06.pdf und: http://ddi.cs.uni-potsdam.de/Lehre/UebersichtInfoSST/Programmierstile.pdf -->

			Die Beurteilung eines Programmierstils erfordert in der Regel ein tiefes semantisches Verständnis des Programmquelltextes. Aus diesem Grund sind [[Style Checker]] und [[Beautifier]] bisher nicht oder nur äußerst eingeschränkt in der Lage, die Überprüfung auf einen guten Programmierstil bezüglich dieser Elemente durchzuführen bzw. eine Einhaltung gewährleisten zu können.

	== Zweck ==		== Zweck ==

2003:E6:773F:A300:4C0E:AC9A:EDBF:B0FB am 2. Juli 2024 um 15:24 Uhr

2024-07-02T15:24:11Z

← Nächstältere Version		Version vom 2. Juli 2024, 17:24 Uhr
Zeile 1:		Zeile 1:
	Ein '''Programmierstil''' (engl. ''code conventions'', ''coding conventions'', ''coding standards'') ist in der [[Programmierung]] das Erstellen von [[Quellcode]] nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von [[Softwarequalität]], der insbesondere die [[Verständlichkeit]] und [[Wartbarkeit]] von [[Software]], dies sind Kriterien für Softwarequalität gem. [[ISO/IEC 9126]] (aktualisiert durch [[ISO/IEC 25000]]) unterstützen soll.		[[Ein Käfig voller Helden\|Ein]] '''Programmierstil''' (engl. ''code conventions'', ''coding conventions'', ''coding standards'') ist in der [[Programmierung]] das Erstellen von [[Quellcode]] nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von [[Softwarequalität]], der insbesondere die [[Verständlichkeit]] und [[Wartbarkeit]] von [[Software]], dies sind Kriterien für Softwarequalität gem. [[ISO/IEC 9126]] (aktualisiert durch [[ISO/IEC 25000]]) unterstützen soll.

	Ein Programmierstil und die Vorgaben dazu regeln, ''„wie“'' ein Programm, d. h. sein Quellcode, in formaler und struktureller Hinsicht gestaltet sein soll – unabhängig davon, ''„was“'' das Programm leisten soll. Dabei wirken drei Aspekte zusammen:		Ein Programmierstil und die Vorgaben dazu regeln, ''„wie“'' ein Programm, d. h. sein Quellcode, in formaler und struktureller Hinsicht gestaltet sein soll – unabhängig davon, ''„was“'' das Programm leisten soll. Dabei wirken drei Aspekte zusammen:
Zeile 7:		Zeile 7:

	In einem umfassenderen Sinn gelten auch die [[Programmierparadigma\|Programmierparadigmen]] als (fundamentaler) Programmierstil.<ref>Andreas Schwill, Uni Paderborn: [http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf ''Programmierstile im Anfangsunterricht'']</ref> <!-- auch: http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Methoden_der_KI/WS0001/methki06.pdf und: http://ddi.cs.uni-potsdam.de/Lehre/UebersichtInfoSST/Programmierstile.pdf -->		In einem umfassenderen Sinn gelten auch die [[Programmierparadigma\|Programmierparadigmen]] als (fundamentaler) Programmierstil.<ref>Andreas Schwill, Uni Paderborn: [http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf ''Programmierstile im Anfangsunterricht'']</ref> <!-- auch: http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Methoden_der_KI/WS0001/methki06.pdf und: http://ddi.cs.uni-potsdam.de/Lehre/UebersichtInfoSST/Programmierstile.pdf -->

	Die Beurteilung eines Programmierstils erfordert in der Regel ein tiefes semantisches Verständnis des Programmquelltextes. Aus diesem Grund sind [[Style Checker]] und [[Beautifier]] bisher nicht oder nur äußerst eingeschränkt in der Lage, die Überprüfung auf einen guten Programmierstil bezüglich dieser Elemente durchzuführen bzw. eine Einhaltung gewährleisten zu können.

	== Zweck ==		== Zweck ==

Louis Bafrance: Tippfehler korrigiert

2023-04-22T20:50:01Z

Tippfehler korrigiert

← Nächstältere Version		Version vom 22. April 2023, 22:50 Uhr
Zeile 59:		Zeile 59:
	{{Hauptartikel\|Kommentar (Programmierung)}}		{{Hauptartikel\|Kommentar (Programmierung)}}

	Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen ~~beschänken~~.<ref Name="JavaOracle" /> Dies kann auch von der [[Programmiersprache]] (z. B. der Verwendbarkeit ‚[[Sprechender Name]]n‘) abhängig sein.		Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen beschränken.<ref Name="JavaOracle" /> Dies kann auch von der [[Programmiersprache]] (z. B. der Verwendbarkeit ‚[[Sprechender Name]]n‘) abhängig sein.

	''Zu viele'' ~~Kommentar~~ können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der ~~Implemetierung~~ prüfen.<ref Name="JavaOracle" />		''Zu viele'' Kommentare können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der Implementierung prüfen.<ref Name="JavaOracle" />

	''Zu wenige'' Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.		''Zu wenige'' Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.

Rolf acker: /* Kommentare */ hier keine Werkliste; weitere formale Kleinigkeiten

2023-04-19T09:02:48Z

Kommentare: hier keine Werkliste; weitere formale Kleinigkeiten

← Nächstältere Version		Version vom 19. April 2023, 11:02 Uhr
Zeile 59:		Zeile 59:
	{{Hauptartikel\|Kommentar (Programmierung)}}		{{Hauptartikel\|Kommentar (Programmierung)}}

	Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen beschänken<ref Name="JavaOracle"/>. Dies kann auch von der [[Programmiersprache]] (z. B. der Verwendbarkeit ‚[[Sprechender Name]]n‘) abhängig sein.		Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen beschänken.<ref Name="JavaOracle" /> Dies kann auch von der [[Programmiersprache]] (z. B. der Verwendbarkeit ‚[[Sprechender Name]]n‘) abhängig sein.

	''Zu viele'' Kommentar können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der Implemetierung prüfen.<ref Name="JavaOracle"/>		''Zu viele'' Kommentar können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der Implemetierung prüfen.<ref Name="JavaOracle" />

	''Zu wenige'' Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.		''Zu wenige'' Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.

	Früher galt die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets ''selbsterklärend'' sein sollte. Er unterscheidet zwischen ~~"guten"~~ und ~~"schlechten"~~ Kommentaren.<ref>{{Literatur \|Autor=Robert Cecil Martin \|Titel=Clean Code. A Handbook of Agile Software Craftsmanship \|Verlag=Prentice Hall \|Ort=Upper Saddle River NJ u. a. \|Datum=2008 \|ISBN=978-0-13-235088-4 ~~\|Typ=wl~~ \|Kapitel=4. Comments \|Seiten=53-74}}</ref>		Früher galt die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets ''selbsterklärend'' sein sollte. Er unterscheidet zwischen „guten“ und „schlechten“ Kommentaren.<ref>{{Literatur \|Autor=Robert Cecil Martin \|Titel=Clean Code. A Handbook of Agile Software Craftsmanship \|Verlag=Prentice Hall \|Ort=Upper Saddle River NJ u. a. \|Datum=2008 \|ISBN=978-0-13-235088-4 \|Kapitel=4. Comments \|Seiten=53-74}}</ref>

	==== Zeilenlänge ====		==== Zeilenlänge ====

Sebastian.Dietrich: /* Kommentare */ in Hauptartikel verschoben

2023-04-18T14:24:33Z

Kommentare: in Hauptartikel verschoben

@@ Zeile 65: / Zeile 65: @@
 ''Zu wenige'' Kommentare bedeuten im Wartungsfall (z.&nbsp;B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.
-Früher galt die Abwesenheit von [[Kommentar (Programmierung)|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets ''selbsterklärend'' sein sollte. Er unterscheidet zwischen folgenden "guten" und "schlechten" Kommentaren:<ref>{{Literatur |Autor=Robert Cecil Martin |Titel=Clean Code. A Handbook of Agile Software Craftsmanship |Verlag=Prentice Hall |Ort=Upper Saddle River NJ u. a. |Datum=2008 |ISBN=978-0-13-235088-4 |Typ=wl |Kapitel=4. Comments |Seiten=53-74}}</ref>
+Früher galt die Abwesenheit von [[Kommentar (Programmierung)|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets ''selbsterklärend'' sein sollte. Er unterscheidet zwischen "guten" und "schlechten" Kommentaren.<ref>{{Literatur |Autor=Robert Cecil Martin |Titel=Clean Code. A Handbook of Agile Software Craftsmanship |Verlag=Prentice Hall |Ort=Upper Saddle River NJ u. a. |Datum=2008 |ISBN=978-0-13-235088-4 |Typ=wl |Kapitel=4. Comments |Seiten=53-74}}</ref>
 ==== Zeilenlänge ====

VÖRBY: Einleitg zu 'kommentare' inkl. Link zum Hauptartikel

2023-04-18T09:08:56Z

Einleitg zu 'kommentare' inkl. Link zum Hauptartikel

← Nächstältere Version		Version vom 18. April 2023, 11:08 Uhr
Zeile 22:		Zeile 22:
	Die Inhalte, die Gegenstand eines Programmierstils sind, können von Fall zu Fall unterschiedlich sein. Die Bandbreite reicht von einfachen Vorgaben zur Code-Strukturierung (Einrückungen) bis hin zu Festlegungen für alle das „Wie“ der [[Implementierung]] betreffenden Details.		Die Inhalte, die Gegenstand eines Programmierstils sind, können von Fall zu Fall unterschiedlich sein. Die Bandbreite reicht von einfachen Vorgaben zur Code-Strukturierung (Einrückungen) bis hin zu Festlegungen für alle das „Wie“ der [[Implementierung]] betreffenden Details.

	In größeren ''[[Projekt]]en und Unternehmen'', wo viele Beteiligte in der [[Softwareentwicklung]] zusammenarbeiten, werden die [[Anforderung (Informatik)\|Anforderungen]] zum Programmierstil häufig in ''Programmierrichtlinien'' festgelegt. Oft bauen diese auf überbetrieblich oder international veröffentlichten Konventionen und Empfehlungen auf; Beispiele sind die „[[Ungarische Notation]]“ oder die „Java-Code-Conventions“.<ref>Oracle ''Code Conventions for the Java TM Programming Language''[http://www.oracle.com/technetwork/java/codeconvtoc-136057.html oracle.com]''(1999)''</ref> Ein Teil der Regeln ist auf die verwendete ''[[Programmiersprache]]'' ausgerichtet. Einzelne oder viele Elemente können situationsbedingt unterschiedlich ''wichtig'' sein (von „Muss“ bis zu „nicht relevant“); z. B. abhängig davon, ob die Software nur einmalig oder dauerhaft benutzt werden soll. Im ''privaten oder nicht-kommerziellen'' Bereich wenden Softwareentwickler häufig nur einen erlernten oder intuitiv angewendeten, nicht explizit festgelegten Programmierstil an.		In größeren ''[[Projekt]]en und Unternehmen'', wo viele Beteiligte in der [[Softwareentwicklung]] zusammenarbeiten, werden die [[Anforderung (Informatik)\|Anforderungen]] zum Programmierstil häufig in ''Programmierrichtlinien'' festgelegt. Oft bauen diese auf überbetrieblich oder international veröffentlichten Konventionen und Empfehlungen auf; Beispiele sind die „[[Ungarische Notation]]“ oder die „Java-Code-Conventions“.<ref Name="JavaOracle"> Oracle ''Code Conventions for the Java TM Programming Language''[http://www.oracle.com/technetwork/java/codeconvtoc-136057.html oracle.com]''(1999)''</ref>

			Ein Teil der Regeln ist auf die verwendete ''[[Programmiersprache]]'' ausgerichtet. Einzelne oder viele Elemente können situationsbedingt unterschiedlich ''wichtig'' sein (von „Muss“ bis zu „nicht relevant“); z. B. abhängig davon, ob die Software nur einmalig oder dauerhaft benutzt werden soll. Im ''privaten oder nicht-kommerziellen'' Bereich wenden Softwareentwickler häufig nur einen erlernten oder intuitiv angewendeten, nicht explizit festgelegten Programmierstil an.

	Beispiele für Elemente des Programmierstils sind nachfolgend gelistet (u. a. aus<ref>Uwe Sauerland: [http://uwe-sauerland.de/richtlinien/Programmierstil.html ''Richtlinien zum Programmierstil'']</ref>):		Beispiele für Elemente des Programmierstils sind nachfolgend gelistet (u. a. aus<ref>Uwe Sauerland: [http://uwe-sauerland.de/richtlinien/Programmierstil.html ''Richtlinien zum Programmierstil'']</ref>):
Zeile 55:		Zeile 57:

	==== Kommentare ====		==== Kommentare ====
			{{Hauptartikel\|Kommentar (Programmierung)}}
⚫	Früher galt die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil~~. Eine programmierende Person müsse immer davon ausgehen, dass ihr Code auch von anderen gelesen und verstanden werden muss~~. Man ging ~~man~~ davon aus, dass ~~hierzu~~ Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets selbsterklärend sein sollte. Er unterscheidet zwischen folgenden "guten" und "schlechten" Kommentaren:<ref>{{Literatur \|Autor=Robert Cecil Martin \|Titel=Clean Code. A Handbook of Agile Software Craftsmanship \|Verlag=Prentice Hall \|Ort=Upper Saddle River NJ u. a. \|Datum=2008 \|ISBN=978-0-13-235088-4 \|Typ=wl \|Kapitel=4. Comments \|Seiten=53-74}}</ref>

			Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen beschänken<ref Name="JavaOracle"/>. Dies kann auch von der [[Programmiersprache]] (z. B. der Verwendbarkeit ‚[[Sprechender Name]]n‘) abhängig sein.

			''Zu viele'' Kommentar können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der Implemetierung prüfen.<ref Name="JavaOracle"/>

			''Zu wenige'' Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.

		⚫	Früher galt die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] wird das differenzierter gesehen. [[Robert Cecil Martin]] weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets ''selbsterklärend'' sein sollte. Er unterscheidet zwischen folgenden "guten" und "schlechten" Kommentaren:<ref>{{Literatur \|Autor=Robert Cecil Martin \|Titel=Clean Code. A Handbook of Agile Software Craftsmanship \|Verlag=Prentice Hall \|Ort=Upper Saddle River NJ u. a. \|Datum=2008 \|ISBN=978-0-13-235088-4 \|Typ=wl \|Kapitel=4. Comments \|Seiten=53-74}}</ref>

	;"gute" Kommentare:		;"gute" Kommentare:
	:* Rechtliche Kommentare wie beispielsweise Urheberrechtshinweise		:* Rechtliche Kommentare wie beispielsweise Urheberrechtshinweise

Sebastian.Dietrich: /* Beispiel Quelltextformatierung */ siehe disk

2023-04-15T08:40:12Z

Beispiel Quelltextformatierung: siehe disk

@@ Zeile 44: / Zeile 44: @@
 == Beispiel Quelltextformatierung ==
 Wichtige Aspekte des Programmierstils sind die Anordnung von untergeordneten Programmelementen ([[Einrückungsstil]]), die damit unmittelbar auch auf die Positionierung umschließender Syntaxelemente wie <code>{}</code>, <code>[]</code>, <code>()</code>, <code>BEGIN</code> oder <code>END</code> Einfluss haben, sowie der Einsatz von Leerzeichen und Leerzeilen und die Verschachtelungstiefe untergeordneter Programmelemente.
 Auch die [[Namenskonvention]]en für Symbole spielen eine gewichtige Rolle im Zusammenhang mit der Bewertung des Programmierstils. Der Name eines Symbols sollte die Funktion oder Verwendungsweise hinreichend erklären oder zumindest andeuten. Da heute ausreichend Speicherplatz für den Code zur Verfügung steht, ist die früher übliche platzsparende Verwendung von Kürzeln wie zum Beispiel „dskmngr“ nicht mehr gerechtfertigt. Häufig wird für unterschiedliche Arten von Symbolen auch eine unterschiedliche Schreibweise verwendet, um so am Symbolnamen ablesen zu können, ob es sich um eine [[Variable (Programmierung)|Variable]], eine [[Funktion (Programmierung)|Funktion]], eine [[Objektorientierte Programmierung#Klassen|Klasse]] oder eine [[Konstante (Programmierung)|Konstante]] etc. handelt. (Siehe auch [[Ungarische Notation]]). In diesem Zusammenhang sind auch die Länge und der Umfang von Symbolen sowie deren Deklarationsreihenfolge von Bedeutung.
@@ Zeile 55: / Zeile 53: @@
 === Umstrittene Elemente ===
 Die folgenden Elemente von Programmierstilen sind umstritten. Es folgt zu jedem Element eine Gegenüberstellung der Argumente der jeweiligen Befürworter und Gegner. Falls möglich und als allgemein akzeptiert betrachtbar, schließt sich eine Empfehlung bezüglich des umstrittenen Elements an die Erörterung an.
 ==== Zeilenlänge ====

Sebastian.Dietrich: /* Beispiel Quelltextformatierung */ siehe disk

2023-04-13T18:56:41Z

Beispiel Quelltextformatierung: siehe disk

← Nächstältere Version		Version vom 13. April 2023, 20:56 Uhr
Zeile 45:		Zeile 45:
	Wichtige Aspekte des Programmierstils sind die Anordnung von untergeordneten Programmelementen ([[Einrückungsstil]]), die damit unmittelbar auch auf die Positionierung umschließender Syntaxelemente wie <code>{}</code>, <code>[]</code>, <code>()</code>, <code>BEGIN</code> oder <code>END</code> Einfluss haben, sowie der Einsatz von Leerzeichen und Leerzeilen und die Verschachtelungstiefe untergeordneter Programmelemente.		Wichtige Aspekte des Programmierstils sind die Anordnung von untergeordneten Programmelementen ([[Einrückungsstil]]), die damit unmittelbar auch auf die Positionierung umschließender Syntaxelemente wie <code>{}</code>, <code>[]</code>, <code>()</code>, <code>BEGIN</code> oder <code>END</code> Einfluss haben, sowie der Einsatz von Leerzeichen und Leerzeilen und die Verschachtelungstiefe untergeordneter Programmelemente.

	Darüber ~~hinaus~~ ~~ist~~ die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode ~~ein~~ Zeichen für einen schlechten Programmierstil. Eine programmierende Person muss immer davon ausgehen, dass ihr Code auch von anderen gelesen und verstanden werden muss; ~~hierzu~~ ~~sind~~ Kommentare unerlässlich. Heutzutage gibt es auch oftmals feste Formate für Kommentare, die beispielsweise Ein- und Ausgabeparameter einer Funktion oder Methode einzeln erläutern. Dadurch können diese von automatischen Dokumentationsprogrammen wie [[doxygen]] oder [[javadoc]] verwendet werden, um vollautomatisch eine menschenlesbare Dokumentation zu generieren.		Darüber galt früher die Abwesenheit von [[Kommentar (Programmierung)\|Kommentaren]] im Quellcode als Zeichen für einen schlechten Programmierstil. Eine programmierende Person muss immer davon ausgehen, dass ihr Code auch von anderen gelesen und verstanden werden muss. Früher ging man davon aus, dass hierzu Kommentare unerlässlich wären. Seit [[Refactoring]] und [[Clean Code]] geht man davon aus, dass Code immer so geschrieben werden kann, dass er auch ohne Kommentare, die potentiell falsch sind und veraltern, von einer anderen Person verstanden werden kann. Heutzutage gibt es auch oftmals feste Formate für Kommentare, die beispielsweise Ein- und Ausgabeparameter einer Funktion oder Methode einzeln erläutern. Dadurch können diese von automatischen Dokumentationsprogrammen wie [[doxygen]] oder [[javadoc]] verwendet werden, um vollautomatisch eine menschenlesbare Dokumentation zu generieren.

	Auch die [[Namenskonvention]]en für Symbole spielen eine gewichtige Rolle im Zusammenhang mit der Bewertung des Programmierstils. Der Name eines Symbols sollte die Funktion oder Verwendungsweise hinreichend erklären oder zumindest andeuten. Da heute ausreichend Speicherplatz für den Code zur Verfügung steht, ist die früher übliche platzsparende Verwendung von Kürzeln wie zum Beispiel „dskmngr“ nicht mehr gerechtfertigt. Häufig wird für unterschiedliche Arten von Symbolen auch eine unterschiedliche Schreibweise verwendet, um so am Symbolnamen ablesen zu können, ob es sich um eine [[Variable (Programmierung)\|Variable]], eine [[Funktion (Programmierung)\|Funktion]], eine [[Objektorientierte Programmierung#Klassen\|Klasse]] oder eine [[Konstante (Programmierung)\|Konstante]] etc. handelt. (Siehe auch [[Ungarische Notation]]). In diesem Zusammenhang sind auch die Länge und der Umfang von Symbolen sowie deren Deklarationsreihenfolge von Bedeutung.		Auch die [[Namenskonvention]]en für Symbole spielen eine gewichtige Rolle im Zusammenhang mit der Bewertung des Programmierstils. Der Name eines Symbols sollte die Funktion oder Verwendungsweise hinreichend erklären oder zumindest andeuten. Da heute ausreichend Speicherplatz für den Code zur Verfügung steht, ist die früher übliche platzsparende Verwendung von Kürzeln wie zum Beispiel „dskmngr“ nicht mehr gerechtfertigt. Häufig wird für unterschiedliche Arten von Symbolen auch eine unterschiedliche Schreibweise verwendet, um so am Symbolnamen ablesen zu können, ob es sich um eine [[Variable (Programmierung)\|Variable]], eine [[Funktion (Programmierung)\|Funktion]], eine [[Objektorientierte Programmierung#Klassen\|Klasse]] oder eine [[Konstante (Programmierung)\|Konstante]] etc. handelt. (Siehe auch [[Ungarische Notation]]). In diesem Zusammenhang sind auch die Länge und der Umfang von Symbolen sowie deren Deklarationsreihenfolge von Bedeutung.

10vor: sorry...

2022-09-05T08:57:50Z

sorry...

← Nächstältere Version		Version vom 5. September 2022, 10:57 Uhr
Zeile 95:		Zeile 95:
	* [https://google.github.io/styleguide/javaguide.html Google Java Code Style] (englisch)		* [https://google.github.io/styleguide/javaguide.html Google Java Code Style] (englisch)
	* [http://www.gnu.org/prep/standards/ The GNU Coding Standards] (englisch)		* [http://www.gnu.org/prep/standards/ The GNU Coding Standards] (englisch)
	* https://www.kernel.org/doc/html/latest/process/coding-style.html Linux Kernel Coding Style] (englisch)		* [https://www.kernel.org/doc/html/latest/process/coding-style.html Linux Kernel Coding Style] (englisch)
	* [http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style%26arch=i386 OpenBSD Kernel source file style guide (KNF)] (englisch)		* [http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style%26arch=i386 OpenBSD Kernel source file style guide (KNF)] (englisch)
	* [http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/00000489.html ActionScript Coding Standards von MacroMedia] (englisch)		* [http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/00000489.html ActionScript Coding Standards von MacroMedia] (englisch)

10vor: Link zum Linux Kernel Coding Style aktualisiert

2022-09-05T08:57:23Z

Link zum Linux Kernel Coding Style aktualisiert

← Nächstältere Version		Version vom 5. September 2022, 10:57 Uhr
Zeile 95:		Zeile 95:
	* [https://google.github.io/styleguide/javaguide.html Google Java Code Style] (englisch)		* [https://google.github.io/styleguide/javaguide.html Google Java Code Style] (englisch)
	* [http://www.gnu.org/prep/standards/ The GNU Coding Standards] (englisch)		* [http://www.gnu.org/prep/standards/ The GNU Coding Standards] (englisch)
	* ~~[http~~://www.~~linuxfromscratch~~.org/~~alfs~~/~~view~~/~~hacker~~/~~part2/hacker~~/coding-style.html Linux Kernel Coding Style] (englisch)		* https://www.kernel.org/doc/html/latest/process/coding-style.html Linux Kernel Coding Style] (englisch)
	* [http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style%26arch=i386 OpenBSD Kernel source file style guide (KNF)] (englisch)		* [http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style%26arch=i386 OpenBSD Kernel source file style guide (KNF)] (englisch)
	* [http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/00000489.html ActionScript Coding Standards von MacroMedia] (englisch)		* [http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/00000489.html ActionScript Coding Standards von MacroMedia] (englisch)