Hello, I'm Matsubara, a coder at the Coding Factory.
Our coders at Coding Factory (hereafter referred to as CF) code in accordance with CF guidelines unless otherwise specified by the client.
By coding in line with the guidelines, we can maintain a consistent quality for the delivered product, regardless of which coder is in charge of production. Also, when a customer requests additional pages or changes, even if the previous coder is unable to handle them, as long as the same guidelines are used, we can easily analyze the site's structure and begin production smoothly without hesitation.
Coding guidelines serve as both a guide and a guide for coders.
The CF guidelines have been updated repeatedly to make them easier to use, by considering and reflecting any issues or improvements that coders have noticed while actually using the guidelines. Last month, the guidelines underwent a major revision, resulting in version 6.0.1.
This time, I would like to introduce the background and overview of the new CF guidelines.
Why did we update this version?
On October 28, 2014, HTML5 became a recommendation.
W3C (World Wide Web Consortium) vocabulary and associated APIs for HTML and XHTML
https://www.w3.org/TR/html5/
Before that, the rule established by the W3C (World Wide Web Consortium, a non-profit organization that develops web standards) was "Use XHTML1.0 when creating a website." This was then changed to "From now on, use HTML5."
The CSS3 specification is being developed, and new features are being implemented in each browser one after another. Representative features include rounded corners, drop shadows, and gradient decorations, which were previously implemented using images, but can now be reproduced using only CSS in modern browsers.
Another reason is that the requests we receive from our customers have become more diverse.
In addition to the previous projects involving PC and smartphone websites, the proportion of websites using responsive web design has increased.
The CF guidelines also needed to be updated to reflect these changes in the field, so a "Guideline Development Committee" was established.
Guideline Development Committee = 8 active coders
Committee members discussing the guidelines.
At the end of the summer of last year (2015), all the CF coders at that time became members of the committee, and discussions began toward revising the guidelines. Meetings were held every week, and sometimes twice a week.
All of the points raised by the members in the first brainstorming session were important and required thorough discussion. There were so many things to decide that I was a little worried about how thick the guidelines would be.
However, after much discussion, we came to the conclusion that in many cases it would be better not to set rules about this, and the guidelines did not end up being as thick as a dictionary, as I had feared.
If there are rules, you can just follow them, which saves you time and effort. Reducing the amount of work you have to do is a big advantage, but if you set too many rules, you lose flexibility and it becomes difficult to use.
Based on the coders' experiences, we thoroughly discussed what is easier to decide in advance, and what, conversely, becomes difficult to do if you decide on rules. It is difficult to coordinate the work of a large number of people, but I think it was very good that we were able to incorporate the opinions of many coders.
What's new?
The changes can be broadly divided into three areas:
- Newly added items in response to changes in the web environment
- Deletion of items that were previously specified in the guidelines but are no longer necessary
- Class naming rules
The first and second points were expected, but as we started to discuss them, various other improvement proposals were brought up. The one we spent the most time on was the third point, which was about class naming rules based on modern CSS design.
We plan to share specific details in a series of posts in this column in the future.
MATSUBARA Megumi