Why use Try instead of try/catch

December 4, 2014, 7:41 am

≫ Next: Difference between private and private[this]?

When writting Scala code, you always have the ability to use Java like exception control flows using try and catch.
However, you have the option of start using the Try type.

Why use Try vs try/catch?

Try was introduced in Scala 2.10 and behaves as a mappable Either without having to select right or left.

In the example below, taken from the Scala API:

def divide: Try[Int] = {  
  val dividend = Try(Console.readLine("Enter an Int that you'd like to divide:\n").toInt)
  val divisor = Try(Console.readLine("Enter an Int that you'd like to divide by:\n").toInt)
  val problem = dividend.flatMap(x => divisor.map(y => x/y))
  problem match {
    case Success(v) =>
      println("Result of " + dividend.get + "/"+ divisor.get +" is: " + v)
      Success(v)
    case Failure(e) =>
      println("You must've divided by zero or entered something that's not an Int. Try again!")
      println("Info from the exception: " + e.getMessage)
      divide
  }
}

You can see how, instead of using explicit try and catch to treat exceptions, Try is used to encapsulate the operation which is always an instance of either Success or Failure.

Benefits

You get, according again to the official documentation the:

[..] ability to pipeline, or chain, operations, catching exceptions along the way. You can map as you would a collection, an option or a right projection of an Either.

Furthermore, they encode exceptions in the Type system allowing for better documentation and clearer intention.
The Effective Scala[2] guide states:

using Option or com.twitter.util.Try are good, idiomatic choices, as they harness the type system to ensure that the user is properly considering error handling.

Start enforcing it today with Codacy

1: Scala API http://www.scala-lang.org/api/current/index.html#scala.util.Try
2: Effective Scala http://twitter.github.io/effectivescala

The post Why use Try instead of try/catch appeared first on Codacy | Blog.

↧

Difference between private and private[this]?

December 19, 2014, 7:44 am

≫ Next: One less Exception

≪ Previous: Why use Try instead of try/catch

When using private and private[this] do you know the difference?

When adding the scope to the private modifier (private[X]), it effectively behaves as a “up to” X, where X designates some enclosing package, class or singleton object.

For example, private[bar], where bar is a package means that every instance of every class belonging to package bar can access whichever member the modifier is restricting.

In the case of private[this], it means that the member is only accessible for each instance.
This becomes more clear in the following example:

class Foo(foo:Foo){  
  private[this] val i = 2
  println(this.i + foo.i)
}

error: value i is not a member of Foo

class Foo(foo:Foo){  
  private val i = 2
  println(this.i + foo.i)
}

defined class Foo

As you can see, the second Foo doesn’t have any problem since any instance can access the private val i. However for the first Foo there’s an error since each instance cannot see other instance’s i.

It’s a good practice to write private[this] since it imposes a bigger restriction.

Looking for a way to make sure you’re using private[this] every time? We enforce it on Codacy!

Enforceable today on Codacy

The post Difference between private and private[this]? appeared first on Codacy | Blog.

↧

One less Exception

May 28, 2015, 8:11 am

≫ Next: A quick look at scala.meta

≪ Previous: Difference between private and private[this]?

java.util.NoSuchElementException: No value found for 'USD' at scala.Enumeration.withName(Enumeration.scala:124)

Dammit! I hate it when code blows in production.
For some cases there’s just no tests or static analysis that can cover you.

This is one of those cases. Calling the withName method with an inexistent value in an Enumeration will blow up. Sure, it throws an Exception, but since Scala has unchecked exceptions, the compiler won’t warn you.

Unfortunately, it wasn’t the first time we had exactly this problem, so we agreed to start avoiding the withName method and writing it as:

Since find returns an Option, the code needs to be ready to deal with the possibility of a non existing value.

We also want all of our users to stay safe, so today we’re adding a new code pattern: Prohibit withName on Enumeration.
You can check your code for this issue and fix it before it blows in production!

The post One less Exception appeared first on Codacy | Blog.

↧

A quick look at scala.meta

June 4, 2015, 2:15 am

≫ Next: 9 Scala security issues you should know about

≪ Previous: One less Exception

At codacy we don’t only rely on external tools to find code patterns.

