Zach Harkey's List: Web Development (Best Practice)

• Remember that exports from the features module are actually just automatically generated modules and are thus subject to the same naming conventions.
• Don't name your module using a name that is already taken by an existing module. Obviously this applies to all the modules in the core modules directory but I would also extend this to don't name your module using a name that's already taken on drupal.org.
• Will you ever contribute this module or is it completely application specific code that will never see the light of day?
• You're going to be typing these module names a lot so brevity can be nice. For Drupalize.Me we started out using drupalizeme****.module, but have since abbreviated it to dme***.module
• We've also standardized on not including an underscore (_) in our module names. For a while we had names like dme_comments, dme_videos, and others. However best practice is to name your module without any underscores to reduce the chance of namespace collision.
• • Don't use names that are already in use on drupal.org for custom code.
   
  • Use meaningful names for findability.
   
  • Use domain specific names for code that you're sure isn't going to be contributed back.
   
  • Standardize your team on a naming convention.
   
   

4 more annotations...

• oh, by the way, your entire way of working will probably have to change.
• Old waterfallesque processes where visual designers work entirely in Photoshop before throwing PSDs over the wall to developers just don’t cut it any more.
• Old QA testing processes that demanded visual consistency across all browsers and platforms are just ludicrous.
• “Oh, we’d love to do what you’re saying, but our clients would never go for it.” Or “You’ve convinced me but there’s no way our boss will ever agree to this.”

2 more annotations...

• Write longer classes; instead of a class like .logo{}, opt for .site-logo{}. Make your classes a lot less loose by naming them a lot more specifically. It might not always be a case of scoping, it might just be a case of picking a better name for something with global scope.
• Nesting selectors is a bad way of scoping, so use a naming convention like BEM to provide a quasi scoping.

• The trick with BEM is knowing when something falls into a relevant category. Just because something happens to live inside a block it doesn’t always mean is is actually a BEM element. In the case of our site logo it lives in the .header purely coincidentally; it could just as easily be in our sidebar or footer. An element’s scope can start in any context, so you need to make sure you only apply BEM as far as you need to.

• Custom code for a project is the one area where I see the most issues with file management. Polarizing concepts, like keeping things global or local, paralyze many developers. They want to keep the code as accessible as possible, but inevitably end up creating functional Sass that is specific to a type of UI or module. So instead of ignoring this, I recommend embracing this.
• The use of elemental styles to build a module is strongly encouraged; while defining new elements in the scope of building a module is strongly discouraged.
• The idea here is that while engineering modules you may need to create complex functional Sass that is exclusive to a module. While I strongly encourage making UI logic as abstract as possible and available to the whole app, this process discourages the practice of creating junk-drawers.
• Our layout Sass files should contain no more information then is needed to assemble a series of modules and elements. Imagine a sketch with gray boxes in the view, this is the document that creates that structure. Elements are never defined and modules are never engineered here.

2 more annotations...

• The reason is to communicate intent. A double underscore is for an element, and a double dash is a modifier. Following this convention means that i can tell, at a glance, the intent and purpose of a selector. I must admit it looks pretty ugly, but it works.

• "Never @extend across modules!".

• It is important that this file be kept devoid of any CSS rules.
• It is important that there are no CSS rules in the _config.scss file.
• Typically you will include it at the head of your primary Sass manifest file, such as style.scss. Depending on how your architecture progresses, there may be times when you need to import your _config.scss file again in another module. As long as you keep any CSS rules out of this document, there is nothing wrong with this practice.
• Elemental partials is where we get to work. Here we write Sass rules that will create your UI foundational layer. _buttons.scss, _forms.scss, _global_design.scss, _reset.scss and _typography.scss all contain Sass rules that will process into CSS. While they will import other partials, mixins and silent placeholder rules, it is important to remember that these files are engineered only to output CSS.
• Patterns like placing mixins in the same file as presentational Sass leads to overly complex files to scan and opportunities for accidental pollution of your processed CSS.
• Keeping functional Sass separate from presentational Sass is important in order to maintain readability, search-ability and scaleability of your code.
• In essence, modular Sass is an assembly of foundational elements with only enough additional presentational Sass to hold it together.
• The use of elemental styles to build a module is strongly encouraged; while defining new elements in the scope of building a module is strongly discouraged.
• Our layout Sass files should contain no more information then is needed to assemble a series of modules and elements. Imagine a sketch with gray boxes in the view, this is the document that creates that structure. Elements are never defined and modules are never engineered here.

7 more annotations...

• The modules directory is reserved for Sass code that doesn’t cause Sass to actually output CSS. Things like mixin declarations, functions, and variables.
• The partials directory is where the meat of my CSS is constructed. A lot of folks like to break their stylesheets into header, content, sidebar, and footer components (and a few others). As I’m more of a SMACSS guy myself, I like to break things down into much finer categories (typography, buttons, textboxes, selectboxes, etc…).
• The vendor directory is for third-party CSS. This is handy when using prepackaged components developed by other people (or for your own components that are maintained in another project). jQuery UI and a color picker are examples of CSS that you might want to place in the vendor directory. As a general rule I make it a point not to modify files in my vendor directory. If I need to make modifications I add those after the vendored files are included in my primary stylesheet. This should make it easy for me to update my third-party stylesheets to more current versions in the future.
• Again modules are not allowed to contain anything that would cause CSS output when importing.
• This allows me to build multiple stylesheets by importing different partials. Multiple stylesheets are handy once a project grows to a certain size.

3 more annotations...