Anselm, Hans, Stefan und Schepp reden heute über Konventionen und das Miteinander in größeren Projekten.
[00:00:18] News
- Brick 2.0
- Mozilla bringt ihre Web Components Bibliothek auf Version 2.0, und verabschiedet sich damit von x-tag. Ab jetzt soll die Web Components Plattform direkt verwendet werden.
- libsass 3.0
- Die native (und viel schnellere) Implementierung von Sass erscheint in Version 3.0. Und hat damit endlich eine Menge Features inkludiert, die von Fans der Ruby-Variante hoch geschätzt werden.
- IE Windows 10 Technical Preview
- Windows 10 kommt, und mit ein neuer Internet Explorer. Was der Browser auf der neuen Plattform bietet, erfahrt ihr hier.
Schaunotizen
- [00:03:45] Code Style Checker und Coding Conventions
- Obigen Artikel als Ausgangsbasis nutzen wir zu einer ausgiebigen Diskussion rund um Coding Conventions und Code Style Checker. Gut finden wir das alle, genutzt wird neben JSHint unter anderem auch PHP Codesniffer, jscs und SCSS Lint. Wir reden über den JS Formatter als Sublime Plugin von Paul Irish, und lernen die Pre-commit Hooks von Git kennen (und schätzen).
[00:36:12] Keine Schaunotizen
- HTTP/2 FAQ
- Was Sie schon immer über HTTP/2 wissen wollten, aber bisher nicht zu fragen wagten.
- Respimage
- Wenn ein Pull Request nicht mehr reicht braucht man eine eigene Bibliothek. Respimage ist der performantere Picturefill.
- CSSUrl
- Node Tool um URLs im CSS einzubetten. Falls eure bisherigen Tools nicht schon ausreichen.
Kommentare
Sebastian #
Geschrieben am 28.10.2014 um 10:00
Codestyle Checker, Linter usw sind alles ganz tolle Ideen und sicher auch nützlich und sinnvoll, aber ich für meinen Teil kann aus der Java Sicht dazu sagen das man auch aufpassen muss das man es nicht zu weit treibt. Ein sehr prominentes Java Beispiel ist da z.B. das Bean Pattern. Das JavaBean Pattern beschreibt kurz gesagt das Vorgehen am Beginn einer Klasse Felder zu definieren (am besten private) und diese nur über public getter und setter Methoden zu manipulieren. Dieses Pattern war sicher einmal gut gemeint und ist oft auch sinnvoll, aber es wird häufig paradigmatische durchgezogen und ist leider auch gern in Stylecheckern als Test verankert. Das führt dann dazu das die Hälfte einer kleinen Klasse nur aus eigentlich leeren Methoden besteht die den Wert eines Feldes setzen (ohne diesen weiter zu manipulieren oder zu prüfen) oder ihn wieder ausgeben, wodurch auch der Sinn das Feld dringend private zu machen ausgehebelt wird. Pragmatischer wäre in einem solchen Fall dem Feld eine angemessene Zugriffsberechtigung zu geben und direkt in das Feld zu schreiben, vor allem wenn der Wert sowieso nur innerhalb einer Klasse selbst genutzt wird.
Solche Beispiele finden sich zu hauf in der Java Welt wo die Stylechecker schon seit Ewigkeiten gang und gäbe sind und viele Dinge werden einfach immer so gemacht ohne Sinn und Zweck zu hinterfragen weil das schon immer so war.
Oft sind diese Tools und Regeln sehr sinnvoll, aber man sollte das auch ab und an hinterfragen und nicht bis ins Extrem treiben wenn es nichts bringt. Manchmal ist Pragmatismus die bessere Wahl.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.