2.2.2020
In diesem Artikel beziehe ich mich auf CSS bzw. SCSS. Das Prnzip kann auf weitere Bereiche übertragen werden.
Jeder ist bestrebt guten Quellcode zu schreiben. Dazu gehört, dass der Quellcode so funktioniert, wie man es von ihm erwartet, richtig formatiert ist, den Code Richtlinien folgt und mit Sicherheit einiges mehr.
Manchmal jedoch schafft man es nicht sich an alle Zielvorstellungen zu halten. Genau dann braucht man einen Shame Bereich.
Der Shame Bereich ist am Ende des Dokuments zu finden. Er ist ein klar durch einen Kommentar gekennzeichneter Abschnitt, in dem es erlaubt ist schlechten Quellcode zu schreiben.
Man muss nach schlechtem Quellcode nicht mehr lange suchen. Wenn ein Modul nicht so funktioniert wie es soll, weiß man, wo man als erstes gucken muss. Das erleichtert bei einem Refactoring das Leben ungemein.
Man sollte sich angewöhnen, zu jedem Logischen Block eine Erklärung zu schreiben, welche Regel warum verletzt worden ist. Ggf. sollten noch Tipps für die richtige Umsetzung gegeben werden.
Der Bereich sollte möglichst drastisch heißen, wie eben z.B. Shame. Das führt dazu, dass man zwei mal drüber nachdenkt, ob man wirklich keine saubere Alternative zu seinem Quellcode finden kann. So ist es mir teilweise passiert, dass ich Code im Shame Bereich geschrieben habe und dann beim Schreiben der Beschreibung gemerkt habe, dass das sehr wohl anders und sauber funktioniert. Das wäre mir ohne den Shame Bereich nicht aufgefallen.
Zusätzlich kann es dazu führen, dass Personen die sehr viel in den Shame Bereich schreiben sich über Ihre Unzulänglichkeiten klar werden und ggf. gegensteuern.
Man hat sich auf die BEM Methodik geeinigt, muss aber zwangsweise verschachteln um ein Element anzusprechen. Das passiert manchmal wenn man (teilweise) keinen Einfluss auf die HTML Struktur nehmen kann.
Manchmal weiß man, dass das was man gerade definiert falsch ist, jedoch fehlt (noch) das technische Know How um es richtig zu gestalten.
Manchmal ist es so, dass man für einen Release keine Zeit mehr für sauberen Code hat. Auch dann sollte der schnell eingetippte Bereich nicht mit dem sauberem Quellcode vermischt werden.
Manche Entwicklungsumgebungen bieten einem die Möglichkeit eigene “ToDo’s” zu definieren. Dadurch können diese farbig hervorgehoben werden. Viel wichtiger jedoch ist, dass wenn man eine Datei mit einem ToDo eincheckt, man noch einmal gefragt wird, ob man nicht die ToDo erledigen möchte. Als Bonus können die ToDos dann gruppiert durchsucht werden.
Je nach dem wie der Linter eingestellt ist, kann es Sinn machen die angemerkten Fehler auszuschalten (Beispiel für sass-lint). Wirft z.B. der Linter Fehler in der Konsole, so würden die bereits bekannten Shame Bereich Fehler bei ausreichender Größe neue Fehler überdecken, was kontraproduktiv wäre.
Ein Shame Bereich tut niemandem weh und bringt diverse Vorteile mit sich. Im schlimmsten Fall landet der ganze Quellcode im Shame Bereich und nachfolgende Entwickler wissen was sie erwartet. Im besten Fall gibt es nur einen Kommentar im Fußbereich der Datei und der Quellcode entspricht den Richtlinien.