O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

HTML5, CSS, JavaScript Style guide and coding conventions

4.504 visualizações

Publicada em

Coding conventions are style guidelines for any programming language. As, we are growing ourselves rapidly in learning new technology, the need for learning of the coding standards and conventions for the same language also arises.
So, here let us try to learn some coding guidelines for few frontend languages.

Publicada em: Software

HTML5, CSS, JavaScript Style guide and coding conventions

  1. 1. HTML5, CSS, JavaScript Style guide and coding conventions HTML5, CSS, JavaScript Style guide and coding conventions Priyanka Wadhwa Software Consultant Knoldus Software LLP Priyanka Wadhwa Software Consultant Knoldus Software LLP
  2. 2. Agenda ● Why we need coding Standards? ● HTML5 coding conventions ● CSS style guide ● JavaScript Coding standards ● Why we need coding Standards? ● HTML5 coding conventions ● CSS style guide ● JavaScript Coding standards
  3. 3. What is a need for coding standards ? Problem When we learn a new language, we begin to code in a specific style. A style we want and not the one that has been suggested to us. Now what? ➢ Can the other person actually read your code? Is it spaced out clearly? ➢ Will he be able to work out what’s happening without needing to look at every line? ➢ Will he be able to know how and why are you commenting the work? ➢ And many more questions may arise…
  4. 4. Need for coding standards Solution Coding conventions are style guidelines for programming. A coding standards document tells developers how they should write their code. Instead of each developer coding in their own preferred style, they should write all code to the standards outlined in the document. Large projects need to be coded in a consistent style – Not just to make the code easier to understand, but also to ensure that any developer who looks at the code will know what naming conventions say and what should he expect from the entire application.
  5. 5. HTML5 coding conventions
  6. 6. HTML5 coding conventions ● HTML5 doctype Enforce standards mode and more consistent rendering in every browser possible with this simple doctype at the beginning of every HTML page. <!DOCTYPE html> <html> <head> </head> </html> ● Language Attribute A lang attribute is required to be specified on the root html element, giving the document's language. <html lang=”en-us”> <!→-→--> </html>
  7. 7. ● Character encoding Ensure proper rendering of your content by declaring an explicit character encoding. <head> <meta charset=”UTF-8”> </head> ● Internet Explorer compatibility mode Internet Explorer supports the use of a document compatibility <meta> tag to specify what version of IE the page should be rendered as. <meta http-equiv=”X-UA-Compatibile” content=”IE=Edge”> ● CSS and JavaScript includes <link rel='stylesheet' href='guide.css'> <style>/* …… */</style> HTML5 Coding conventions
  8. 8. ● Attribute order As per the standards, we are required to follow the following order of HTML attributes - ➢ class ➢ id, name ➢ data-* ➢ src, for, type, href, value ➢ title, alt ➢ role, aria-* <a class=”….” id=”…..” data-toggle=”model” href=”#”> Example link </a> <img src=”...” alt=”...”/> HTML5 Coding conventions
  9. 9. ● Boolean attributes Requires no declaration. <input type=”text” disabled> <input type=”checkbox” value=”1” checked> <select> <option value=”1” selected>1</option> </select> ● Reducing markup Produce less HTML, avoid superfluous parent elements when writing HTML. <span class=”avatar”> <img src=”...”> </span> can be re-written as - <img class=”avatar” src=”...”> HTML5 Coding conventions
  10. 10. Some more basic standards - ● Always use the alt attribute with images. It is important when the image cannot be viewed. ● Try to avoid code lines longer than 80 characters. ● Spaces and equal signs - HTML5 allows spaces around equal signs. But space-less is easier to read, and groups entities better together. ● Use the attributes name in lower case letters. ● Close each and every HTML elements even empty HTML elements also. . HTML5 Coding conventions
  11. 11. CSS style guide
  12. 12. CSS style guide Am I following the correct coding conventions here?
  13. 13. CSS style guide Am I following the correct coding conventions here? And what about me?
  14. 14. CSS style guide Am I following the correct coding conventions here? And what about me?
  15. 15. CSS style guide Am I following the correct coding conventions here? And what about me? Let's find out the correct way of coding CSS , following the correct coding conventions.
  16. 16. CSS style guide Syntax ● Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment. ● When grouping selectors, keep individual selectors to a single line. ● Include one space before the opening brace of declaration blocks for legibility. ● Place closing braces of declaration blocks on a new line. ● Include one space after : for each declaration. ● Each declaration should appear on its own line for more accurate error reporting. ● End all declarations with a semi-colon. The last declaration's is optional, but your code is more error prone without it. ● Comma-separated property values should include a space after each comma (e.g., box- shadow).
  17. 17. CSS style guide ● Don't include spaces after commas within rgb(), rgba() values. This helps differentiate multiple color values from multiple property values. ● Don't prefix property values or color parameters with a leading zero (e.g., .5 instead of 0.5 and -.5px instead of -0.5px). ● Lowercase all hex values, e.g., #fff. Lowercase letters are much easier to read. ● Use shorthand hex values when available, e.g., #fff instead of #ffffff. ● Quote attribute values in selectors, e.g., input[type="text"]. They’re only optional in some cases, and it’s a good practice for consistency. ● Avoid specifying units for zero values, e.g., margin: 0; instead of margin: 0px;.
  18. 18. CSS style guide ● Declaration order Following properties should be grouped together : ➢ Positioning (position, top, right) ➢ Box model (display, float, width, height) ➢ Typographic (font, line-height, color) ➢ Visual (background-color, border) ➢ Misc (opacity) Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.
  19. 19. CSS style guide ● Don't use of @import From a page speed standpoint, @import from a CSS file should almost never be used, as it can prevent stylesheets from being downloaded concurrently. There are occasionally situations where @import is appropriate, but they are generally the exception, not the rule.
  20. 20. CSS style guide ● Media query placement ➢ Bundling the media query in a separate file is not preferable. ➢ Decision to add it at the end of the CSS file or placing close to their relevant rule sets depends upon your CSS file.
  21. 21. CSS style guide ● Single declarations Consider removing line breaks for readability and faster editing. Any rule set with multiple declarations should be split to separate lines. Single-line declaration Multi-line declaration
  22. 22. CSS style guide ● Shorthand notation Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include: ➢ padding ➢ margin ➢ font ➢ background ➢ border ➢ Border-radius Often times we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.
  23. 23. CSS style guide ● Comments Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
  24. 24. CSS style guide ● Class names Do keep the following points in mind before giving class names to the HTML elements - ➢ Keep classes lowercase and use dashes (not underscores or camelCase). Dashes serve as natural breaks in related class (e.g., .btn and .btn-danger). ➢ Avoid excessive and arbitrary shorthand notation. .btn is useful for button, but .s doesn't mean anything. ➢ Keep classes as short and succinct as possible. ➢ Use meaningful names; use structural or purposeful names over presentational. ➢ Prefix classes based on the closest parent or base class. ➢ Use .js-* classes to denote behavior (as opposed to style), but keep these classes out of your CSS. Class to denote behavior : .js-calculate-price Some good class names : .sequence { … }, .sequence-header { … }, .important { … } Not so good class names : .s { … }, .header { … }, .red { … }
  25. 25. CSS style guide ● Selectors Keep the following in mind before using nested CSS selectors - ➢ Use classes over generic element tag for optimum rendering performance. ➢ Avoid using several attribute selectors (eg., [class^="..."]) on commonly occurring components. Browser performance is known to be impacted by these. ➢ Keep selectors short and strive to limit the number of elements in each selector to three. ➢ Scope classes to the closest parent only when necessary (e.g., when not using prefixed classes).
  26. 26. CSS style guide ● CSS quotations Use single ('') rather than double ("") quotation marks for attribute selectors or property values. Do not use quotation marks in URI values (url()). @import url(“//www.google.com/css”); html { font-family: “open sans”, arial, sans-serif; } @import url(//www.google.com/css); html { font-family: 'open sans', arial, sans-serif; }
  27. 27. JavaScript coding standards
  28. 28. JS coding standards ● Variable Names Use of letters with camelCase in naming the variables. ✔ firstName = “Knoldus”; ✔ price = 9.90; ✗ middlename = “Softwares”; ● Spaces around operators Spaces should be used to differentiate operators and also after commas. ✔ var x = y + z; ✔ var values = [“knoldus” , “software”]; ✗ var values=[“knoldus”,“software”];
  29. 29. JS coding standards ● Code Indentation 4 spaces for indentation of code block - function toCelsius(fahrenheit) { return (5 / 9) * (fahrenheit – 32); } * Do not use tabs for indentation Different editors may treat it differently. ● Statement Rules Simple statements end with a semicolon. Like – declaring a variable var person = { firstName: “Knoldus”, lastName: “Softwares”, };
  30. 30. JS coding standards Complex/ compound statements must follow the following - ➢ Opening bracket at the end of first line, ➢ Space before opening bracket. ➢ Closing bracket on a new line, without leading spaces. ➢ And, complex statements doesn't end with a semicolon. function tocelsius(fahrenheit) { return (5 / 9) * (fahrenheit - 32); } * same applies for the loop and conditional statements.
  31. 31. JS coding standards ● Object Rules - ➢ Placing opening brackets on the same as the object name. ➢ Using colon plus one space between each property and its value. ➢ No adding of comma at the last property-value pair. ➢ Placing of closing brackets on a new line, without leading spaces. ➢ Never forget to end an object with a semicolon. var person = { firstName: "Knoldus", lastName: "Softwares" }; Short objects can be compressed and written in one line using the spaces only between their properties - var person = {firstName:"Knoldus", lastName:"Softwares"};
  32. 32. JS coding standards ● Line length < 80 characters If a javascript statement does not fit on one line, then the best place to break it, is after an operator or comma. document.getElementById("knolx").innerHTML = "Hello Knolders."; ● Naming Conventions Remember to maintain consistency in the naming convention for all your code. ➢ All variables and functions must be in camelCase. ➢ Global variables and Constants to be written in UPPERCASE.
  33. 33. JS coding standards ● Line length < 80 characters If a javascript statement does not fit on one line, then the best place to break it, is after an operator or comma. document.getElementById("knolx").innerHTML = "Hello Knolders."; ● Naming Conventions Remember to maintain consistency in the naming convention for all your code. ➢ All variables and functions must be in camelCase. ➢ Global variables and Constants to be written in UPPERCASE. Should we use hyp-hens, camelCase or under_scores in variable names?
  34. 34. JS coding standards Hyphens (-) ● HTML5 attributes can have hyphens (data-element, data-count). ● CSS uses hyphens in property names (background-color, padding-left, font-size) ● JavaScript names does not allow use of hyphens. As they can conflict with subtraction operator. Underscores ( _ ) ● Underscores (date_of_birth) are mostly used in databases or in documentation. So, we prefer not to go with using underscores. PascalCase ● It is often used by C Programmers. CamelCase ● This is used by javascript, jquery and in various JS libraries.
  35. 35. References ● https://google.github.io/styleguide/htmlcssguide.xml ● http://codeguide.co ● http://www.w3schools.com/js/js_conventions.asp ● http://www.w3schools.com/html/html5_syntax.asp
  36. 36. Thank you :)Thank you :)

×