You’ve just gotten word that you may need to lay off some staff soon, and your CEO is asking you to justify the talent and resources in the org. You need solid data to answer that question.
You could just count lines of code written by each dev. But lines of code won’t show you how your teams are truly performing. It doesn’t matter if you’ve delivered a lot of code if it’s not what the business is asking for. You need a way to show that your whole org is invaluable because they’re delivering features faster and on time.
Remember, you only get what you measure. So if you’re only measuring lines of code, you’ll only get more lines of code, not necessarily quality code from a predictable and productive engineering org. We like the way Kathryn Koehler, Director of Productivity Engineering at Netflix, puts it:
In this article, we’ll show you how (and when) to count lines of code, and help you identify the problems that come up from using this metric incorrectly.
Pros and Cons of Counting Lines of Code
Although counting lines of code are an old practice, they’re not as useful as you may think today. But that doesn’t mean this metric is inherently bad. As with everything, it has its pros and cons.
Pro: Shows You Devs Are Actually Working
Teams who are writing code are clearly doing something. So by counting lines of code, you may get some takeaway as to whether devs are actually writing code or just looking at memes all day.
Con: Doesn’t Indicate Productivity Accurately
A junior dev may write a function in ten lines, while a senior dev can write it in just three. Does that make the junior more productive? Clearly not. And does that mean the senior dev was distracted all day? Also no. It just means they wrote the function more efficiently.
Pro: Could Help You Optimize Your Resources
Counting lines of code can show you how dense your project and its individual components are. This way, you can form a good idea of how complex and resource-intensive a task may be.
Con: Bloats Your Software
If your devs are convinced that lines of code are of utmost importance, they’ll start opting to write suboptimal code. This, in turn, will inflate your measurements, leading to longer PR processes because each review gets longer and longer. This also means you won’t be able to assess resources properly because your files will all be extra inflated.
Don’t be like Elon, don’t count lines of code!
Pro: Doesn’t Require Special Tools
Unlike other engineering benchmarks and metrics, counting lines of code is fairly simple. Most IDEs and even GitHub will automatically tell you how many lines are in a specific file.
Con: Creates a Hostile Environment for Devs
If teams are always focusing on their total lines of code, they can easily start believing they wrote more code than other teams. This will negatively affect the overall psychology of your engineering org. A little competition can be good, but that shouldn’t be the general atmosphere in your org.
Pro: Works Well for Non-Developers
Everyone understands big numbers. So when you’re trying to convey project size and complexity, everyone can understand that writing a thousand lines of code took more effort than writing a hundred.
Con: Leads to Stack-Ranking Individual Devs
Teams are just that — a group of developers working toward a shared goal. But if you always count lines of code to provide an easy-to-understand metric for your execs, they could start asking you to separate and rank devs based on their individual performance. This means devs will lose sight of the bigger picture, and may even end up turning on their teammates in a never ending game of who wrote more.
Pro: Helps Improve Your PR Process
When you count lines of code to track PR sizes, your teams can enforce rules for smaller PRs. With smaller, more digestible PRs, your PR process speeds up, and so does your cycle time.
Improve your code quality and developer workflow with smaller pull requests. Get started with your free-forever LinearB account today.
So it’s clear that counting lines of code isn’t as beneficial as many paint it to be. But again, it’s not all bad — you can still benefit from it if you use it right. So we’ll show you how to count lines of code properly.
Metrics for Counting Lines of Code
Most people think counting lines of code is as simple as opening their favorite code editor and seeing the lines of code in the project. But this method doesn’t show you how many lines are comments or formatting breaks. This means you won’t actually know how many lines are actually code.
On top of that, the process of counting raw lines of code is super tedious. You’ll have to go to every source file in the project, check the number in each file, and add all the values.
To count lines of code, simply open a file and check the number of the last line!
Raw Lines of Code
Even though it’s not the most efficient thing in the world, counting this raw number can still indicate when you might need to refactor something or break it down into smaller parts.
With LinearB, for example, we use this metric as a part of our high-risk work detection. Our platform checks all active branches and notifies you if any have received an update within the last seven days, have less than 50% of new work, and exceed 300 lines.
Lines of code might also indicate the sheer scale of what needs to be reviewed in a pull request. For example, our WorkerB bot uses lines of code to give you more context for your PRs. In fact, lines of code are essential to the adaptive data modeling approach that we use to calculate your estimated review time.
WorkerB’s estimated review time will help reviewers identify which PRs they can handle right away and which ones they’ll have to block off some time for. And when everyone can plan their schedule to handle PRs quickly, your org’s PR process will improve drastically, reducing your overall cycle times and improving your software delivery predictability!
In addition to WorkerB, gitStream can provide context to PRs (like estimated review time), automatically approve safe changes, or automatically assign the best reviewer for the job.
These automated programmable workflows help teams move faster, increase quality, and provide a great developer experience–which drives developer productivity.
Want to see it in action? Schedule a demo today!
Source Lines of Code
The next step in accurately counting lines of code is to identify a similar metric called source lines of code (SLOC). This metric doesn’t just count lines in a text file — it tries to filter out comments and empty lines.
Consider the for loop below:
for(let i=0; i<names.length; i++)
{
console.log(‘Name is ‘ + names[i]);
}This for loop has four lines of code. As you can see, it has two curly brackets, and each one is taking up an entire line, which is typical for JavaScript developers. Surely, these brackets shouldn’t count as two source lines of code, right? SLOC will filter out the two lines of source code from this for loop.
Source lines of code are more accurate than a raw count, but they still have some built-in uncertainty. So, another approach is to calculate statements.
Logical Lines of Code
To write a program to count logical lines of code, you could use semicolons to check the end of a line rather than using a carriage return.
This strategy will also help eliminate comments, which generally start with // in most languages. So, this will count the number of lines of code perfectly in Java, C++, and other traditional languages.
But semicolons aren’t necessary in some languages, like JavaScript and Python, so you’ll need different methods for different languages. But this can quickly get out of hand if your teams use several languages.
Most programs that count lines of code will include this sort of logic already, so you don’t need to worry about building a custom solution for your team’s needs. Let’s check some out!
3 Ways to Count Lines of Code
Your engineering leaders and devs don’t have to count lines of code manually or create programs to do that. We’ve got three methods your teams and team leaders can use to measure this metric instead.
1. VS Code Counter
VS Code has a handy extension that does all the heavy lifting for teams who use it. With VS Code Counter, teams can install this right into their IDEs and start tracking immediately. That way, everyone has access from the start, and no one needs to learn any complex terminal commands.
Here are some of the cool features that come with VS Code Counter:
- Counts lines of source code in whole workspaces and directories
- Tracks lines of code in your current file in real time
- Allows teams to configure how it interprets each tracked language with a .JSON file
Here’s what vs code counter will show us for our lines of code.
2. Counting Lines of Code Using cloc
One of the best applications for counting lines of code is cloc, a package that’s been around for nearly 20 years. After installing cloc, you can use it with most operating systems. Here, for example, we’re using Ubuntu in a Windows 11 system through Windows Subsystem for Linux.
If we pick a directory, cloc will return the results of every file within it if possible.
Here are some of the features cloc offers:
- Runs on any major OS, so teams don’t need to use a certain IDE or OS
- Can count lines of code in various archived and compressed file formats
- Outputs the results in a variety of formats, so teams can get the data they need in nearly any text format
3. Counting Lines of Code Using xargs
IIf you’re using Linux (or the Linux subsystem for Windows 11), you can simply use the built-in command xargs. This handy tool is a little more complex than our other two methods, as it will involve some complex terminal commands to get the results your teams need.
Here are some other xarg features:
- Comes built-into most OS, including most Linux distros, macOS, and Windows
- Allows teams to chain multiple commands together to get the data they need, so it’s more than just a program to count lines of code
You can count lines of code using the xargs command!
How to Use Lines of Code Correctly
Yes, knowing how to count lines of code can come in handy in some situations, but it’ll never be enough on its own. It won’t show you what your org is achieving, and it can’t tell you who’s struggling. And actually assigning too much value to this metric will likely lead you to run your org into the ground.
Instead, you need to get the proper context when you count lines of code with other engineering metrics as part of a holistic engineering metrics program. For example, LinearB helps you track how teams are actually performing. It’ll show you where the bottlenecks are and help you set goals to improve efficiency.
LinearB also gives you access to two workflow automation tools, WorkerB and gitStream. These will help you identify high-risk work, work that needs to be refactored, or work that may create bottlenecks in your pipeline delivery. And with them, you can finally track PRs and branches that start becoming excessively long, so teams can better separate tasks and reduce review time.
With this powerhouse, you’ll know exactly what your teams are working on without relying on lines of code. You’ll also be able to improve your PR process, boosting cycle time as a result.