Especially when it comes to Scala we also have a nice repository of homemade patterns. Therefore we need to be able to process Scala sourcecode. And by processing we mainly mean transforming source code into Abstract Syntax Trees (ASTs).

Everything you find here you can try yourself in the repl. Be sure to add the following sbt resolver and dependencies

(Not yet deprecated) scala.reflect

Up until now we used the standard scala.reflect.api and the toolbox it provides. To parse scala code with help of the reflection toolbox we need to run the following:

The resulting tree variable is of type toolbox.u.Tree and this is the structure we use(d) to find problematic code. That doesn’t look too complicated you might say. Well you are right but the problems start here. Unfortunately those Trees are very complex (after all they represent the complete AST of your program). Also documentation is kinda poor – as writer of patterns I had to rely mainly on Scaladoc and partly Reflection.

Sidenote: Real life .scala files usually reside in packages which means a typical sourcefile will start with package foo ... The current implementation of the toolbox however is not able to parse such files. We were forced to implement a workaround that preyed on my mind ever since.

All of this doesn’t really make it easy for someone who doesn’t know the internals of scala.reflect.api to start writing patterns from scratch. But that’s exactly what we want. We want to make it possible for our users to write custom patterns for their issues.

scala.meta to the rescue

Recently we started a very promising collaboration with Eugene Burmako and Mathieu Demarne from scala.meta. scala.meta was created to simplify metaprograming in scala and will hopefully be the successor of the current scala.reflect. For us it already is. Let’s try to get a scala.meta.Tree

And that’s it. (Now try parsing a proper .scala file containing a package definition – spoiler alert : it works! ) But that’s not all, in scala.meta.tql we find a neat tree query language that helps us writing patterns. Let’s try to implement a pattern that finds occurrence of try-catch blocks. (On codacy you can read why you shouldn’t use them)

We can now pass trees to the tryMatcher, let’s just try a simple test code:

Et voila – the repl doesn’t lie – “found culprit at line 0”

Stay tuned about the future of scala.meta at Codacy

The post A quick look at scala.meta appeared first on Codacy | Blog.

↧

9 Scala security issues you should know about

December 11, 2015, 4:05 am

≫ Next: Codacy integrates with ESLint

≪ Previous: A quick look at scala.meta

Here is a list of 9 security issues we feel every Scala developer should know about and try to avoid:

1. Avoid Object deserialization of untrusted data

Object deserialization of untrusted data can lead to remote code execution, if there is a class in classpath allow the trigger of malicious operation.

Libraries developers tend to fix classes that provided potential malicious trigger. There are still classes that are known to trigger Denial of Service.

Deserialization is a sensible operation that has a great history of vulnerabilities. The web application might become vulnerable has soon as a new vulnerability is found in the Java Virtual Machine.

Code at risk:

public UserData deserializeObject(InputStream receivedFile) throws IOException, ClassNotFoundException {

    try (ObjectInputStream in = new ObjectInputStream(receivedFile)) {
        return (UserData) in.readObject();
    }
}

Solution:

Avoid deserializing object provided by remote users.

2. Avoid using the NullCipher

The NullCipher is seldom used intentionally in production applications. It implements the Cipher interface by returning ciphertext identical to the supplied plaintext. In a few contexts, such as testing, a NullCipher may be appropriate.

Solution:

Avoid using the NullCipher. Its accidental use can introduce a significant confidentiality risk.

3. Enforce secure RSA usage – RSA algorithm must have padding set.

Usage of the RSA algorithm without Optimal Asymmetric Encryption Padding (OAEP) might weaken encryption.

Vulnerable Code:

Cipher.getInstance("RSA/NONE/NoPadding")

Solution:

Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")

4. indexOf checks should be for negative numbers

Any checks that look for values > 0 ignore the first element, which is likely a bug.

Most checks against an indexOf value compare it with -1 because 0 is a valid index. Any checks which look for values > 0 ignore the first element, which is likely a bug. If the intent is merely to check inclusion of a value in a String or a List, consider using the contains method instead.

For strings, if the intent is truly to find the first index after a specific character index, then use the version ofindexOf which takes a start position argument.

This rule raises an issue any time an indexOf value retrieved either from a String or a List is tested for a positive value.

