JavaScript for Li...
Follow
Find tag "jslint"
309.4K views | +691 today
JavaScript for Line of Business Applications
Keeping track of current JavaScript Frameworks that help design your clientside Business Logic Layers.
Curated by Jan Hesse
Beam to my Inbox:
Your new post is loading...
Your new post is loading...
Scoop.it!

Explorations In Automatically Fixing JavaScript Linting-errors

Explorations In Automatically Fixing JavaScript Linting-errors | JavaScript for Line of Business Applications | Scoop.it

FixMyJS (by Josh Perez) was created to try solving this problem. It aims to automatically fix linting errors in a non-destructive way. To an extent, it achieves this goal.

Under the hood the module uses Esprima for source parsing and Escodegen (from the Mozilla Parser API AST) to generate it back. While any form of automation code transformation should be approached with a healthy dose of skepticism, FixMyJS is able to handle fixing basic JSHint errors fairly well. Some of what it supports includes:

  • Adding missing semicolons
  • Enforcing camelCase and snake_case conventions
  • Adding curly braces to statements
  • Removing debugger statements
  • Enforcing single and double quite styles
  • Adding the radix parameter to parseInt
  • Dot notation conversion
  • Handling extra trailing commas

and a few other common linting issues.

more...
No comment yet.
Scoop.it!

Eliminating Code Smell With Grunt

I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.

My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.

Beyond the challenge of defining rules lies the supreme annoyance of enforcing them. Code reviews become cluttered with nits to be picked. Time is wasted. The solution I settled on was simply automating the conformance process.

I set forth to solve this problem:

Establish coding standards that are clearly defined and automatically verifiable.

Jan Hesse's insight:

http://flippinawesome.org/2013/12/02/eliminating-code-smell-with-grunt/

more...
No comment yet.
Scoop.it!

Testable & Tested Client-side Code

Testable & Tested Client-side Code | JavaScript for Line of Business Applications | Scoop.it

Testing (i.e. linting, unit tests, integration testing etc..) client-side code is not done as commonly as it should be. The reason it is so commonly not done, besides lack of know-how, is that it is presupposed that it will take time away from other more productive development tasks.

This fallacious notion is, of course, wrong. The repeatable successes in software engineering based on testable (i.e. modular, loosely coupled, small, simple units of code) and tested code has proven again and again to be a time-saver and part of creating maintainable and understandable code. At a minimum, if code is not unit tested it is only a matter of time before it is burnt down and re-written, or abandoned altogether because it becomes unmaintainable and incomprehensible.

In this article, I am going to defend and talk about testing client-side code. It is my intention that the information in this article will give those among us who do not test, the desire and some initial testing knowledge to test, along with the ability to defend its necessity from any agent that might deter testing.

more...
No comment yet.
Scoop.it!

Introducing ESLint

A long time ago, JSLint was the state of the art in JavaScript linting technology. Then JSHint came along as a fork and took over due to increased flexibility. I welcomed JSHint as my linter of choice and used it everywhere, happily submitting patches and customizing which rules to apply based on the project. At some point I started to feel stifled and frustrated by JSHint as well. There’s no easy way to add additional rules or to create your own that may be project-specific.

After talking with Anton about the possibilities available with JSHint, we both came to the conclusion that it wouldn’t be possible to do what I wanted. I really wanted an AST to evaluate for context and to be able to dynamically plug in new rules at any time, including run time.

ESLint is a JavaScript linting tool built on top of Esprima. The goal of the project is to create a linting tool where all rules are pluggable. This is achieved by having one rule per file and allowing each rules to inspect the AST at the points it wants.

more...
No comment yet.
Scoop.it!

JSCS — JavaScript Code Style.

JSCS — JavaScript Code Style. | JavaScript for Line of Business Applications | Scoop.it

jscs is a code style checker. jscs can check cases, which are not implemeted in jshint, but it does not duplicate jshint functionality, so you should use jscs and jshint together.

 

