Cross Programming Languages Best Practices

In this article:
Subscribe to our blog:

We want to focus on cross programming best practices as often it seems like best practices are tied to a specific programming language.  However, some of them seem to have crossed boundaries and have found a place in other languages.

Sometimes they’re exactly the same; sometimes they’re a bit different.

Here are are some interesting facts:

1. TODO comments

There seems to be a tendency to write comments with TODO, FIXME, BUG and the likes in many different languages.

Here are three different patterns integrated at Codacy regarding this behavior:

  • Java (from Checkstyle) — A check for TODO comments
  • Scala — Prohibit todo/fixme tags in comments
  • JavaScript (from ESLint) — Prohibit Warning Comments

Interestingly, this is a pattern that is activated by default for Scala world but not for Java or JavaScript.

The patterns refer to the same thing but they each have their own intricacies:

  • in Java the pattern look for the terms FIXME and TODO
  • in Scala the pattern has an option for case sensitivity and the default terms are FixMe and ToDo
  • in JavaScript the search is case insensitive, done in the beginning of the comment (but that can be changed) and the default terms are todo, fixme and xxx

I’m not sure what this says about JavaScript developers.

2. TABS

I still remember when a tab was always 8 spaces and everybody used tabs for indentation.

Times changed: tabs started having different lengths depending on the editor being used (and on the configuration in place) and, eventually, bits of code got a bit difficult to read. The result was a general distaste for the tab character.

Lots of static analysis tools now have patterns related to this. Here are a few that are integrated at Codacy:

  • Java — Checks to see if a file contains a tab character
  • JavaScript — Enforce Indentation standard
  • JavaScript — Prohibit mixed spaces and tabs
  • PHP — Enforce space indentation (Code must use an indentation of 4 spaces without tabs)
  • CoffeeScript — No Tabs
  • Python — Prohibits a mix of spaces and tabs
  • Python — Prohibits an unexpected number of indentation’s spaces
  • Scala — Prohibit tabs in a file (Prohibits from using tabs for indentation)
  • Ruby — Indentation Width

A few interesting points regarding these patterns:

  • Java, Scala, PHP and CoffeeScript’s patterns reject tabs
  • JavaScript and Python allow tabs, but there are patterns to make sure the code isn’t indented with both (otherwise the result could be different depending on the editor or configuration being used)
  • In these patterns, the recommended indentation for Ruby, JavaScript and Scala is 2 spaces, while for Python and PHP it’s 4 spaces.

The names differ, but they mostly focus on the same kind of things: prohibiting tabs, enforcing that indentation is done with a specific number of spaces or that spaces and tabs are not both used for indentation purposes.

As a side note, it should be said that there are several Ruby patterns regarding Indentation.

3. LINE LENGTH AND OTHER LENGTHS

Long lines make it difficult to read and understand code. Some of the patterns present at Codacy regarding line length:

  • Ruby — Line Length (default value is 80)
  • Python — Enforce line max length (default value is 120)
  • Java — Check long lines (default value is 80)
  • JavaScript — Excessive line length (default value is 200)
  • Scala — Enforce line max length (default value is 160)

It’s interesting to see that the default values differ from language to language, and out of these only Ruby and Java have the historic 80 as default.

JavaScript has a really high threshold, but the pattern is indeed called “Excessive”.

In any case, if you think about it and if you analyze a couple more languages, there might be some sort of correlation between the original creation of the language and the maximum line length recommended, which seems to imply that each language is still a bit tied to the screens available back when it was created.

Maximum line length vs Year of creation

Maximum line length vs. Year of creation (please try not to take this chart too seriously)

The correlation breaks in either JavaScript with a too high value or Scala with a too low value. There are several ways to look at this: maybe JavaScript developers, being front-end developers, have bigger screens; or maybe Scala developers, being some of the highest paid developers, are investing their money in smaller but higher quality screens.

There are also other places where length is taken into account:

  • JavaScript — Enforce identifiers limit length
  • Ruby — Method Length
  • Java — Enforces the care you should take when looking at class file lengths
  • Java — The Check validate abbreviations (consecutive capital letters) length in identifier name, it also allow in enforce camel case naming

Conclusions

Some best practices are best practices everywhere, albeit with a little tweak here and there.

Default values differ from language to language, but some things are simply good ideas everywhere (conversely, some other things are bad ideas everywhere).

Codacy

Not all of the patterns presented are enabled by default at Codacy, but the most relevant ones definitely are.

Add your project and start building better code today.


Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!


About Codacy

Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your  GitHub, Bitbucket or Google account to sign up.

GET STARTED

RELATED
BLOG POSTS

Regular Expressions: Best Practices
Pretty much every main programming language supports Regular Expressions, and many static analysis tools have patterns that relate to regular...
Integration with ESLint JavaScript Linter
This past year we’ve seen an incredible growth coming from ESLint, a linter on steroids for ECMAScript, JSX and JavaScript code. It quickly became the...
Programming languages: comparison of Best Practices, comments
Every main programming language implements comments and every developer out there has written at least a few (comments, not languages).

Automate code
reviews on your commits and pull request

Group 13