Noncompliant Code Example:

  val color = "blue"
  val name = "ishmael"

  val strings = List(color, name)

  if (strings.indexOf(color) > 0) {
    // Noncompliant
  }

  if (name.indexOf("ish") > 0) {
    // Noncompliant
  }

  if (name.indexOf("hma") > 2) {
    // Noncompliant
  }

Compliant Solution:

val color = "blue"
val name = "ishmael"

val strings = List(color, name)

if (strings.indexOf(color) > -1) {
  // ...
}
if (name.indexOf("ish") >= 0) {
  // ...
}
if (name.indexOf("hma") > -1) {
  // ...
}

5. indexOf checks should use a start position

indexOf with start position argument is clearer because the result is tested against -1, which is an easily recognizable ‘not found’ indicator.

One thing that makes good code good is the clarity with which it conveys the intent of the original programmer to maintainers, and the proper choice of indexOf methods can help move code from confusing to clear.

If you need to see whether a substring is located beyond a certain point in a string, you can test the indexOfthe substring versus the target point, or you can use the version of indexOf which takes a starting point argument. The latter is arguably clearer because the result is tested against -1, which is an easily recognizable not found indicator.

Noncompliant Code Example:

String name = "ismael";

if (name.indexOf("ae") > 2) { // Noncompliant
  // ...
}

Compliant Solution:

String name = "ismael";

if (name.indexOf("ae", 2) > -1) {
  // ...
}

6. java.lang.Error should not be extended

java.lang.Error and its subclasses represent abnormal conditions, such as OutOfMemoryError, which should only be encountered by the Java Virtual Machine.

Noncompliant Code Example:

public class MyException extends Error { /* ... */ }       // Noncompliant

Compliant Solution:

public class MyException extends Exception { /* ... */ }   // Compliant

7. Prevent Path Traversal

The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate a URL in such a way that the web site will execute or reveal the contents of arbitrary files anywhere on the web server. Any device that exposes an HTTP-based interface is potentially vulnerable to Path Traversal.

Most web sites restrict user access to a specific portion of the file system, typically called the “web document root” or “CGI root” directory. These directories contain the files intended for user access and the executable necessary to drive web application functionality. To access files or execute commands anywhere on the filesystem, Path Traversal attacks will utilize the ability of special characters sequences.

The most basic Path Traversal attack uses the “../” special character sequence to alter the resource location requested in the URL. Although most popular web servers will prevent this technique from escaping the web document root, alternate encodings of the “../” sequence may help bypass the security filters. These method variations include valid and invalid Unicode-encoding (“..%u2216” or “..%c0%af”) of the forward slash character, backslash characters (“..”) on Windows-based servers, URL encoded characters (“%2e%2e%2f”), and double URL encoding (“..%255c”) of the backslash character. Even if the web server properly restricts Path Traversal attempts in the URL path, a web application itself may still be vulnerable due to improper handling of user-supplied input. This is a common problem of web applications that use template mechanisms or load static text from files. In variations of the attack, the original URL parameter value is substituted with the file name of one of the web application’s dynamic scripts. Consequently, the results can reveal source code because the file is interpreted as text instead of an executable script. These techniques often employ additional special characters such as the dot (“.”) to reveal the listing of the current working directory, or “%00” NULL characters in order to bypass rudimentary file extension checks.

Example:

http://example/../../../../../etc/passwd
http://example/..%255c..%255c..%255cboot.ini
http://example/..%u2216..%u2216someother/file

8. Prohibit insecure ciphers

DES and DESede (3DES) are not considered strong ciphers for modern applications. They should be replaced by AES block cipher.

An example of weak code:

Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

Replaced with a stronger cipher:

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

9. Prohibit unencrypted sockets

When using an unencrypted Socket the traffic could be read by an attacker intercepting the network traffic.

Vulnerable Code:

Socket soc = new Socket("www.google.com",80);

Solution:

Socket soc = SSLSocketFactory.getDefault().createSocket("www.google.com", 443);

Enforce them now with Codacy

At Codacy we are committed to helping you save time in code reviews and we believe these security checks should be enforced automatically.
That’s why you can now enforce them automatically with Codacy. Just go to your project and enable them by selecting them in the code patterns section.

