Microsoft Dynamics NAV Source Code Analysis – LineCount

Recently, I came across this nice graph: . 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:

NAV2017 W1 CU3 LineCount


Codeunit<Intelligent Info Manifest>.PROCEDURE<ManifestText>


Codeunit<Office Add-In Sample Emails>.PROCEDURE<GetHTMLSampleMsg>


Codeunit<Item Tracking Navigate Mgt.>.PROCEDURE<FindTrackingRecords>




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

NAV2016 BE LineCount






Codeunit<Item Tracking Navigate Mgt.>.PROCEDURE<FindTrackingRecords>




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:

NAV2017 W1 CU3 LineCount




Page<Inventory – G/L Recon Matrix>.PROCEDURE<Calculate>


Page<Inventory – G/L Recon Matrix>.PROCEDURE<MATRIX_OnDrillDown>


Page<Item Tracking Lines>.PROCEDURE<RegisterChange>


Page<Item Tracking Lines>.PROCEDURE<SetSourceSpec>




Page<Item Tracking Lines>.PROCEDURE<WriteToDatabase>


Page<Apply Vendor Entries>.PROCEDURE<CalcApplnAmount>


Page<Apply Customer Entries>.PROCEDURE<CalcApplnAmount>


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:

NAV 2016 NAV 2017
Total C/AL Line Count



Total Functions



Average number of lines per function



Maximum number of lines in one function



Code Lines on Pages



Total page functions that contains code



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!


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.

5.00 avg. rating (98% score) - 2 votes

Permanent link to this article:


4 pings

Skip to comment form

    • David Singleton. on March 2, 2017 at 5:24 am
    • Reply

    So basically in simple terms you are saying … “Programmer are lazy” 🙂

      • waldo on March 2, 2017 at 9:42 am

      Well .. I am lazy for sure!

      • David Singleton. on March 2, 2017 at 9:54 am

      To Paraphrase Churchill.

      I didn’t have time to write you a short speech so I wrote a long one instead.

    • Guido robben on March 2, 2017 at 7:02 am
    • Reply

    Event functions have no lines. So the minimum is 0

      • waldo on March 2, 2017 at 9:42 am

      Well .. I was counting C/AL code lines 🙂

    • R on March 2, 2017 at 3:39 pm
    • Reply

    Keep it up man, quite an interesting post. It’d be interesting to see what the most used expressions are and such too.

      • waldo on March 2, 2017 at 4:23 pm

      Hm, interesting .. so, what exactly do you mean? Specific statements? Function names?

    • A Random Passer-by on March 12, 2017 at 7:43 pm
    • Reply

    Waldo said: “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”

    Total elements with Codelines: 47786
    Elements with 10 Codelines or less: 36152 (76%)
    Elements with 20 Codelines or less: 41965 (88%)
    Elements with 100 Codelines or more: 366 (0,8%)

    But your remark about COMMIT’s triggered my curiosity.
    I did not expect to find the following

    Total COMMITs: 630 (!)
    In Codeunits: 320
    In Pages: 130
    In Reports: 81
    In Tables: 98
    In XMLPorts: 1

    p.s.: A similar disclaimer as Waldo’s applies… 🙂

      • waldo on March 14, 2017 at 8:11 am

      Interesting :-).

      Very similar results, But not exactly the same. Maybe because the codebase slightly differs.. . I have a hunch on who you are – also using the Model.Tools, right? ;-).

      Thanks for the comments .. I’m going to drill into commits in the near future as well .. .

  1. […] Microsoft Dynamics NAV Source Code Analysis – LineCount […]

  2. […] my last blogpost on Source Code Analysis (which focused on the LineCount), I got the remark whether it would be interesting to drill into […]

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.