Hero Image

Foundation

Dev standards

At Svenska Spel, we have developed guidelines for how we write our code. We try to follow the standards that are generally accepted in the open source community with certain adaptations for our development stack.

Shared policies and guidelines

Everyone that works with development should have been educated about the development process as part of their onboarding. If you haven't or if you have any questions ask your Team Coach.

Here are a few links for reference.

Utvecklingsprocessen (Internal link)

Beslut om ändring av informationstillgång - Regler och riktlinjer (Internal link)

Process UX-Utv (Internal link)

Checkout the trinidad SDK for more documentation (Internal link)

Javascript code standard

We follow all of the javascript coding standards and recommendations proposed by the Javascript community and Google. We use ESLint to make sure these standards are followed. EcmaScript Linter will be run on build servers (Jenkins) to verify the code but should also, if possible, be run during development to catch errors and divergences from the standard early on.

  • Files should be named after its function or class.

  • Always use lowercase in filenames and use - as a divider between words.

  • Camel-case should be used in code (function/classes/variables etc)

  • Filename: form-validation-for-username-and-password.js

  • Code: formValidationForUsernameAndPassword = function() {};

  • Always use namespaces. Start with svs followed by module then the function.

  • svs.lotto.collection.boards

  • svs.lotto.models.board

Bleeding edge language features (ES6)

Anyone may use language features that are natively supported in all browsers and/or transformed by Babel during asset build.

Not sure what actually works? Consult caniuse.com and the Babel documentation. Test the language feature in browsers that must be supported.

Polyfills

For performance reason we have opted to only use polyfills for a few features that we fund to be the most important. At the moment the following features have polyfills.

  • Promise
  • Async / Await

Documentation

Javascript code is documented according to the JSDoc format.

Documentation must be made on module, file and function level, which means that every javascript-file should start with a description of that file and the authors.

/**
* Handle user session and sessionstore.
*
* @author firstname.lastname@svenskaspel.se (Firstname Lastname)
*/

Every publicly exposed function should be described with it's purpose, the input parameters and return-datatype.

/**
* Setup the session from a usersession received after a login to Jupiter.
* We adding user-property, save-function, and more to the session.
* @param {Object} userSession A usersession received after a Jupiter login.
* @return {Object} Logged in session.
*/

HTML code standard

Write each new element on a new line and indent with 2 spaces for each level. Always use double quotes <span class="badge">Test</span> around arguments.

Use lowercase. Do not write: <A HREF=""> </A> Write: <a href=""> </a>

Semantics: Use the right elements for the right thing. Div tags should be used for block elements and span tags for styling inline elements etc. Tables are perfectly ok to use but only for tabular data as results or statistics. Do not use tables for layout. Do not type type="text / css" or type="text / javascript" when linking in css / javascript, it is not needed in HTML5 and also works well in older browsers.

Availability

Images and other graphic elements

It is important to write an alternative (alt) text for all types of media such as images, flash and video, etc. so that browsers that do not display images and search engines can understand what media we are displaying.

WAI-ARIA

ARIA stands for Accessible Rich Internet Applications and makes more advanced web applications available to more users. If we e.g. need to create a button with a div tag, the browser and especially not the screen reader do not know that it is a button. It is also not possible to make a mistake to the button.

With ARIA you can describe what the element is and its condition etc. eg: <div role="button" aria-pressed="false">Play here</div>.

Tabindex

If we also want to make the button available via the keyboard, we add tabindex: <div role="button" aria-pressed="false" tabindex="0"> Play here </div>. Then the button becomes available in the usual tab order.

If for some reason we do not want to be able to tab to an element, it is possible to use tabindex = "- 1" eg: <input type="text" tabindex="-1" value="Username" disabled="disabled" /> .

Read more:

Accessible Web 2.0 Applications with WAI-ARIA · An A List Apart Article Accessible Rich Internet Applications (WAI-ARIA) 1.0 Web Content Accessibility Guidelines (WCAG) 2.0

Microformats

Microformats are used to describe what content on the page really is so search engines and other applications understand what kind of data it is. Always try to apply microformats whenever possible.

Examples of what contact information for a person might look like:

<div id="hcard-First-name-Last name" class="vcard">
  <span class="fn">First Name Last Name</span>
  <div class="org">Svenska Spel</div>
  <div class="adr">
    <div class="street-address">Norra Hansegatan 17</div>
    <span class="locality">Visby</span>
    <span class="postal-code">621 80</span>
  </div>
</div>

Read more:

Microformats Microformats: What They Are and How To Use Them | Smashing Coding Rich snippets (microdata, microformats, RDFa, and Data Highlighter) - Webmaster Tools Help

Validation

Validate your code before you check in!

