He uses the following example for when to throw your own errors:<p><pre><code> var Controller = {
addClass: function(element, className) {
if (!element) {
throw new Error("addClass: 1st argument missing.");
}
element.className += " " + className;
}
};
</code></pre>
I don't think this is a very good as a native error will have all this information already in a stacktrace, and if you're running Chrome dev tools with 'Pause on exceptions' then you'll be shown the exact place this fails. Additionally, you need to now keep the function name in sync with the string (your IDE / build tool will not tell you if they get out of sync).<p>Better cases for custom errors are situations where a native error will not be thrown, such as:<p>- in his example method: if className is undefined<p>- valid objects in a state you don't expect<p>- switch statements that don't match any expected case<p>- etc.
This is nice video/article, but strongly outdated / missing "current" javascript maintainability standards.<p>Not so much "javascript" specific advices here.<p>No words on ES6 classes, that help keeping a meaningfull syntax, rest parameters, template strings.<p>No words on nodejs callback as last arg best practice.<p>No words on generator & promises (nor async await) that totally change callback behavior. No word on synchronious throw / catch vs callback(err) pattern.<p>No words on code modularisation.<p>This video is 4 years old, believe we, javascript change, a lot (and the "maintainable" best practice)<p>No link to mozilla MDN, when it's now a de-factor standard for web & js documentation.
The way I evaluate if a recommendation is good or bad is how it filters bad code.<p>The 4 most important things for me to keep under control are:<p>1) Length<p>2) Cyclomatic complexity<p>3) Shared mutable state<p>4) Coupling<p>If you keep those under control, the rest of the maintainability will come by itself. e.g: testability, reusability, thread safety, security and other high level goals are easier when these low level requirements are met.<p>And, of course, consistency. Make sure that things do what they say they do. e.g: make sure the purpose of a variable or function can be explained only through its signature without requiring to look at the code.
The code examples use ==, which does lossy comparison. Using === is much safer. The tools section mentions JSLint which flags any use of == as an error.<p>JavaScript is such a quirky language that I always want the code to pass JSLint and Closure Compiler with 100% type annotation. I simply do not feel confident about the code otherwise.<p>I'm surprised about the lack of space after 'if'. 'if' is not a function so 'if(' looks weird.