General

• [ ] When you are refactoring, make a tiny change, run the app to make sure nothing broke. One tiny change at time.

HTML

• [ ] Ids: camelCase, use IDs in our JS selectors (querySelectors)
  • document.querySelector(‘#someID’) OR document.getElementById(‘someID’)
  • classList.add / remove is totally fine in JS
• [ ] Classes: kebab-case, use classes in our CSS selectors
• [ ] Indentation - check it, then check it again. Double check your nested elements.
• [ ] Img elements - make sure all images have an alt attribute
• [ ] Limit the use of div and span
  • Should only be used for styling purposes. Is this div adding any meaning/content to the page? Or is it just for the eye?
  • div should be used like a box/section when you want to style that box area or apply styling (usually layout, like flexbox) to the children inside of that box/div
  • if your div only contains one child element, get rid of div and apply the styling directly to the child element itself
  • if your div is directly inside of another contain like section, you don't need the div. Apply the styling directly to the section itself
• [ ] p tags and h1 - h6 tags should only contain text
• [ ] Use label elements instead of p elements in forms
• [ ] No functionality onclick nor styling should be declared in your HTML
  • <em> (italics) and <strong> (bold) are good semantic options for HTML

CSS

• [ ] DRY up CSS by stacking selectors and applying shared styles just once
• [ ] DRY up CSS by applying styles to a single class, then applying that class (in html file) to all the elements that needs those styles
• [ ] Don't grab/style the selector more than once
• [ ] Organize your CSS file
  • Use brief comments to organize the file
  • Within individual rule blocks, the properties/styles should be organized in some consistent way

Comments in Code

• While you are still working on the project, all comments are okay (though not pushing them to main is ideal).
• When you are turning in your final product, only some comments should remain...
  • Leave these comments out:
    • any commented out code (working or broken code)
    • any console.logs
    • commented explanations of what the code is doing
      • Your code should be written a way that we know what it’s doing (good variable and function names, modular functions)
  • These comments can stay:
    • Organizational comments (should be brief and clear)
      • example: In CSS, HEADER section
      • example: In JS, EVENT LISTENER section
      • example: In HTML, “Cards will appear here…”