Code Quality Counts
As a front end developer who tries to keep up with the latest trends, I find it a constant challenge to define my own unique path when building a website or application. The web is an ever evolving environment and there are multiple ways of doing the same thing. This post is meant to discuss the write steps to writing higher quality code that is both understandable by yourself and for other developers. Code that is consistent and legible is always a good thing but keep in mind that it doesn’t always mean the code is valid.
Where to begin
Every developer is different and has their own process of doing things. Where to begin is sometimes the biggest challenge when starting a project. With so many resources available it can be overwhelming at times to make the final decision on what resources to use before moving forward.
You may ask yourself
- Do I start with a framework?
- How about a preprocessing language or task manager?
- Should I use a CMS or develop something custom?
For this, I say, use what works for you. Just because the tool or technology exists doesn’t mean you have to always adopt it. If you can write clear and concise code without all the minifiers, linters, and compilers available then so be it. Sometimes starting from scratch not only helps you become a better developer, but it also eliminates unnecessary code you won’t even use(ahem! Bootstrap...).
Define a process of your own and use that to become faster, more efficient, and less prone to errors. Humans are made to adapt, we like having set schedules and regimens to help us evolve into smarter more advanced beings and it just makes us feel comfortable.
How to write quality code
There are a number of methods available to write clear and concise code. No matter the language many developers come up with guidelines to follow. Below I’ll discuss a few that involve CSS, HTML, and more. I’ll also throw some cool tools and syntax checkers in the mix to help you along your journey.
CSS has come so far in the past few years. New pre-processing languages like Less, Sass, or Stylus make CSS more powerful than ever. With all that power can come some sloppy code. Be sure to utilize a style guide below or create your own so long as it’s consistent and valid.
SMACSS is a style guide used to examine your design process and is a way to fit rigid frameworks into a flexible process. Combining unique and timeless naming conventions for selectors in CSS and ids and classes in HTML is what sets SMACSS apart from other guidelines.
SMACSS CSS contains 5 general categories
- Base - These are basic defaults ( html, body, h1, ul, etc... )
Layout - These divide the page into sections ( Section, Aside, Header, Footer, etc... )
Module - These are reusable classes for design across multiple elements. ( Buttons, Forms, Links, etc... )
Theme - These define things like color or typography across the site.
Writing traditional CSS you can mix and match these categories and still create the same result but you will also likely end up with complex code that is quite hard to read. Grouping your CSS into categories eliminates some of the hassles for you and others down the road working on the project.
SMACSS suggests different naming conventions based on the categories I stated before. Following this convention is optional of course but having one in place is wise for consistency.
- Base - Nothing needed
- Layout —
- State —
is-prefix as in
- Module - Modules make use of the name of
.calloutinstead of trying to prefix each. Related modules would receive a consistent prefix to help keep things organized.
To really understand the value here I invite you to find out more about SMACSS by reading the book.
Almost every element on a website has different visual aspects that get repeated under different circumstances. Cases involving websites branding, color, buttons, borders, and more come to mind. When these different traits or aspects are grouped into a class they become reusable and can be applied to multiple elements on a webpage.
Here’s an example
border: 1px solid #dddddd;
border: 1px solid #dddddd;
border: 1px solid #dddddd;
You might also notice a number of styles in common. Wouldn’t it be better to make use of classes to utilize the same styles across multiple elements? I think so...
If you plan ahead you can write better quality code like this
border: 1px solid #dddddd;
Now all the elements are making use of classes which ARE reusable. There has also been a new class added which is the
.theme class. This class would be applied across each of the other classes within the HTML markup. In our example case, the theme class defines some styles for all of the elements.
This is only a small example of OOCSS. To find out more you can visit any of these sites to really understand the power behind it.
If you don’t take anything away from OOCSS you should at the very least take away the two main principles
- Separate structure from skin
- Separate container and content
CSS guidelines is a document written by Harry Roberts. Harry is the owner/operator of
http://csswizardry.com/, this guy knows his stuff as you can tell from his clientele, knowledge, and case studies.
Harry states A coding style guide (note, not a visual style guide) is a valuable tool for teams who
- build and maintain products for a reasonable length of time;
- have developers of differing abilities and specialisms;
- have a number of different developers working on a product at any given time;
- on-board new staff regularly;
- have a number of codebases that developers dip in and out of.
Following a proper style guide will set new standards for code quality across your team's codebase. A style guide will also provide more consistency within the code and give a developer a sense of familiarity in his work when tackling something new for the first time.
The style guide found at http://cssguidelin.es is the rules Harry follows in his own work. It is his recommendation on establishing clear and concise formatting, spacing, tabs, and more across an entire project. I invited you to read through the guidelines as it’s one I try to uphold to myself.
Harry if you read this, great job and thank you for giving back to the community!
Google paves the way for many web technologies being developed. With so many applications to consider they must have a style guide to keep their platform consistent and clear.
Naming conventions, layouts, sectioning, and commenting are all dually noted within the guide. Check out how Google makes use of their code at Google HTML/CSS Style Guide
This one I hope you have already heard of. A great way to determine if you have coded a valid HTML page is to check it with the W3C Validator. Doing this will help optimize your web page to work across any platform on the web. It will also point you in the right direction if your code is behind on modern standards. While code quality counts, code validity is more important. After all, if your code doesn’t run or function then what’s the point?
This guide documents the proper indentations, rules, spacings, and more to follow for any type of application or service they author. It’s an interesting read if you have the time.
or applications like CodeKit come with this functionality ready to go with a few clicks or lines of code.
Sidekick JS is a completely new service offering the combined functionality of JS Lint and JS Hint plus many more features. Geared towards teams, Sidekick JS fits into any developer's workflow to allow quality code to be the norm. Sign Up today to get notified when Sidekick JS launches.
Quality isn’t always best
Some code can suffer from quality. Just because you use the latest naming conventions or standards doesn’t mean your code is worth a darn. If your code isn’t valid or doesn’t function in the first place then the quality of it is the least of your worries. Always defer functioning over form. While the form is nice and makes us all giddy and psyched, it doesn’t mean crap if your code fails.
The ever debatable “Quotes”
Quotation marks are used in just about any programming language. There is always a debate going on as if to use single quotation marks or double quotation marks. Some style guides mentioned above will tell you one way or another. I try to use only one type but there are some instances where you may need to use both like in PHP. In the end-use what you learned with because you will probably type it naturally without a single thought. Keeping your quotes consistent no matter the type is the end goal.
Keeping it real
Don’t go overboard for quality. Writing good code takes practice and knowledge. Adopt your own techniques as well as others and you can be sure you’ll do fine in the end. Use whatever method works for you. There’s no wrong way to solve a problem so long as the problem is solved. Some may argue against that statement while others may agree. Define a process in your development, stick to it and don’t be afraid of change because it is most certainly going to happen. Adapting and growing is part of being a web professional. I would even argue that the aspect of change is what makes being a developer so great.
Do you use a style guide? If so have you adopted any of the guides mentioned above? Let us know in the comments