Read more: The W3C Markup Validation Service WAVE Web Accessibility Tool

Other

Doctype

If you do not specify a doctype, or if you specify an error, the page risks running in compatibility mode.

Today, html5-doctype is used on svenskaspel.se: <!DOCTYPE html>

Character encoding

In the same way as with doctype, character coding must also be specified. Today we use ~~ iso-8859-1 on svenskaspel.se, but in the future the idea is that we will use ~~ UTF-8. <meta charset ="utf-8">

Read more:

Handling character encodings in HTML and CSS

CSS / LESS standard

Selectors

Don’t use id’s and js- prefixed classes in selectors. Keep specificity low by using unique class-names.

.btn {
  display: inline-block;
  padding: @margin-base;
  height: 40px;
}

.btn-250 {
  min-width: 80px;
}

.btn-300 {
  min-width: 126px;
}

.btn,
.btn-game,
.btn-primary,
.btn-info,
.btn-success {
  border: 1px solid @grey-200;
}

Read more:

Keep your CSS selectors short – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Robert…

Properties

Group properties by

  • Positioning (top, left, position, float etc)
  • Box-model (height, width, padding, margin, display etc)
  • Text (font-size, color, line-height etc)
  • Other visual properties (background, border)
  • CSS3 (box-shadow, border-radius etc)
  • Use mixins for prefixed values
  • Always use variables or mixins for colors, font-sizes, z-index etc.
  • Do not use units after 0 values
  • Never use !important
.btn {
  display: inline-block;
  padding: @margin-base;
  height: 40px;
  font-size: .f-300();
  line-height: 13px;
  text-align: center;
  vertical-align: middle;
  border: 1px solid transparent;
  outline: none;
  .border-radius(2px);
  -webkit-appearance: none;
}

Components

  • Build reusable components according to OOCSS
  • Separate layout and design
  • Use the component name as class for layout (positioning and box-model)
  • Use the component name as prefix for design classes (text, other and CSS3)
  • Components should always be independent by outer styling
.panel {
  padding: @margin-base;
  margin-bottom: @margin-base;
}

.panel-default {
  background: @white;
  border: 1px solid @grey-200;
}

.panel-inverted {
  background: @grey-700;
  border: 1px solid @grey-600;
}

Read more:

http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code http://csswizardry.com/2011/09/the-nav-abstraction/

The ‘island’ object – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts

An Introduction To Object Oriented CSS (OOCSS) - Smashing Magazine

Files

  • Split large files to small well defined files
  • Include files in controller
  • Only use @import for mixins and variable files

Code linting

To help write better code we are using linters to analyze source code and flag syntactic and stylistic errors, and suspicious constructs. The linters are enforced and no code that does not pass the liners can be merged.

Tools

SonarCube

Javascript coding standards gets validated by the merge and deployment processes. Code coverage and quality are checked by SonarQube.

ESlint

ESLint is used to check that coding standards are followed in .js, .jsx and .es6 files. The trinidad-eslint (Internal link) npm module is an ESlint-plugin extending ESlint with Svenska Spel set of rules, react rules and Svenska Spel own defined rules. If a rule is defined to error, the make finish will stop. If rules are defined as warning, make finish will stop if --max-warnings limit is exceeded.

SVS-lint

Runs test that the code follows coding standards defined by us except for .js, .jsx and .es6 files. When framework or components change implementation, if possible, a test checking for the outdated way of doing things. Tests will be run as a step during make finish. If a test is defined as warning a message will be shown. If defined as error make finish will stop.

Stylelint

Svenska Spel is using Stylelint to do static analysis of our CSS with the help of our Stylelint config which you can find here: https://git.svenskaspel.se/node/stylelint-config-svs

Different ways to run the linters

make finish

This command should always be run before a feature branch is ready to merge, however it also installs node modules, runs tests, etc. and takes a lot of time.

npm run lint

This command runs the linter for javascript files the entire projekt.

npm run lint_stylelint

This command runs the linter for css/less files in the entire projekt.

If you want to run the liner for a specific file or files provide the path in the command. E.g

npm run lint modules/casino/assets/javascripts/*

Disabling linter

In some situations it is necessary to disable a certain linter rule. This should only be done when its not possible to rewrite the code to conform to the rules. E.g.

// eslint-disable-next-line no-unused-expressions
item[0].offsetHeight; // Trigger rendering in iOS

For javascript see "Disabling Rules with Inline Comments" in the documentation https://eslint.org/docs/user-guide/configuring

For style lint (css/less) see "Turning rules off from within your CSS" in the documentation https://github.com/stylelint/stylelint/blob/master/docs/user-guide/configuration.md

Related

Hero Image

Getting started

Developing

Hero Image

Getting started

Whats new

Hero Image

 

Components