Keiner hier hat irgendetwas mit der maximalen Zeilenlänge begründet.
Davon abgesehen mag ich vom Editor umgebrochenen Code genausowenig wie Leerzeichen zur Einrückung.
Es gibt auch 2016 noch Style Guides die eine maximale Zeilenlänge vorschreiben (z.B. Google C++ Style Guide).
[size=8]Wie ihr ja wisst ist #42 die einzig wahre Antwort, also hier nochmal die Fakten für alle:[/size]
Früher war ich immer gegen maximale Zeilenlängen - aber mittlerweile halte ich es doch wieder für sinnvoll.
Natürlich gibt es mittlerweile größere Bildschirme und höhere Auflösungen.
Trotzdem finde ich beispielsweise eine vertikal lang gestreckte Funktion einfacher zu lesen als einen horizontal extrem in die Breite gestreckten Einzeiler.
Erstens bedeuten größere Bildschirme ebenfalls, dass man auch in der Höhe mehr Platz hat, Code in das Fenster zu bekommen, ohne scrollen zu müssen.
Und wenn man doch scrollen muss, kann man sich ggf. auch mal Gedanken darüber machen, ob es sinnvoll ist, alles in eine Funktion zu packen (“Functions should do one thing.” [1] usw.).
Zweitens kann man große Bildschirme auch dazu nutzen, mehrere Dateien gleichzeitig nebeneinander geöffnet zu haben - was gerade bei Programmiersprachen, bei denen man gewöhnlicherweise eine Datei pro Klasse anlegt, helfen kann.
Deswegen halte ich eine maximale Zeilenlänge durchaus für sinnvoll - wobei ich bei der genauen Längenangabe eventuell sogar mehr als 80 Zeichen für gut befinden würde (z.B. 120 Zeichen oder mehr) und Kommentarblöcke u.U. von dieser Regelung ausschließen würde.
Automatisch vom Editor umgebrochene Zeilen sind dagegen imho nie optimal.
Es sind natürlich außerdem die Tabs für die Einrückung und die Leerzeichen für die Ausrichtung (Ausnahme Python: Überall Leerzeichen, um Ausrichtung zu ermöglichen).
Es ist natürlich zusätzlich noch die geöffnete Klammer in der selben Zeile.
Und es sind selbstverständlich niemals und es dürfen niemals und es können eigentlich auch niemals die Kommata nach dem Zeilenumbruch sein. Wtf ist das denn?
Nebenbei - hat sich zufällig schon mal jemand mit sowas hier beschäftigt? Ich hab das gerade nur zufällig beim Suchen entdeckt - aber eine Möglichkeit, diese Einrückungs-Unterschiede wie die LF/CRLF-Geschichte automatisch von Git handlen zu lassen, klingt ja erstmal nicht schlecht.
[1] Martin, Robert C. Clean code: a handbook of agile software craftsmanship. Pearson Education, 2009.
Die Scheisse mit dem Komma zuerst kann ich dir erklären.
Bei Javascript darf am Ende kein freihängendes Komma stehen. Ich würde sogar sagen, das ist in den meisten Sprachen der Fall. Somit muss man also, wenn man ein neues Element anhängen möchte, in der Zeile davor ein Komma anfügen. Beim Entfernen am Ende muss das Komma entsprechend mitentfernt werden.
Das ist natürlich suboptimal. Aber es ist doch super einfach zu lösen, indem man das Komma mit in die betr. Zeile packt. Somit muss immer nur die jew. Zeile angefügt/entfernt werden.
Auf so einen Schwachsinn können natürlich nur Menschen kommen, die absolut Null Sinn für Ästhetik haben.
Lol!
Das hier ist auch klasse:
Und wieso machen sie das? Damit sie Anweisungen überall sonst nicht mit einem Strichpunkt abschließen müssen. Doh!
2 „Gefällt mir“
[m]git diff --ignore-space-change[/m] oder [m]-w[/m]? Ich weiß eh nicht, warum das normalerweise angezeigt wird. Whitespace-Änderungen sind doch sowas von egal.
Was gerne vergessen wird: Braillezeilen können in der Regel nicht mehr als 80 Zeichen darstellen. Für langlebige Projekte würde ich auf jeden Fall an den 80 Zeichen festhalten.
Wer mehr braucht sollte idR mal über seinen Code nachdenken.
Dafür müsstest du Git aber bei Projekten mit Sprachen wie Python mitteilen, dass es das doch tun sollte. Das Problem ist nicht so groß, wenn man für solche Änderungen separate commits verwendet, das in die Nachricht schreibt und dann muss sich den keiner anschauen. Es ist ohnehin empfehlenswert bei git relativ kleine Änderungen zu comitten.
1 „Gefällt mir“
Eigentlich ja, aber wenn jeder zweite Commit mal schnell zwischen verschiedenen indent-Parametern konvertiert kommen auch wieder Leute und heulen.
Außerdem macht das [m]git blame[/m] kaputt.
[m]git log -L ,:[/m]
[m]git log -L :: [/m]
1 „Gefällt mir“
Genau, und aus einem einfachen [m]git blame[/m] ist wissenschaftliche Untersuchung geworden. Aber trotzdem schön, dass es [m]git log -L[/m] gibt.
Weil abgesehen von Indent-Änderungen niemals mehr als 1 Person den gleichen Bereich im Code angefasst haben können? Ok, wenn man den Thread so anschaut, könnt man es fast glauben 
Natürlich stößt blame auch so schnell an seine Grenzen. Ich habe bei der Arbeit mit Code von anderen Leuten die Erfahrung gemacht, dass die Antwort auf die Frage, wieso jetzt an einer Stelle etwas bestimmtes so und nicht anders gemacht wird, oder dort überhaupt steht, in der letzten Commitnachricht zu finden ist. Wenn dann aber eben Zeilen angefasst werden, die eigentlich nicht angefasst werden sollten, muss man dann den umständlichen Weg gehen. Und dann gibt es eben diese Pappenheimer, deren Editor mal eben die ganze Datei “bereinigt”, wenn sie nur irgendwo anders einen Teil geändert haben, oder die Codezeilen “anfassen” ohne tatsächlich etwas zu ändern etc. pp.
Ich stell hier mal ne frage, da ich bei superuser keine Antwort bekomme:
http://superuser.com/questions/1081487/repo-wide-configuration-of-git
Im prinzip geht es darum sachen direkt in der repo config einzustellen. So koennte man es projekt weit fuer alle user einstellen. → git blame ist reparier
Geht nicht. Eine entfernte git config zu schreiben ist im wesentlichen arbitrary remote code execution, daher könnte man das höchstens für ein subset implementieren. Du kannst höchstens ein Skript schreiben, was die .git/config so anpasst wie du es haben willst, und Leuten nahelegen, das auszuführen (oder, wenn du in die Hölle kommen willst, es als Teil des buildsystems zB aufzurufen)
Vim hat den Mechanismus der Modelines: http://vim.wikia.com/wiki/Modeline_magic
Die sind aber inzwischen per default auch aus, weil man auch dadrueber boesen Code ausfuehren kann.
Ja, vielen dank, ich dachte mir schon, das was ich vor habe “boese” ist 
Zur Tabs vs. Leerzeichen, war gestern auch in Silicon Valley (serie s03e06), gleich nach dem intro
Allen VIM-Nutzern kann ich übrigens das Smart Tabs-Plugin wärmstens empfehlen.
Um alles per Tab einzurücken und mit Leerzeichen an den runden Klammern auszurichten (siehe arws Post) muss noch folgendes in die [m].vimrc[/m]:
set noexpandtab
set cindent
set cinoptions=(0,u0,U0README und mit den Usern reden. Ich mein, ich kann mir vorstellen, warum du das technisch lösen willst. Ich finde aber auch gut, dass es nicht geht. Hat man erst mal genug Erfahrung und eine über lange Zeit gewachsene, sinnvole git config, ist es bestimmt total nervig vom Repo beim nächsten pull ein paar neue Settings reingedrückt zu bekommen.
Ich nutze das Plugin securemodelines:
Ziemlich hölzern, der Dialog. :rolleyes: