Automated code review

Enforce code quality on every commit and pull request and take charge of your technical debt


Announcing Ruby, Java support and fundraising

I’m excited today to bring you some news about Codacy.

We’re officially supporting two programming languages that developers have asked us to support inumerous times.

Starting today you can use Codacy to review and help maintain your Ruby and Java code.

We’ve also rolled out a way for you to support whichever language you’d like. Thanks to brilliant developers (special mention to Ryan Delaney).

We’re also very proud to announce our new funding round. Caixa Capital and Join Capital have now joined our current investors Espirito Santo Ventures and Faber Ventures (who also participated in the round) with a total of $1.1M.

At Codacy we’ve always been proud of the impact that we’ve been having per number of developers working in the company. Our objective is to continue serving our clients and users with a platform that saves incredibly precious time and frustration.

Our mission has always been to cut time out of code reviews. During the course of this year and the next one, our product will be laser focused on that purpose and our roadmap is very exciting.

We’re also hiring. Join us if code is your obsession.

Let us kill some of your code reviews today.

Read More

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

Untitled-1 copy

Fixing a “Too many open files” exception

Fixing a “Too many open files” exception

One of the many components of which Codacy is comprised started displaying, from time to time, a “Too many open files” exception. This was one of the hardest bug we’ve had to face to date, getting us to the point of pulling out our hair. Today, were sharing how we fixed it so that you can avoid pulling out yours. (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