└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # :book: Front-End Code Guidelines :computer: 2 | ## A short code guidelines' guide for every front-end developer 3 | 4 | Hello Folks!! Working in Front-end domain from few years I know how important is to have a single source for the code guidelines. Here are some guidelines I learned over years. This is still work in progress. If you have any suggestion, questions or feedback reach me. 5 | 6 | [Website](https://www.codeguidelines.com/) 7 | 8 | ## :golf: Agenda 9 | - [CSS](#agenda) 10 | - [SCSS](#scss) 11 | - [HTML](#html) 12 | - [JAVASCRIPT](#javascript) 13 | - [IMAGES](#images) 14 | - [TOOLS](#tools) 15 | 16 | ## :zap: Summary 17 | - Consistency 18 | - Code writing style 19 | - Readability 20 | - Performance 21 | - Embracing the new features 22 | 23 | ## CSS 24 | - **Code division** : divide the code into modules and write CSS accrodingly. Keep the Global , base, and reset CSS on top always. 25 | - **Grouping** : Group the same style and modules together 26 | - Use CSS3 variables and write them on the top. 27 | - Do not turn off `outline` and `focus` property. They are important for accessibility 28 | 29 | :-1: **Bad** 30 | ```css 31 | *{ outline: 0 } 32 | ``` 33 | 34 | :+1: **Good** 35 | ```css 36 | *{ focus: none } 37 | ``` 38 | - Use pre-processors such as `SCSS`, `LESS`. 39 | *WHY?* Pre-processors provides you lot of features which are missing from CSS. It helps 40 | you in writting the modular, and manageable code. Such as , mixins(), functions(), placeholders etc. 41 | 42 | - Aviod using `@import` in CSS. 43 | *WHY?* @import behind the scene is doing HTTP request and bad for the performance. 44 | 45 | - Class Name Methodology : use `BEM, SMACS` or you can have your own Methodology too. The underline message is to have pattern to write the css. 46 | *WHY?* When you have different developers working on same project, there will always be visible difference in naming and coding guidelines. Especially classnames. So, by using some className Methodology such as BEM, it will restrict the devs 47 | to follow one single way of decalring the classnames. 48 | 49 | - Either use `_` or `-` or `camelCase`. Do not merge all three way together Which is the best? Depends on the methodology you are going to follow. 50 | 51 | :-1: **Bad** 52 | ```css 53 | .header-title .header_text .highlightText{ color: #000; } 54 | ``` 55 | 56 | :+1: **Good** 57 | ```css 58 | .header-title .header-text .highlight-text{color: #000;} 59 | 60 | .header_title .header_text .highlight_text{color: #000;} 61 | 62 | .headerTitle .headerText .highlightText{color: #000;} 63 | ``` 64 | 65 | - No space between the key and colon and 1 space after the colon. 66 | 67 | :-1: **bad** 68 | ```css 69 | .header-title { color : #000;} 70 | ``` 71 | 72 | :+1: **Good** 73 | ```css 74 | .header-title {color: #000;} 75 | ``` 76 | 77 | - Do not forget to put `;`. 78 | - Class names should start with lower case and avoid starting the name with numericals. 79 | 80 | :-1: **bad** 81 | ```css 82 | .Header-title{color: #000; } 83 | ``` 84 | ```css 85 | .10margin{color: #000;} 86 | ``` 87 | 88 | :+1: **Good** 89 | ```css 90 | .header-title{ color: #000;} 91 | ``` 92 | 93 | ```css 94 | .margin10{ color: #000;} 95 | ``` 96 | 97 | 98 | - Multiple properties always come in multiple lines. 99 | 100 | :-1: **bad** 101 | ```css 102 | .headerTitle .headerText .highlightText{color: #000;} 103 | ``` 104 | 105 | :+1: **Good** 106 | ```css 107 | .headerTitle, 108 | .headerText, 109 | .highlightText{color: #000;} 110 | ``` 111 | 112 | - No measurement unit after `0`. 113 | 114 | :-1: **bad** 115 | ```css 116 | .headerTitle{margin: 0px;} 117 | ``` 118 | 119 | :+1: **Good** 120 | ```css 121 | .headerTitle, 122 | .headerText, 123 | .highlightText{color: #000;} 124 | ``` 125 | 126 | - `font-weight : bold` should be in numeric rather than 'bold', 'normal'. Reason is the web engine convert normal to 400. Basicailly convert string to numeric. 127 | 128 | 129 | :-1: **bad** 130 | ```css 131 | .headerTitle{font-weight: normal;} 132 | ``` 133 | 134 | :+1: **Good** 135 | ```css 136 | .headerTitle{font-weight: 200;} 137 | ``` 138 | 139 | 140 | - Color values should be in lowercase. 141 | 142 | :-1: **bad** 143 | ```css 144 | .headerTitle{text-transfrom: UPPERCASE;} 145 | ``` 146 | 147 | :+1: **Good** 148 | ```css 149 | .headerTitle{text-transfrom: uppercase;} 150 | ``` 151 | 152 | - `RGBa` is faster than `hexa`. 153 | - While implementing the colors in CSS, use the chrome tools to test the contrast ratio for accessibility. 154 | - Do not control content from CSS such as uppercase, lowercase until it is important. 155 | - Avoid adding `!important`. 156 | - Identify the critical CSS of your pages and place it on the head 157 | - Class names should be very clear. But longer classnames will affect the size of bundle.So, choose them wisely. 158 | - Classname should be self explanatory such as: `.header-title` , `.header-body`. 159 | - If the style is going to be used globally do not bind it with the any module. Instead of writing `.header-title-error` write `.error` and so on. 160 | 161 | :-1: **bad** 162 | ```css 163 | .headerTitle .error{...} 164 | ``` 165 | 166 | :+1: **Good** 167 | ```css 168 | .error{...} 169 | ``` 170 | 171 | - Use the build packages to minify the css files. 172 | - Put comments only when and where it is required. 173 | - Use single-quotes when targeting attributes `input[‘required’]`. 174 | 175 | :-1: **bad** 176 | ```css 177 | input["required"]{...} 178 | ``` 179 | 180 | :+1: **Good** 181 | ```css 182 | input[‘required’]{...} 183 | 184 | ``` 185 | or 186 | 187 | ```css 188 | input[required]{...} 189 | ``` 190 | 191 | - Use inbuild attributes over making classes. 192 | - Avoid more than 3 nesting as specifity will be slow. 193 | 194 | :-1: **bad** 195 | ```css 196 | .header .header-content .header-left .header-title span{...} 197 | ``` 198 | 199 | :+1: **Good** 200 | ```css 201 | .header 202 | .header-title 203 | span{...} 204 | ``` 205 | - Complier arranges the css properties alphabetically. If you can also do same, good.By doing this you are saving complier work. 206 | - Short-hand properties vs writing explicit property. `padding:0 10px;` will convert to `padding-top:0;` `padding-bottom:0;` and so on. So, define `padding-left:10px;` `padding-right: 10px;`. 207 | 208 | :-1: **bad** 209 | ```css 210 | header{padding:10px 10px 0 30px;} 211 | ``` 212 | *the above will result in following css* 213 | 214 | ```css 215 | header{ 216 | padding-top:10px; 217 | padding-left:10px; 218 | padding-bottom:0; 219 | padding-right:30px; 220 | } 221 | ``` 222 | 223 | :+1: **Good** 224 | ```css 225 | header{ 226 | padding-top:10px; 227 | padding-left:10px; 228 | padding-right:30px; 229 | } 230 | ``` 231 | *the above will result in following css* 232 | 233 | ```css 234 | header{ 235 | padding-top:10px; 236 | padding-left:10px; 237 | padding-right:30px; 238 | } 239 | ``` 240 | 241 | - Avoid styling HTML tags unless you are sure it will be like that. 242 | 243 | :-1: **bad** 244 | ```css 245 | header{...} 246 | ``` 247 | :+1: **Good** 248 | ```css 249 | .header{ 250 | ... 251 | } 252 | ``` 253 | 254 | - **Typography**: always have fall back font-family 255 | - Use `rem` for text, px for spacing, `%` for widths 256 | - Responsive – use media queries. 257 | - Polyfills for auto-prefixer 258 | - Use single-quotes 259 | - `Calc()` function 260 | - Use CSS3 features such as `flex`, `css grids`, `@support`. 261 | - Use `css3 gradients` etc over images of gradients. 262 | - CSS Animations over JS animations. 263 | - To avoid the opacity issues cross browser use colors. 264 | - Focus on progressive enhancement. 265 | 266 | ## SCSS 267 | - Do not write scss in one file 268 | - Use the modular file approach. 269 | - Create the SCSS files for - `Base, varibales, components, typography , layout` etc. 270 | - Avoid using color name in color variables - `$bright-blue: blue`. Think of a case when you get a change request to replace blue color with red. You will end up assigning `$bright-blue: red` or create another variable `$bright-red: red` and change its usage across all files. 271 | - Unless and until you don't have the requirement to have sepreate CSS files, import all the SCSS files into one SCSS file. 272 | - SCSS is very popular because it supports nested css. This helps in writing better organzied code and avoid nesting exceed more than 3 level 273 | - Use `&` where ever you are refering the parent. 274 | - Use `SCSS functions` to make the colors dark, light etc 275 | - Use SCSS `mixins`. They are super helpful to have consisitency in your code. 276 | - Use `placeholder`for re-use and inheritance but be careful with placeholders. It can bloat css. 277 | - While using SCSS `variables` write default values. 278 | - Do not forget to use SCSS variables. Though now CSS3 also provide variables but to have cross-browser support, use SCSS variables. 279 | - If the value will be used with `calc()` do not make the scss varaibles 280 | - Use SCSS `functions`. 281 | - Keep eye on bloating css generation 282 | 283 | ## HTML 284 | - Use HTML5 285 | - Use **semantic code** 286 | - **Validate** your HTML. 287 | - Use right tag for right thing. Eg-Use for footer content instead of using div and giving it a class of footer, same is true for header and main. If there is a redirectionanchor if there is an action button. Cart?? 288 | - when there is clear understanding about the what is section and div is for division of the page. 289 | - Avoid inline css & javascript. 290 | - Always have mobile first approach. Use viewport meta tag. 291 | - Use appropriate menifest file for PWA. 292 | - Do not put block elements into the inline elements. 293 | - Use block elements to wrap around every logical section of your page. Block elements provide structure to your page. 294 | - Use p tag for content. 295 | - Keep your HTML clean. Do not add extra tags and classes 296 | - Do not add unnecessary IDs or classes 297 | - Always have a wrapper of your HTML page. 298 | - While creating a module which is not supported in HTML. Add role=””. 299 | - Follow the Heading hierarchy. 300 | - Put defer and async with blocking scripts, if possible include scripts as late as possible (down in body tag) 301 | - While writing footer text or legal text , use small tags 302 | - Avoid using the bold and italic from markup. These can be handle by css classes. 303 | - If you are sure about the HTML structure then avoid adding css classes at every level. You can write the style by targeting the parent level only 304 | - Doctype is important. Do not avoid them. 305 | - With Forms use legend. 306 | - Use `novalidate` to disable default validation from browser, when implementing custom validations 307 | - In input fields use placeholder property but use label too for accessibility. 308 | - Use `alt` text for `` 309 | - Hiding text from the page is not good practice. 310 | - Add move to top functionality if your website has longer scroll. 311 | - Do not just rely on icons, add the label, alt, and title tag to make them accessible. 312 | - Use semantic HTML for better SEO & Accisibility (secion, article, header, footer, aside, h1 to h6, strong, em) 313 | - For custom tags use Uppercase for tagname. (e.g. 314 | 315 | ## Javascript 316 | - Always use a Javascript pattern to write your code. (i.e. Revealing Module Pattern) 317 | - Use `ES6+` syntax. 318 | - Where ever you need this context use `fat-arrow` or `Lambda` functions. (Caution: do not try to replace your existing functions with fat arrow syntax if it is using `this, super, arguments` or being called with `new` operator. 319 | - `Constructor` should have all the initial setup values 320 | - In your JS you should have minimal DOM manipulation. If required, use document fragments or bulk update. 321 | - Avoid hardcoding the values in Javascript. 322 | - Values that are not going to change should be declared with const such as `API` Keys and the name should be always in uppercase. 323 | - Should have a constant file in your project. 324 | - Create constant objects using `Object.freeze(...)` 325 | - Immutability is important, use Array & Object methods which does not mutate the original instance (e.g. splice vs slice) 326 | - All the `API Keys` and config key(s) should be in config files. 327 | - Do not commit any type of credentials in code files. 328 | - In Javascript world, do not forget `semi-colon`. 329 | - Use indentation for code readbility. Setup your IDE/Editor to use a uniform setting (2 or 4 spaces/tabs). 330 | - Add comments only when required 331 | - For performance, cache the length of the arrays and objects. Espcially if your code require iteratation on it. 332 | - variables and results,use data-types such as `arrays` and `objects` wisely. 333 | - Identify which data-type would be better in which operation. Eg: deleteing elements from array could be expensive as compared to the objects. 334 | - While creating the methods or variables name, use same pattern througout your code. 335 | - Avoid using many loops. Loops are expensive. Look into data and understand if `for() , for..in(), for—each() or while` could be better 336 | - Avoid nesting of loops if possible. 337 | - Write error handling code. 338 | - Use build tools – `Wbpack`, `ParcelJS` etc 339 | - Use `Babel/Typescript` , when you are using ES6+. 340 | - While doing the build always change the version number in your `package.json`. 341 | - Avoid adding/deleting style from Javascript.Instead use class names to add / remove styles. 342 | - Javascript can also lead to security issues. While writing your code especially if you are creating APIs keep the security testing in mind. 343 | - Write reusable code. 344 | - Avoid polluting Global scope 345 | - For block level scope always use `const or let`. 346 | - Use shorthand syntaxes only when necessary. Code readability is important too 347 | - Use strict mode. If not using `ES6+ or Typescript`. 348 | - Use `array.push()` to add values in array rather than any other way. 349 | - Use functional programming. 350 | - Clean the `console.log()` and `alert()` before the deployment. 351 | - Make use of `Tree shaking` and `chunk-loading` by using build tool like Webpack to break the long code files. 352 | - Use modulas `import/export` to write modular javascript. 353 | - As Javascript don't have strict garbage collection, you need to be careful about what all is getting into the memory unused. Use `weakmap` or `weakset`. 354 | - Use strict equal signs while comparing the values.`===` instead of `==`. 355 | - Always use `Prettier` or `ESLint` to format your code. 356 | - Use `objects` or `arrays` literals over using new keyword 357 | - Use `defer` or `async` for not blocking the browser. 358 | - Use `async/await` over `promise`. 359 | - While working with API data, always check if data exists or not. 360 | - Have one space in the `function()` signature. 361 | - Prefer `function()` over `variable functions`. As variable functions get hoist. 362 | - While using if, while code block the bracket should come in same line. 363 | - Use the shorthand property for defining the object property. eg: if key and value has same name. You can drop the value. 364 | - Do not use reserved keywords - such as `arguments`, `catch`, etc. 365 | - While checking if the object exist or not, do not check for `!null` only. 366 | - Avoid using `object.assign()`. Consider using `spread` operator. 367 | - use `single quotes` for the string 368 | - Spread the code into multiple lines. 369 | - Use `destructuring`. 370 | - Use `map` & `reduce` function for generating multiple values & single accumulated value respectively. 371 | - Do not use `__proto__` directly. 372 | - Use `bind` function to pass dynamic context for `this`. 373 | - Use array index in logic carefully as deleting any element would change index sequence and can have side effects. 374 | 375 | 376 | ## Images 377 | - Use SVG over `png, jpeg` etc 378 | - If the image is the part of the content,do not make it the part of the JS and CSS. Keep it on markup. 379 | - Image should have the `alt` and `title` tags. 380 | - Use a library like `font-awesome` for icons 381 | - Use image sprite for the small images. 382 | - Take advantage of lazy-loading while working on the site with heavy images. 383 | - Use `correct tags figure, img`. 384 | - Add `captions` , when required. 385 | - Compress `jpeg` files using available tools, it trims off un-necessory metadata 386 | 387 | ## Tools 388 | - [Lighthouse](https://developers.google.com/web/tools/lighthouse/) 389 | - [caniuse.com](https://caniuse.com/) 390 | - [contrastratio](https://webaim.org/resources/contrastchecker/) 391 | - [Webpagetest](https://www.webpagetest.org/) 392 | - [Frontend tools](http://frontendtools.com/) 393 | 394 | ## Reactsjs 395 | :construction: Coming soon 396 | 397 | ## UX 398 | :construction: Coming soon 399 | 400 | ## SEO 401 | :construction: Coming soon 402 | 403 | ## Accessibility 404 | :construction: Coming soon 405 | 406 | ## :heart: Contributions 407 | Please raise the PR to contribute. 408 | --------------------------------------------------------------------------------