Codacy Background Image

Review of Scala Static Analysis Tools

In the past we reviewed the different coding styles that the Scala programming language offers. We also saw in the last couple of months the apparition of a few new ones from Databricks and Paypal or the great Scala Best Practices from Alexandru that we didn’t mention.
Leif Wickland said “If your coding standard isn’t automatically and uniformly applied, you don’t have a coding standard” and I couldn’t agree more. At Codacy we believe that the enforcement of those guidelines should be outsourced to tools, and today we are going to review the main static analysis and linters that exist. (more…)

Read More


Developing with Code Reviews

Code reviews are a great tool to achieve higher quality code in a software development project.

Here at Codacy, code reviews are a crucial step of our development process. We’re currently following a software development methodology where each developer’s work is made in a feature branch, and upon feature completion, a pull request is created for that branch.

To be merged, each pull request requires two approves from other members of that team. We’re using this rule since our team had four developers, and it still works great now, with ten developers.

The pull request are the last control point before code joining the master branch, we’re production code lives. As a continuous deployment approach, our methodology assumes that once code is merge into the master branch, it’s ready to be deployed. In our case, after a merge the code is built and deployed to a staging environment. The staging environment is periodically or manually promoted to production at any given moment.

Still, code reviews can be a bottleneck in the feature pipeline and delay their deployment. So here are some best practices that worked for us and can help your team to keep a healthy speed.

Keep a schedule

Creating a schedule to maintain your team organized is a good way of keeping your team engaged. Reviewing code is often regarded as a “boring” activity by some programmers, so make sure you get everyone involved to minimize the load on each individual developer.


Before starting to code a new feature, discuss with your colleagues the major design and algorithm choices. This will help you gain a better understanding of the problem and collectively find better solutions. It also makes that reviewers are already familiar with the decisions you made in the code and have a easier time reviewing it.


I do believe in the “Don’t live with broken windows” motto. When you find a piece of code that you feel isn’t as good as it could be, you should always strive to improve it.
However, don’t do it in the middle of a feature. It’ll pollute your branch with unrelated changes, that the reviewer will have an hard time understand how they relate to the original intent of the pull request.

Instead, you can keep your personal list of things to improve when you’re in between features.

Think like a reviewer

Always be your own reviewer! I can’t stress this post enough. Always review your code before hand it over to the reviewers. It’ll help you get a perspective on the changes you made. Use this opportunity to analysis your code with a critical eye and strive for improvements. Think of what a reviewer would ask and clarify the code and/or add comments to explain your intent. This will also help you make sure that your code is definitely ready for review and prevent you from wasting the reviewers time.


As a team you should automated the review process as much as you can. Automate builds, tests and static analysis (using Codacy of course :) ). These help to speed reviews immensely. A human reviewer shouldn’t start reviewing if any of those steps fail. (Also, making sure a pull request includes test to feature developed is a critical point.)

I hope you and your team find these rules of thumb useful. If you have more tips on how to improve the productivity of code reviews and the happiness of your team, please share them in the comments below.

Read More


Codacy at the Tricity Scala Users Group

Last week we attended the Tricity Scala Users Group scala meetup where I did a short presentation about Codacy’s project structure and architecture. This blog post is a quick summary of the presentation I made. The slides are available here, or you can download them directly as a pdf here if you prefer.



I would like to thank Scalac and Sandra, our Developer Advocate, for the organization of the event. Patryk Jażdżewski also made a presentation about how to use Scala on Android with Scaloid. You can check his slides here.


Read More

Codacy Background Image

Why we chose Scala

We truly love Scala. Scala has been one of the pillars of Codacy from the start. Joao, who has an Enterprise Java background, has loved the language from the beginning and we’ve since taught Scala to new people joining in the company.


Initially, we wanted to have the expression power of dynamic languages without losing static type safety. We placed our bets on Scala and, judging from adoption rates, we believe this was a good decision. The type system is turing complete. This should say enough about its potential.

Scala has also helped us with hiring; typically, if someone is interested in working with Scala, they will probably be a good fit for us as a company. This is because a special spark in a engineer is needed for him/her to be curious and interested in working with new languages. Having said that, Scala is no longer a new language. Its adoption has been growing steadily and fueled by the big data movement and platforms such as Spark.

When defining Codacy’s architecture, we knew that the system we would have to build to analyze millions of lines of code per hour and would have to treat scalability, distribution and concurrency as first class citizens. We were already sold on Scala, since as I mentioned, we’ve been fans of the language for a long time. The process of choosing Play and Akka was simple: both are built for massive operations and have the backing of a strong growing company such as Typesafe. We treat every single operation as an immutable task for an actor. From parsing code, to dealing with code repositories, to applying code patterns to ASTs: everything is a task for us that we distribute to pools of actors. Akka excels at this job.

Now, we’re in a position where our current infrastructure demands further decomposition into services and that we break a monolith. Because we’ve modeled our system already in components, this has been easy from the architecture standpoint.

We are especially excited about the great work from the Scala team on Abide, Scala-Meta from Eugene Burmako and his team, and about the TASTY spec announced by Martin Odersky. It has many things we’ve been looking for to support customers interested in deeper code analysis.

Scala has been a great decision for us and it’s paying off in many ways.



Read More