Microsoft Dynamics NAV Source Code Analysis – LineCount

Recently, I came across this nice graph: http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ . Pretty cool to see the comparison. But – obviously – the next question for us Microsoft Dynamics NAV developers is:

How many lines of code does Microsoft Dynamics NAV contain?

Good question .. and an interesting one. I always told people things like “it’s not easy to navigate in millions lines of code that you didn’t write yourself”. Assuming “millions” was a safe bet. But is it really? When I talk to people, sometimes I hear 2 million, and others even say “6 million”.

So, that’s about the same lines of code as a F-22 Raptor Fighter Jet .. or even the Mars Curiosity Rover. Honestly .. I don’t think so ..

Here are the real stats

This is what I came up with – I’m not saying it’s 100% .. but it should be pretty close to the real factual amount – it’s not an estimate at all 😉 . As the application “Microsoft Dynamics NAV” is much more than code alone .. the first thing I did was simply exporting all objects, and count the lines. So, to describe the application of NAV, including all (C/AL code, Metadata, descriptions, properties, .. whatever you can think of), for the W1 (only the ENU language), we need 3044075 lines of text.

“Only” 3 million lines, people. And that includes all the stuff we are actually not talking about when we talk “code”.

What about the C/AL code only??

Now THAT is the question I really wanted to answer. But that’s quite difficult to calculate. Because in that case, we need to analyze code as being code, not just text that can be both code or any other metadata.

You might remember this post, where I analyzed the “event publishers” with some ingenious dll that one of my developers has come up with.

Well, this dll has evolved to analyze code as well. Too bad I can’t share that, but what I can share are the results. And apparently, the total number of lines of C/AL code in Microsoft Dynamics NAV is “only” 464447, spread over 47729 places (functions, triggers, …).

When we’re at it…

This is fun stuff. So why not go a little bit further .. . I did some more checks, and here are a few things that I have come up with ..

As said, there are 464447 lines of C/AL code, spread over 47729 places. Basically, this means there is an average of 9.73 lines of code per function.

On top of this, the maximum amount of lines in one function is 801 lines. The minimum is 1 (surprise :-)).

The Top 5 Functions with the highest linecount is this:

You would have expected Codeunit80 and 90, wouldn’t you. Well, they were redesigned in NAV2017. In NAV2016, this would be the result:

Going further, what about things we do want to know, but like to avoid, like

Code on pages

Code on pages doesn’t necessarily need to be a bad thing. Pages is UI, UI can have code (formatting, matrix, wizards, ..) .. so you sure can have code on pages. Though, personally, I think it should always be checked. So, let’s check.

Well, in total, there is a staggering 77762 lines of C/AL code, spread over 17948 procedures and triggers in pages.

Here is an overview of the Top 10 pages with most code in NAV2017:

Besides the expected Matrix-pages, there are the expected “legacy”-pages as well: Reservations and Item Tracking – in my book the number one thing in NAV that really needs to be refactored.. .

So, can we conclude that most of the code is on Matrix-pages and Wizards? Well, unfortunately not. Without Matrix and Wizard pages, we still have 63104 lines of code, spread over 15201 places.

So, what is my conclusion?

Code analysis is a good thing to do. Not to point out the bad things, but to be aware of the places that might need attention. All code, the amount, on any place, probably has got his reason and definitely has got its history. The challenge for a Microsoft Dynamics NAV developer is to understand all this, and to make conscious decisions when modifying it.

What I did here, is I pointed out the “worst” cases in an old codebase. A codebase that people don’t want to change too much, just because of upgradability. And, a lot of these cases, is very easy explainable. Only one area really comes to mind that is not explicable: Item Tracking / Reservation (in need for refactoring for years already)

An average of 10 lines is very good. Just think of this – to compensate functions like the above top 10, you really need a lot of “good” ones, to end up with the decent average of 10. To conclude, let’s compare NAV2016 with NAV2017:

All good, but what I don’t like is the increasing amount of code on pages. I haven’t looked into that, but I honestly don’t believe it’s all UI formatting… . And in my book .. business logic just doesn’t belong on pages.

More to come

Doing this blog, I got more ideas that I would like to work out. Two of them are “Commits” and “Cyclomatic Complexity”. If you have more stats you’d like to see – just provide a comment, and I’ll see I get to it!

Disclaimer:

All the stats were made based on an internal tool that is still in beta. So I don’t want to guarantee the exact figures. However, we didn’t find any reason to doubt the output just yet.