4308 shaares
7 results
tagged
CodingStyle
While developing a new project is like rolling on a green field for you, maintaining it is a potential dark twisted nightmare for someone else. Here's a list of guidelines we've found, written and gathered that (we think) works really well with most JavaScript projects here at hive. If you want to share a best practice, or think one of these guidelines should be removed, feel free to share it with us.
Found from: http://javascriptweekly.com
"RSJS makes JavaScript easy to maintain in a typical web application. It’s written for the typical conventional web app in mind: a collection of HTML pages that occasionally need a bit of JavaScript to make things work."
Anti-patterns addressed:
- Ambiguious sources: It’s not obvious where to look for the JS behavior. (Is the handler attached to .author, .footnote, or .profile-link?)
- Non-reusable: It’s not obvious how to reuse the behavior in another page. (Should blogpost.js be included in the other pages that need it? What if that file contains other behaviors you don’t need for that page?)
- Lack of organization: Making new behaviors gets confusing. (Do you make a new .js file for each page? Do you add them to the global application.js? How do you load them?)
In a nutshell:
- Keep your HTML declarative (get rid of inline scripts).
- Put all your imperative code in JS files.
- Reduce ambiguity by having straight-forward conventions.
- HTML elements can be components that have behaviors.
- Behaviors apply JavaScript to a [data-js-behavior-name] selector.
Some practical tips:
- onmount (interesting but almost no users so far)
- store shared data in
<meta>
tags:function getMeta (name) { return $('meta[property=' + JSON.stringify(name) + ']').attr('content') }
Codage en langage C