We’ll be rolling out more security patterns for Scala during the next couple of weeks, so stay tuned.

PS: Speaking of Scala, we are attending Scala eXchange today. We have a booth, come say hi. We have a magician.

The post 9 Scala security issues you should know about appeared first on Codacy | Blog.

↧

Codacy integrates with ESLint

December 21, 2015, 4:06 am

≫ Next: Review of CSS Linting Tools

≪ Previous: 9 Scala security issues you should know about

This past year we’ve seen an incredible growth coming from ESLint. ESLint is a linter on steroids for ECMAScript, JSX and JavaScript code. It quickly became the go-to linter for the JavaScript community. The work of Nicholas and the numerous contributors is really impressive.

ESLint Logo

The original philosophy behind the tool is something that speaks to us greatly as it is completely pluggable. ESLint makes it very easy to write your own plugins and share them with the community. You can find several examples on NPM.

Today I’m happy to announce that ESLint rules are now supported on Codacy. Here are the rules taken from the rules list that you can now enforce on Codacy. Enable them on your projects and share your feedback with us!

ESLint Rules

Possible Errors

The following rules point out areas where you might have made mistakes.

comma-dangle – disallow or enforce trailing commas (recommended)
no-cond-assign – disallow assignment in conditional expressions (recommended)
no-console – disallow use of console in the node environment (recommended)
no-constant-condition – disallow use of constant expressions in conditions (recommended)
no-control-regex – disallow control characters in regular expressions (recommended)
no-debugger – disallow use of debugger (recommended)
no-dupe-args – disallow duplicate arguments in functions (recommended)
no-dupe-keys – disallow duplicate keys when creating object literals (recommended)
no-duplicate-case – disallow a duplicate case label. (recommended)
no-empty-character-class – disallow the use of empty character classes in regular expressions (recommended)
no-empty – disallow empty statements (recommended)
no-ex-assign – disallow assigning to the exception in a catch block (recommended)
no-extra-boolean-cast – disallow double-negation boolean casts in a boolean context (recommended)
no-extra-parens – disallow unnecessary parentheses
no-extra-semi – disallow unnecessary semicolons (recommended) (fixable)
no-func-assign – disallow overwriting functions written as function declarations (recommended)
no-inner-declarations – disallow function or variable declarations in nested blocks (recommended)
no-invalid-regexp – disallow invalid regular expression strings in the RegExp constructor (recommended)
no-irregular-whitespace – disallow irregular whitespace outside of strings and comments (recommended)
no-negated-in-lhs – disallow negation of the left operand of an in expression (recommended)
no-obj-calls – disallow the use of object properties of the global object (Math and JSON) as functions (recommended)
no-regex-spaces – disallow multiple spaces in a regular expression literal (recommended)
no-sparse-arrays – disallow sparse arrays (recommended)
no-unexpected-multiline – Avoid code that looks like two expressions but is actually one
no-unreachable – disallow unreachable statements after a return, throw, continue, or break statement (recommended)
use-isnan – disallow comparisons with the value NaN (recommended)
valid-jsdoc – Ensure JSDoc comments are valid
valid-typeof – Ensure that the results of typeof are compared against a valid string (recommended)

Best Practices

These are rules designed to prevent you from making mistakes. They either prescribe a better way of doing something or help you avoid footguns.

