OpenBSD style(9): Wie umsetzen?

[paedubucher]

Ich befasse mich hie und da etwas mit OpenBSD, weil es mich mit seiner "reduced to the max"-Philosophie doch sehr beeindruckt.

Beim letzten Release gab es keinen klassischen Release-Song, sondern diese Style Hymn. Dabei ist mir der Einrückungsstil etwas eigenartig vorgenommen, hier zitiert aus style(9):

Code: Alles auswählen

Indentation is an 8 character tab. Second level indents are four spaces.

Diskussionen über Tabs vs. Spaces und Einrückungstiefen von 2, 4 oder 8 halte ich ja für sehr unproduktiv; mir ist das, was Go mit gofmt macht, am symphatischsten.

Doch falls ich mal OpenBSD-Code schreiben wollte (ja, ich weiss, das wird kaum passieren): Wie müsste ich da meinen Editor konfigurieren (sagen wir mal vi mit .exrc oder vim mit .vimrc), damit ich so programmieren kann?

Es gibt ja verschiedene Optionen wie shiftwidth, tabstop, expandtab, autoindent usw. Kriegt man das so zurecht, ohne dass man jeweils vier Spaces eintippen muss? Oder gibt es da vollautomatisierte Formatter, die entsprechend kofigurierbar sind? Ich kenne ja nur gg=G in vim.

Nachtrag: Gerade ist mir der Gedanke gekommen, dass diese Style-Vorgaben eine Art low-pass filter für möchtegern BSD-Hacker sein könnten. Ich wäre also schon einmal daran gescheitert

[Meillo]

Der etwas seltsame Begriff ``second level indents'' meint umgebrochene, zu lange Zeilen.

Hier etwas mehr Kontext zu der von dir zititerten Aussage:

Indentation is an 8 character tab. Second level indents are four spaces. All code should fit in 80 columns.

Code: Alles auswählen

while (cnt < 20)
	z = a + really + long + statement + that + needs +
	    two + lines + gets + indented + four + spaces +
	    on + the + second + and + subsequent + lines;

Do not add whitespace at the end of a line, and only use tabs followed by spaces to form the indentation. Do not use more spaces than a tab will produce and do not use spaces in front of tabs.

Alle Einrueckungen von Bloecken werden mit einem Tab gemacht. D.h. Tabs definieren die Blockstruktur.

Damit die drei Zeilen der `z'-Zuweisung auf der gleichen Blockebene sind, sind sie hier alle mit einem Tab eingerueckt. Die umgebrochenen Linien sind dahinter zudem mit je vier Spaces eingeschoben, damit man erkennt, dass es eine fortgesetzte Zeile ist.


Meine Frage an dich: Wie soll der vi fuer dich entscheiden, ob eine Zeile ein naechstes Statement oder ein umgebrochenes fortgesetztes Statement ist? Ich wuerde sagen, das kann er nur durch Syntaxanalyse, wozu er die Grammatik der Sprache beherrschen muesste. Damit wirst du keine automatische Unterstuetzung bekommen (ausser du verwendest irgendwelche wilden Vim-Plugins, die es vermutlich gibt). Die Einrueckung mit Tabs machst du manuell oder mit `:set ai'. Wenn du eine Zeile umbrichst, dann tippst du zudem vier Spaces ein. Dieser Fall sollte nur selten vorkommen, naemlich nur wenn du Code umbrechen musst. (Falls das zu oft passiert, dann solltest du an deinem Style arbeiten: weniger tief verschachteln und kuerzere Bezeichner.)

Ich glaube, du hast missverstanden, was ``second level indent'' bedeutet (das ist IMO auch ein verwirrender Begriff, der durch ``indent of wrapped lines'' oder so ersetzt werden sollte).

Im vi musst du fuer diesen Stil gar nichts konfigurieren, weil seine Defaulteinstellungen schon passend dafuer sind. Einzig ueber `ai' kannst du nachdenken, wenn du das angenehm findest.

[rodney]

Interessante Entdeckung. Scheint kein low-pass-Filter zu sein, jedoch sind mir die Beweggruende fuer solche Vorgaben/Best Practices schleierhaft. Fuer vim gibt es wohl ein Plugin fuer FreeBSD bzw style(9): https://raw.githubusercontent.com/freeb ... reebsd.vim

Edit: Danke Meillo. Beweggruende sind nun klar

[paedubucher]

Der etwas seltsame Begriff ``second level indents'' meint umgebrochene, zu lange Zeilen.

Ach, das war eigentlich schon das Missverständnis!
In die Richtung habe ich gar nicht gedacht.

Meine Frage an dich: Wie soll der vi fuer dich entscheiden, ob eine Zeile ein naechstes Statement oder ein umgebrochenes fortgesetztes Statement ist?

Für mich war die Frage ja eher, wie die erste von der zweiten Einrückungsstufe unterschieden werden kann. Aber gehen wir als Denkexperiment mal in diese Richtung.

Ich wuerde sagen, das kann er nur durch Syntaxanalyse, wozu er die Grammatik der Sprache beherrschen muesste. Damit wirst du keine automatische Unterstuetzung bekommen (ausser du verwendest irgendwelche wilden Vim-Plugins, die es vermutlich gibt).

Beim K&R-Style ist da in der Regel öffnende geschweifte Klammern oder ein Semikolon am Ende. Das wäre mal eine ganz grobe Faustregel, sicherlich nicht ausreichend...

Die Einrueckung mit Tabs machst du manuell oder mit `:set ai'. Wenn du eine Zeile umbrichst, dann tippst du zudem vier Spaces ein. Dieser Fall sollte nur selten vorkommen, naemlich nur wenn du Code umbrechen musst. (Falls das zu oft passiert, dann solltest du an deinem Style arbeiten: weniger tief verschachteln und kuerzere Bezeichner.)

