Class 10: Principles of Great Code and CSS Preprocessors (by way of Stylus)

One of the main goals of this course is to look at the principles of good software engineering and teach them in the context of visual web design. That is a new (in 2016) idea which is powerful and needs students like you to spread. Here is a list, "Principles of Good Programming", which I am stealing from Christopher Diggins but they are all well-known amongst good developers:

• DRY - Don't Repeat Yourself
• Abstraction Principle Every piece of significant functionality should be implemented in just one place in the source code. When similar functions are carried out be distinct pieces of code, it is generally worth combining them using abstraction.
• KISS - Keep It Simple, Stupid
• YAGNI (You Aren't Going to Need It)
• Do the simplest thing that could possibly work
• Don't make me think Code should be easy to read and understand (and debug/maintain)
• Open/Closed Principle Extending is better than modifying
• Write Code for the Maintainer Code spends more time in use than in development, make it easy to maintain.
• Principle of Least Astonishment Someone reading your code should be surprised as little as possible.
• Single Responsibility Principle A component of code should define a single well-defined task.
• Minimize Coupling Avoid as many dependencies as you can.
• Maximize Cohesion Similar code should be in similar components.
• Hide Implementation Details
• Law of Demeter Components should only communicated with their direct relations.
• Avoid premature optimization! "Premature optimization is the root of all evil" - Knuth
• Code reuse is good
• Separation of concerns Different functionality should overlap as little as possible.
• Embrace Change Code as if you will have to change the projects specs many times before launch. (Hard to practice in a single semester course but very important to maintainable projects.)

The heart of this course

Typically CSS for a project is hacked together. Also JavaScript is so forgiving and simple that things can just work and ignore almost all of these principles. What does it mean to to "minimize coupling" for a CSS design? If you were able to just get your JS code working did you bother to go back and start applying the single responsibility principle?

Reflection Task 1: Which of these did you violate in the projects you turned in yesterday? If I were to ask you to make major changes to the heart of your game how little could you get away with. Make a text file with your answers, including most honored principles and least honored principles for project 2.

Reflection Task 2: How did your CSS project violate these principles? Which of these did you try to consider in your CSS? Which did you least consider? Add this to your text file and email me the reflections for both projects in a single email to yournamehere@js.prof.ninja .

SMACSS

The SMACSS system (the first book in our list of books) is a loose set of guidelines which encourage you to rethink your CSS rules in a more modular and well-engineered way. Specifically he encourages classifying/categorizing your rules into five categories. Then use a naming convention to make it clear what category your rule is:

• Base The default rules for everything in your project. These are the rules that target tags (also tags with pseudo-classes and siblings and such).
• Layout These rules structure the location of your elements that hold your "modules" together. Use a class prefix like .l-block or .layout-left-column.
• Module These are the main, reusable, parts of your design. The sidebars, callouts, captions, etc. These can just be the class names without prefix like .code-sample.
• State These rules describe how your modules and layouts look in a particular state. Hidden, on a small-screen, selected, etc. Use a convention like .is-selected and mix the state rules with module rules like this: .form.is-collapsed.
• Theme These are the very rare rules that override others when you want to re-theme/re-style a page. The SMACSS convention is that they are named the same as other rules but kept in their own this_theme.css file.

I'm not looking to dogmatically assert these rules on you, but I do want you to have some structure to your rules. Also you should think about them a little differently from the perpective of the above principles.

Refactor Task 3: Head to the CSS file for your first project. How are your CSS rules grouped? (My guess is that many are based around the particular elements they are targeting.) Try to pick a couple of rules and refactor them into base, layout, module, and state rules. How many classes did you have to add to the HTML element to get it back to looking correct?

SMACSS from the source Task 4: Head to a page of the SMACSS book and inspect his source and classes. Find his modules, look at his CSS source, see how fine-grained his philosophy is.

SMACSS in the Wild Task 5: Head to http://chriswrightdesign.com/ and inspect his source and classes. This guy has gone on record as a SMACSS promoter so let's see how his classes look and if the rulesets are reusable.

CSS Preprocessors

I now want to show you some of the amazing powers possible with a CSS Preprocessor and also warn you to only use these when they are absolutely needed. There are two main reasons for this:

• CSS Preprocessors add complexity to your codebase. You might not agree with this since the code looks (and truly is) cleaner. However, now your code is tied to another technology that is not as well supported as CSS. When you move on from your project you might have to hire a Stylus expert which is harder to find than a CSS expert. Making a change to your codebase has to be done at the command-line rather than in the stylefile. You might need a "build-process". The beauty has a non-negligible cost, so go vanilla until you can't.
• CSS Preprocessors should eventually be unnecessary and when they are you'll be dated. When you start to work with a preprocessor you become a little weaker as a CSS thinker. The features that made jQuery needed back in the late 00s are what defined the latest Javascript specs. In 5 years most of what makes a preprocessor needed now should be part of the CSS specifications (check those editor's drafts). So if you've grown to need a preprocessor then you will grow to be more and more obsolete. It is always better to push what browsers offer than to try and go around the standards process.

So why learn these things?

The benefits are this (besides less verbose code):

• Variables and Functions (in CSS, how cool)
• Nested rules (some rules for paragraphs and also paragraphs with this class get this extra rule)
• Conditionals (use those variables to decide which rules to use)
• Extends and Mix-ins (my personal favorite: declare a selector to be an extension of other rule sets (and only ship the used ones))
• Prefix-management (use nib to avoid the -webkit, -moz, etc. mess)

Stylus as an example

I like Stylus because it ships with npm and I like Node more than Rails (SASS ships with gem). You can try other preprocessors on your own and play to your heart's content.

Hello Stylus Task 6: Head to Codepen. In the CSS gear icon select the "Stylus" preprocessor. Now use the http://stylus-lang.com/ docs to make a horizontal nav bar.

Stylus Level 2 Task 7: Now split into 5 groups. Each group select one of the bullet points from my list of awesome things about Stylus. Master it, make a sample, share it in chat, present to us what you did.