accessor-pairs – Enforces getter/setter pairs in objects
block-scoped-var – treat var statements as if they were block scoped
complexity – specify the maximum cyclomatic complexity allowed in a program
consistent-return – require return statements to either always or never specify values
curly – specify curly brace conventions for all control statements
default-case – require default case in switch statements
dot-location – enforces consistent newlines before or after dots
dot-notation – encourages use of dot notation whenever possible
eqeqeq – require the use of === and !== (fixable)
guard-for-in – make sure for-in loops have an if statement
no-alert – disallow the use of alert, confirm, and prompt
no-caller – disallow use of arguments.caller or arguments.callee
no-case-declarations – disallow lexical declarations in case clauses
no-div-regex – disallow division operators explicitly at beginning of regular expression
no-else-return – disallow else after a return in an if
no-empty-label – disallow use of labels for anything other than loops and switches
no-empty-pattern – disallow use of empty destructuring patterns
no-eq-null – disallow comparisons to null without a type-checking operator
no-eval – disallow use of eval()
no-extend-native – disallow adding to native types
no-extra-bind – disallow unnecessary function binding
no-fallthrough – disallow fallthrough of case statements (recommended)
no-floating-decimal – disallow the use of leading or trailing decimal points in numeric literals
no-implicit-coercion – disallow the type conversions with shorter notations
no-implied-eval – disallow use of eval()-like methods
no-invalid-this – disallow this keywords outside of classes or class-like objects
no-iterator – disallow usage of __iterator__ property
no-labels – disallow use of labeled statements
no-lone-blocks – disallow unnecessary nested blocks
no-loop-func – disallow creation of functions within loops
no-magic-numbers – disallow the use of magic numbers
no-multi-spaces – disallow use of multiple spaces (fixable)
no-multi-str – disallow use of multiline strings
no-native-reassign – disallow reassignments of native objects
no-new-func – disallow use of new operator for Function object
no-new-wrappers – disallows creating new instances of String,Number, and Boolean
no-new – disallow use of the new operator when not part of an assignment or comparison
no-octal-escape – disallow use of octal escape sequences in string literals, such as var foo = "Copyright \251";
no-octal – disallow use of octal literals (recommended)
no-param-reassign – disallow reassignment of function parameters
no-process-env – disallow use of process.env
no-proto – disallow usage of __proto__ property
no-redeclare – disallow declaring the same variable more than once (recommended)
no-return-assign – disallow use of assignment in return statement
no-script-url – disallow use of javascript: urls.
no-self-compare – disallow comparisons where both sides are exactly the same
no-sequences – disallow use of the comma operator
no-throw-literal – restrict what can be thrown as an exception
no-unused-expressions – disallow usage of expressions in statement position
no-useless-call – disallow unnecessary .call() and .apply()
no-useless-concat – disallow unnecessary concatenation of literals or template literals
no-void – disallow use of the void operator
no-warning-comments – disallow usage of configurable warning terms in comments – e.g. TODO or FIXME
no-with – disallow use of the with statement
radix – require use of the second argument for parseInt()
vars-on-top – require declaration of all vars at the top of their containing scope
wrap-iife – require immediate function invocation to be wrapped in parentheses
yoda – require or disallow Yoda conditions

Strict Mode

These rules relate to using strict mode.

strict – controls location of Use Strict Directives

Variables

These rules have to do with variable declarations.

init-declarations – enforce or disallow variable initializations at definition
no-catch-shadow – disallow the catch clause parameter name being the same as a variable in the outer scope
no-delete-var – disallow deletion of variables (recommended)
no-label-var – disallow labels that share a name with a variable
no-shadow-restricted-names – disallow shadowing of names such as arguments
no-shadow – disallow declaration of variables already declared in the outer scope
no-undef-init – disallow use of undefined when initializing variables
no-undef – disallow use of undeclared variables unless mentioned in a /*global */ block (recommended)
no-undefined – disallow use of undefined variable
no-unused-vars – disallow declaration of variables that are not used in the code (recommended)
no-use-before-define – disallow use of variables before they are defined

Node.js and CommonJS

These rules are specific to JavaScript running on Node.js or using CommonJS in the browser.

callback-return – enforce return after a callback
global-require – enforce require() on top-level module scope
handle-callback-err – enforce error handling in callbacks
no-mixed-requires – disallow mixing regular variable and require declarations
no-new-require – disallow use of new operator with the require function
no-path-concat – disallow string concatenation with __dirname and __filename
no-process-exit – disallow process.exit()
no-restricted-modules – restrict usage of specified node modules
no-sync – disallow use of synchronous methods

Stylistic Issues

These rules are purely matters of style and are quite subjective.