Und plötzlich ergibt das ganze einen Sinn! Mit dieser Plackerei will man die Leute davon abhalten lange Zeilen zu schreiben, die dann einen Umbruch verlangen! Hätte ich doch das originale Zitat nicht gekürzt, denn es lautet folgendermassen:

Indentation is an 8 character tab. Second level indents are four spaces. All code should fit in 80 columns.

Code: Alles auswählen

while (cnt < 20)
	z = a + really + long + statement + that + needs +
	    two + lines + gets + indented + four + spaces +
	    on + the + second + and + subsequent + lines;

Nicht mal beim Anblick des Codebeispiels bin ich darauf gekommen, dass es um umgebrochene, fortgesetzte Statements ging.

Ich glaube, du hast missverstanden, was ``second level indent'' bedeutet (das ist IMO auch ein verwirrender Begriff, der durch ``indent of wrapped lines'' oder so ersetzt werden sollte).

Wie schon oben erwähnt, ist genau das Problem. Vielleicht sollte ich den Begriff mal in der entsprechenden Mailingliste ansprechen und auf diesen Thread hier verweisen. Aber "Debianforum" werden die wohl gleich rausfiltern

Im vi musst du fuer diesen Stil gar nichts konfigurieren, weil seine Defaulteinstellungen schon passend dafuer sind. Einzig ueber `ai' kannst du nachdenken, wenn du das angenehm findest.

Autoindent habe ich immer aktiv, das hilft mir.

@rodney: Danke für den Plugin-Hinweis! Werde ich wohl nicht benötigen, aber wenn...

[Meillo]

Die Einrueckung mit Tabs machst du manuell oder mit `:set ai'. Wenn du eine Zeile umbrichst, dann tippst du zudem vier Spaces ein. Dieser Fall sollte nur selten vorkommen, naemlich nur wenn du Code umbrechen musst. (Falls das zu oft passiert, dann solltest du an deinem Style arbeiten: weniger tief verschachteln und kuerzere Bezeichner.)

Und plötzlich ergibt das ganze einen Sinn! Mit dieser Plackerei will man die Leute davon abhalten lange Zeilen zu schreiben, die dann einen Umbruch verlangen!

Fuer viele wirken 8-Zeichen breite Tabs und 80-Zeichne Zeilenlaenge wie unmoegliche und damit unsinnige Einschraenkungen. Natuerlich liegt es auch an der Programmiersprache, wenn mit C++ oder Java hat man durch die Klassen gleich eine Ebene mehr als in C. Ganz generell finde ich jedoch, dass die C-aehnlicher Code meist dann gut ist, wenn er problemlos mit 8-Zeichen Tabs und 80-Zeichen Zeilenlaenge formatiert werden kann. Wenn man da an Probleme stoesst, dann ist das fast immer ein Zeichen fuer ein noetiges Refactoring.

Nicht mal beim Anblick des Codebeispiels bin ich darauf gekommen, dass es um umgebrochene, fortgesetzte Statements ging.

Ich glaube, du hast missverstanden, was ``second level indent'' bedeutet (das ist IMO auch ein verwirrender Begriff, der durch ``indent of wrapped lines'' oder so ersetzt werden sollte).

Wie schon oben erwähnt, ist genau das Problem. Vielleicht sollte ich den Begriff mal in der entsprechenden Mailingliste ansprechen [...]

So sehr die OpenBSD-Leute auf Code-Qualitaet und Code-Verstaendlichkeit Wert legen, dieser Style-Guide hat nicht gerade Vorbildwirkung. Ich finde die Begriffswahl nicht nur an der Stelle missverstaendlich und die Beispiele sind teilweise richtig schlecht, weil sie den relevanten Teil eben gar nicht zeigen. Wenn es um mehrfache Einrueckungen geht, dann sollte man auch mehrfache Einrueckungen im Beispiel zeigen. Wenn es um Compilerwarnings fuer potenziell missverstaendliche Zuordnung bei weggelassenen geschweiften Klammern geht, dann muss man halt auch ein Dangling-Else-Problem zeigen und nicht ein Stueck Code das dieses Problem gar nicht hat. Ehrlich gesagt bin ich etwas enttaeuscht von der schlechten Qualitaet des Dokuments. Ich glaube, ich koennte das besser.

Hmm ... tun oder lassen? Es ist ja nicht gerade so, dass ich gerade nach solchen Herausforderungen suchen wuerde. Zudem ist die OpenBSD-Community nicht gerade bekannt fuer ihre Freundlichkeit. Andererseits sollte man solche Chancen auch wieder nicht verstreichen lassen ...

@paedubucher: Wenn du da einen Patch angehen willst, dann sag Bescheid. Ggf. koennte ich mich mit einbringen. Wenn du aber nichts machen willst und auch sonst niemand ``Hier!'' schreit, dann ueberlege ich es mir doch nochmal ob nicht ich aktiv werden will.