Co to znaczy być zajętym? Ano na przykład nie mieć absolutnie czasu nawet na nowe posty na blogu, chociaż tematów jest cała rzeka. Tak oto byłem zajęty, zawodowo oraz prywatnie. Dziś wracamy „on-line” z tematem, i to nie byle jakim… Zyskiwać czas można poprzez optymalizację codziennych czynności, ich automatyzację i organizację. I zawsze staram się to krok po kroku wdrażać. Efekty widać gołym okiem – więcej czasu, mniejsze zmęczenie i frustracja.

W aspekcie programowania można by tutaj napisać o narzędziach, np. webpack. Ale temu poświęcimy oddzielne posty. Dziś skupimy się na podejściach do pisania stylów CSS w dobry, komfortowy dla nas (i dla innych) sposób, aby to co stworzymy było łatwe w utrzymaniu i rozbudowie.

„Long term value of the software is directly proportional to the quality of code base…”
— Douglus Crockford

Czy znacie style guides i konwencje CSS? Na przykład OOCSS, BEM, rscss, SMACSS. A może OMG? Być może stosujecie wybrane podejście do tworzenia CSS, być może jedynie obiło się o uszy, ale nie porwało Was na tyle, aby to zastosować. A może widzieliście już przykłady CSS w tutorialach napisane z użyciem BEMa czy innego SMACSSa, ale nie zwracaliście uwagi na takie detale. Ten artykuł bierze pod lupę właśnie podejścia o pisania CSS, organizacji plików, nazywania klas CSS, itp. Team jest obszerny i wyjdzie poza jeden artykuł.

Notka: jako że od dawna piszę style prawie wyłącznie przy użyciu Sass (SCSS – Syntactically Awesome Style Sheets), również artykuły i przykłady kodów odnosić się będą do tego preprocesora CSS, zwanego też „CSS with superpowers” 🙂 Poświęcimy mu oddzielny artykuł, póki co można zerknąć na oficjalną stronę: http://sass-lang.com po więcej informacji.

Pracę z Sass można zacząć (kto jeszcze tego nie zrobił) szybko i przyjemnie. Nie trzeba nawet tracić zbytnio czasu na narzędzia i konfiguracje – web framework, którego używacie prawdopodobnie wspiera Sass. Sam pracuję głównie w Ruby on Rails (RoR) oraz node.js, gdzie nie ma żadnych z tym problemów.

Co do style giude, to jeśli chodzi o JavaScript / ES6, moim ulubionym jest ten opracowany przez Airbnb:

https://github.com/airbnb/javascript

To samo dotyczy podejścia do pisania (S)CSS:

https://github.com/airbnb/css

Dla wybranych składni możemy sobie zainstalować i skonfigurować odpowiedni linting.

UWAGA: mam jedno zastrzeżenie do rekomendacji Airbnb, co do letter case dla bloków. Nie przepadam za PascalCase / camelCase, zwłaszcza we front-end development. Oczywiście np. w Ruby / RoR (które uwielbiam) używamy PascalCase dla nazw klas i snake_case dla nazw metod, gdzie wygląda to świetnie. Po prostu jakoś tak… bardzo pasuje akurat tak, a nie inaczej.