array-bracket-spacing – enforce spacing inside array brackets (fixable)
block-spacing – disallow or enforce spaces inside of single line blocks (fixable)
brace-style – enforce one true brace style
camelcase – require camel case names
comma-spacing – enforce spacing before and after comma (fixable)
comma-style – enforce one true comma style
computed-property-spacing – require or disallow padding inside computed properties (fixable)
consistent-this – enforce consistent naming when capturing the current execution context
eol-last – enforce newline at the end of file, with no multiple empty lines (fixable)
func-names – require function expressions to have a name
func-style – enforce use of function declarations or expressions
id-length – this option enforces minimum and maximum identifier lengths (variable names, property names etc.)
id-match – require identifiers to match the provided regular expression
indent – specify tab or space width for your code (fixable)
jsx-quotes – specify whether double or single quotes should be used in JSX attributes
key-spacing – enforce spacing between keys and values in object literal properties
linebreak-style – disallow mixed ‘LF’ and ‘CRLF’ as linebreaks
lines-around-comment – enforce empty lines around comments
max-depth – specify the maximum depth that blocks can be nested
max-len – specify the maximum length of a line in your program
max-nested-callbacks – specify the maximum depth callbacks can be nested
max-params – limits the number of parameters that can be used in the function declaration.
max-statements – specify the maximum number of statement allowed in a function
new-cap – require a capital letter for constructors
new-parens – disallow the omission of parentheses when invoking a constructor with no arguments
newline-after-var – require or disallow an empty newline after variable declarations
no-array-constructor – disallow use of the Array constructor
no-bitwise – disallow use of bitwise operators
no-continue – disallow use of the continue statement
no-inline-comments – disallow comments inline after code
no-lonely-if – disallow if as the only statement in an else block
no-mixed-spaces-and-tabs – disallow mixed spaces and tabs for indentation (recommended)
no-multiple-empty-lines – disallow multiple empty lines
no-negated-condition – disallow negated conditions
no-nested-ternary – disallow nested ternary expressions
no-new-object – disallow the use of the Object constructor
no-plusplus – disallow use of unary operators, ++ and --
no-restricted-syntax – disallow use of certain syntax in code
no-spaced-func – disallow space between function identifier and application (fixable)
no-ternary – disallow the use of ternary operators
no-trailing-spaces – disallow trailing whitespace at the end of lines (fixable)
no-underscore-dangle – disallow dangling underscores in identifiers
no-unneeded-ternary – disallow the use of ternary operators when a simpler alternative exists
object-curly-spacing – require or disallow padding inside curly braces (fixable)
one-var – require or disallow one variable declaration per function
operator-assignment – require assignment operator shorthand where possible or prohibit it entirely
operator-linebreak – enforce operators to be placed before or after line breaks
padded-blocks – enforce padding within blocks
quote-props – require quotes around object literal property names
quotes – specify whether backticks, double or single quotes should be used (fixable)
require-jsdoc – Require JSDoc comment
semi-spacing – enforce spacing before and after semicolons
semi – require or disallow use of semicolons instead of ASI (fixable)
sort-vars – sort variables within the same declaration block
space-after-keywords – require a space after certain keywords (fixable)
space-before-blocks – require or disallow a space before blocks (fixable)
space-before-function-paren – require or disallow a space before function opening parentheses (fixable)
space-before-keywords – require a space before certain keywords (fixable)
space-in-parens – require or disallow spaces inside parentheses
space-infix-ops – require spaces around operators (fixable)
space-return-throw-case – require a space after return, throw, and case (fixable)
space-unary-ops – require or disallow spaces before/after unary operators (fixable)
spaced-comment – require or disallow a space immediately following the // or /* in a comment
wrap-regex – require regex literals to be wrapped in parentheses

ECMAScript 6

These rules are only relevant to ES6 environments.

arrow-body-style – require braces in arrow function body
arrow-parens – require parentheses in arrow function arguments
arrow-spacing – require space before/after arrow function’s arrow (fixable)
constructor-super – verify calls of super() in constructors
generator-star-spacing – enforce spacing around the * in generator functions (fixable)
no-arrow-condition – disallow arrow functions where a condition is expected
no-class-assign – disallow modifying variables of class declarations
no-const-assign – disallow modifying variables that are declared using const
no-dupe-class-members – disallow duplicate name in class members
no-this-before-super – disallow use of this/super before calling super() in constructors.
no-var – require let or const instead of var
object-shorthand – require method and property shorthand syntax for object literals
prefer-arrow-callback – suggest using arrow functions as callbacks
prefer-const – suggest using const declaration for variables that are never modified after declared
prefer-reflect – suggest using Reflect methods where applicable
prefer-spread – suggest using the spread operator instead of .apply().
prefer-template – suggest using template literals instead of strings concatenation
require-yield – disallow generator functions that do not have yield