* requireCurlyBraces
* requireSpaceAfterKeywords
* disallowSpaceAfterKeywords
* requireParenthesesAroundIIFE
* requireSpacesInFunctionExpression
* disallowSpacesInFunctionExpression
* disallowMultipleVarDecl
* requireMultipleVarDecl
* disallowEmptyBlocks
* disallowSpacesInsideObjectBrackets
* disallowSpacesInsideArrayBrackets
* disallowSpacesInsideParentheses
* requireSpacesInsideObjectBrackets
* requireSpacesInsideArrayBrackets
* disallowQuotedKeysInObjects
* disallowDanglingUnderscores
* disallowSpaceAfterObjectKeys
* requireSpaceAfterObjectKeys
* disallowCommaBeforeLineBreak
* requireCommaBeforeLineBreak
* requireAlignedObjectValues
* requireOperatorBeforeLineBreak
* disallowLeftStickedOperators
* requireRightStickedOperators
* disallowRightStickedOperators
* requireLeftStickedOperators
* disallowSpaceAfterPrefixUnaryOperators
* requireSpaceAfterPrefixUnaryOperators
* disallowSpaceBeforePostfixUnaryOperators
* requireSpaceBeforePostfixUnaryOperators
* disallowSpaceBeforeBinaryOperators
* requireSpaceBeforeBinaryOperators
* disallowSpaceAfterBinaryOperators
* requireSpaceAfterBinaryOperators
* disallowImplicitTypeConversion
* requireCamelCaseOrUpperCaseIdentifiers
* disallowKeywords
* disallowMultipleLineStrings
* disallowMultipleLineBreaks
* validateLineBreaks
* validateQuoteMarks
* validateIndentation
* disallowMixedSpacesAndTabs
* disallowTrailingWhitespace
* disallowKeywordsOnNewLine
* requireKeywordsOnNewLine
* requireLineFeedAtFileEnd
* maximumLineLength
* requireCapitalizedConstructors
* safeContextKeyword
* requireDotNotation
* validateJSDoc

more...
No comment yet.
Scoop.it!

Now available: ESLint v0.1.0

Today I’m excited to announce version 0.1.0 is available. This is the first alpha version that is ready for people to start using and give us feedback on. Up until this point, the tool was in a state of constant flux and I didn’t feel comfortable recommending anyone use it. I wanted to get ESLint as close to the ruleset of JSHint before deeming it ready for use, and we are finally there. We have (as best we can tell), nearly 100% coverage of the JSHint rules that don’t apply to formatting (white space and other code convention rules).

Here’s what this release gives you:
* Most of the JSHint rules (that don’t apply to formatting issues)
* New rules can be loaded at runtime
* Specification of shared settings using .eslintrc files
* Configure rules as disabled, warnings, or errors
* Output results as Checkstyle, compact, JSLint-XML, or JUnit formats
* 95% or higher code coverage for statements, branches, functions, and lines

more...
Shaker technologies's curator insight, November 14, 2013 5:51 PM

Un vérificateur de code javascript.

Scoop.it!

Better JavaScript with Strict Mode and JSHint

With great flexibility comes great responsibility… and JavaScript is very flexible.  Too flexible, some might argue.  There are many “features” of JavaScript that result in code that is hard to read, dangerous or buggy to execute, and in some cases creates performance issues.  In 2008, Douglas Crockford wrote a fantastic book called “JavaScript: The Good Parts” that described the features he found problematic: global variables, the assignment of ‘this’ to the global object, misuse of eval, etc.  If you write JavaScript, it’s a must read.

Several of the “bad” features Crockford identified have been mitigated with “Strict Mode.”  This was added to version 5 of ECMAScript (the JavaScript standard; supported by most popular web browsers).  Strict mode throws exceptions or prevent behavior when “bad” features or common coding errors are evaluated.  A couple of examples…

more...
No comment yet.