W przypadku CSS zdecydowanie preferuję kebab-case (spinal-case, hyphen delimited, https://en.wikipedia.org/wiki/Letter_case#Special_case_styles), stąd też nie piszę żadnych:

.pageHead {}
.sub_header {}
...

tylko:

.page-head {}
.sub-header {}
...

Oczywiście jest to tylko moja własna preferencja.

Tak naprawdę podejść i konwencji, zarówno dla JS i CSS, jest cała masa. My powinniśmy oczywiście używać takiej, która jest rozsądna, spójna ORAZ komfortowa dla nas. Jeśli nie mamy własnego, „lepszego” zbioru zasad, skorzystajmy z jednego z dostępnych. Mój wybór to konwencje od inżynierów Airbnb. I jak widzimy, w przypadku przewodnika dla CSS, również tam pojawia się rekomendacja używania BEM i/lub OOCSS. Tym będziemy się zajmować. Tak naprawdę… ważne jest nie tyle jakie konwencje wybieramy (… niby dlaczego A jest lepsze od B? może dla mnie, ale nie koniecznie dla Ciebie …). Ważne jest, aby trzymać się wybranych konwencji konsekwentnie. Wtedy naprawdę skorzystamy, w przeciwnym razie prędzej czy później powstanie niepotrzebny bałagan.

Zacznijmy jednak od kilku słów na temat Sass / SCSS, oraz przede wszystkim, od struktury plików dla naszych stylów.

„Writing CSS is easy. Writing maintainable CSS is hard.”

Dlaczego to wszystko ma znaczenie? OK, sam nie lubię tego „Overengineering’u”, który zdaje się być typowy dla środowiska programistów front-end. Stąd mamy miliardy narzędzi, bibliotek, approaches i „racji” co do pisania kodów JS i CSS. Niektórzy programiści niestety zdają również być, delikatnie mówiąc, dziwni, próbując narzucać jakieś podejście jako „jedyne słuszne”.

Bzdury… Niektórzy są irytująco leniwi, jako że problemem zdaje się dla nich stawianie średnika na końcu linijki. Albo problem „czy muszę uczyć się PHP lub innego języka, skoro znam JS”… nie ma to jak pasja do programowania, co? 🙂

OK, ja uczyłem się języków jeden po drugim, i nigdy nie widziałem w tym problemu (ale może jestem już dinozaurem 🙂 ?). Trochę też trwało, zanim znalazłem „swoje miejsce” w programowaniu. Dziś jest inaczej, dziś jest znacznie prościej. Wszystko mamy podane na tacy, dostęp do rozwiązań i wiedzy. Mamy na tacy wręcz za dużo, dlatego trzeba wybrać coś dla siebie.

Wiadomo że zawodowo używa się kilku języków i narzędzi, cała reszta może być for fun, czy dla pasji. Może też przydać się np. do rozwoju jakiegoś projektu open source, bądź poratować nas, gdy kiedyś okaże się, że potrzebny nam większy skill. W końcu ta branża jest dynamiczna jak chyba żadna inna.

Co więc z tymi średnikami? Helloooł, a programowałeś w czymkolwiek innym? Ja uwielbiam Język Ruby i jego konwencję. No i brak średników. Jednak co do JS i CSS, to przez wszystkie lata przywykłem do średników na końcu. Zwyczajnie. I Innych detali, jak wcięcia, itp. Wiem kiedy kod wygląda dla mnie dobrze, a kiedy nie…

Ktoś w swoich projektach jak najbardziej może używać .sass zamiast .scss lub Standard JS zamiast Airbnb JS. Grunt żeby było komfortowo i praktycznie. Oraz spójnie. Dla mnie komfortowo i praktycznie jest tak, a nie inaczej, stąd też trzymam się konwencji Airbnb dla JS, oraz preferuję składnię .scss ponad .sass. Jeśli pokażę jednak przykłady kodu według moich ulubionych konwencji, NIE powinno być żadnego problemu dla innych, aby szybko zaadaptować je do używanych przez siebie podejść. Dla prawdziwego programisty takie detale to małe piwo.

Wspominam o tym, ponieważ warto być elastycznym i adaptować się. Szczególnie w teamie. A ja pracując przez lata w różnych team’ach i projektach, po prostu musiałem „wskoczyć” w sposób programowania teamu, zamiast próbować go zmieniać – na siłę, a już na pewno nie hejtować.

Dobre, uzasadnione zmiany są zwykle mile widziane. Ale przebudowa ponad połowy kodu dla samej sztuki, albo czyjegoś wyznania… „a bo w ostatnią sobotę oglądałem video-tutorial z hiper fajnym, trendy podejściem – musimy przerobić nasz kod, będzie fajniejszy i łatwiejszy w utrzymaniu”. Hola, a czy obecny kod nie jest?

Cóż… Sam nienawidzę rozwiązań, które zdają się jedynie tworzyć problemy, ale je rozwiązać, lub takich, które rozwiązują jeden „problem”, ale w jego miejsce przynoszą 10 innych… Takich „cudów” unikamy, sięgamy po sensowne, faktycznie potrzebne rozwiązania, które przynoszą realne korzyści i dają udogodnienia.

Tak czy inaczej, warto szukać sposobności do pójścia naprzód, zamiast wymówek. Rozwijajmy się, śledźmy nowe trendy i budujmy nowoczesne oprogramowanie. Dobry, czysty i spójny kod, który nie będzie przestarzały za 5 minut. W nowoczesnych podejściach fajne jest to, że znacznie łatwiej niż kiedyś możemy aktualizować nasze rozwiązania do nowszych wersji.

Ale na tym dość już filozofii, nie chcę wchodzić w te tematy rzeki. Do dzieła!