The post Codacy integrates with ESLint appeared first on Codacy | Blog.

↧

Review of CSS Linting Tools

June 25, 2014, 8:22 am

≫ Next: 3 new code patterns for Scala

≪ Previous: Codacy integrates with ESLint

Writing a set of well-structured and optimized CSS codes can be a tedious task.
There are a couple of tools you could use today to help you achieve better CSS code. CSS Linting Tools will assist you and save you precious time in the code review process.

Let us have a quick overview of the open source CSS Linting Tools available.

1. CSS LINT

CSS LINT is the most common and known CSS linting tool to help point out problems with your CSS code. It is basically written in JavaScript which runs the whole CSS linting process.
It applies a set of Javascript rules against your CSS file code. It’s also completely open sourced (https://github.com/CSSLint/csslint) so it’s community driven which is a great signal for linting tools.

CSSLint verifies your syntax versus a set of predefined rules to uproot potential inefficiencies and errors. You are given the possibility to select the set of rules you would like to enforce.
Overall, it’s a very flexible tool and complete since it looks for:

– Possible errors (e.g. empty rules or unknown property files)

– Compatibility (e.g. requiring all vendor prefixes such as moz or webkit)

– Performance (e.g. using too many web fonts)

– Maintainability and duplication (e.g. using too many font-size declarations)

Interaction Mode: Direct Input.
More Information: http://csslint.net/

2. CSS Cop

Helps you in improving your code better browser compatible stylesheets. It runs the CSS Lint (CSSlint.net) in the background and it is highly customizable. It is an extension which gets directly integrated with Visual Studio and runs CSS Lint in the IDE.

To run CSSCop, just right-click on any CSS file, folder or project in the Solution Explorer. This will trigger the rule engine and make a list of warnings or the error List. The characteristic of pluggable options make the user to opt as per the need. This extension is compatible with Visual Studio 2013, 2012 and 2010.

Interaction Mode: Direct.
More Information: http://visualstudiogallery.msdn.microsoft.com/a921b98e-9430-4be2-bf53-1169e12bdb50

3. ProCSSor

It is a sleek tool to clean and format your CSS. The main aim of this tool is to deal with formatting, indentation and presentation issues. Another great feature is the compression of the code in order to increase its speed and to maintain the code in a readable format.

This format is defined by you which provides an interesting customization option for your CSS code.

Interaction Mode: Direct Input, file and URL.
More Information: http://tools.maxcdn.com/procssor/

4. Dust-Me Selectors

Dust-Me Selectors is a firefox plugin that primarily provides 3 main functions: scanning an HTML page by getting stylesheet and selector details and making you aware of the CSS that are used and not used in a particular page. Essentially it helps you maintain and clean up your CSS code by crawling an XML or HTML site. It loads and scans each page which is linked to the web site and performs a check between each stylesheet against the document object model and gives you an overall and global picture of the selectors. It also has the ability to scan the pages automatically as you are browsing and pick up content dynamically which the crawler cannot detect.

Very configurable interface it is a handy plug-in for Firefox and Opera. It also supports all the levels of stylesheets, scans 5 pages in one second.

Interaction Mode: Direct and URL.
More Information: https://addons.mozilla.org/en-US/firefox/addon/dust-me-selectors/

5. W3C

The W3C CSS Validation Service provides you the feature of validating HTML and CSS by manually entering code, URL, or on your local hard drive. This online tool helps you in extracting out all the CSS and HTML errors and warnings which do not conform to HTML rules and standards. It supports all four levels of CSS, Scalable Vector Graphics (SVG), mobile devices and TV profiles. It provides the errors list as well as various levels of warnings which can be ignored on the user preferences.
It works great against vanilla HTML without any sort of template mechanisms.

Interaction Mode: Direct input, file and URL.
More Information: http://jigsaw.w3.org/css-validator/

6. Dirty MarkUp

Dirty Markup is a three in one tool which helps you clean, format and validate CSS, HTML and JavaScript file types applying the same set of rules. These rules are, for instance, making sure that every code file has an identical appearance and code style. Every file type has a set of alternatives which will decide how the output comes out once the code is cleaned.
It also serves as a CSS editor, with colour coding the code elements. Unfortunately it doesn’t provide an option to directly upload and save changes to a file.

Interaction Mode: Direct input, file and URL.
More Information: http://www.dirtymarkup.com/

7. CleanCSS

CleanCSS helps your code to be well formatted and performant. Its main focus is code compression by removing unwanted white spaces and thus using minimum file resources and browser memory which improves web page performance and load time. It optimizes colour settings, removes unwanted backslashes and also discards invalid properties.

CleanCSS does not support CSS3 and also the compressed code produced is not human readable, these could marked as the 2 disadvantages.

Interaction Mode: Direct input and URL.
More Information: http://www.cleancss.com/

8. StyleNeat

StyleNeat is another open source web service that assists you to have standard and organized CSS- sub-selectors and selectors.

Interaction Mode: Direct input and URL.
More Information: http://www.styleneat.com/

9. CSSTidy

CSSTidy is an open source CSS linting tool available as executable file (available for Windows, Linux and OSX) which runs using command line and as PHP script providing CSS2 support. It provides high compression capability and also has custom templates to format the CSS code using your own coding style.

Interaction Mode: Command Line
More Information: http://csstidy.sourceforge.net/

10. Code Beautifier

Code Beautifier is a simple CSS clean-up tool with a user friendly interface. It provides the feature to place the cleaned up code to an output CSS file.

Interaction Mode: Direct Input, URL
More Information: http://www.codebeautifier.com/

Each of the mentioned above tools have its own advantages and disadvantages, so the choice is left to the user to make the best to meet your requirements.

[Shameless plug]

At Codacy, we provide a pretty thorough analysis using CSSLint which gets applied automatically and effortlessly to every commit you make. We take pride in removing the burden of even having to remember to run these tools. We run, organize and prioritize each CSS analysis results so you don’t have to waste time doing this.

The post Review of CSS Linting Tools appeared first on Codacy | Blog.

↧

3 new code patterns for Scala

February 29, 2016, 3:14 am

≪ Previous: Review of CSS Linting Tools

Codacy regularly adds new patterns to the languages it supports.

Here are 3 new patterns we just added for Scala:

1. Avoid using DateTime.now without a timezone (Error Prone)

Using DateTime.now without specifying a timezone can lead to error prone code with regard to dealing with other timezones than those initially considered, as well as with daylight saving time.

For instance, the following example:

 val now = DateTime.now

could easily be written as:

 val now = DateTime.now(DateTimeZone.UTC)

2. Prefer using .nonEmpty (Code Style)

The collections libraries usually provide a method for determining if the iterable has, at least, one element, with:

 val hasElements = SomeSequence.nonEmpty

This is a bit cleaner than verifying explicitly the length or the size:

 val hasElements = SomeSequence.length > 0
 val hasElementsUsingSize = SomeSequence.size > 0

3. Prevent XML parsing attacks (Security)

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source.

Vulnerable Code:

 SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
 parser.parse(inputStream, customHandler);

Solution using “Secure processing” mode:

 SAXParserFactory spf = SAXParserFactory.newInstance();
 spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
 SAXParser parser = spf.newSAXParser();
 parser.parse(inputStream, customHandler);

Solution disabling DTD:

 SAXParserFactory spf = SAXParserFactory.newInstance();
 spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
 SAXParser parser = spf.newSAXParser();
 parser.parse(inputStream, customHandler);

Enabling patterns with Codacy

When new patterns are added, they’re disabled for already existing projects.

To enable them for a project first head to the project and hit “Code Patterns” on the top right corner. You’ll be able to filter the patterns by language or category:

To enable the new patterns simply look for the “New” tag on them and hit their respective checkbox:

If you’re interested, there’s also a “Fork pattern” button on the bottom right corner of the details of every Scala pattern.

Hitting this button will take you to our Beta Pattern Creator with the current pattern loaded; you can then edit it to create your own:

Have fun, code well!

The post 3 new code patterns for Scala appeared first on Codacy | Blog.

↧