«

»

Print this Post

Microsoft Dynamics NAV Source Code Analysis – LineCount

Microsoft Dynamics NAV Source Code Analysis – LineCount
1 vote, 5.00 avg. rating (96% score)

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:

NAV2017 W1 CU3 LineCount
Page<Reservation>.PROCEDURE<DrillDownTotalQuantity>

802

Codeunit<Intelligent Info Manifest>.PROCEDURE<ManifestText>

734

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

500

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

492

Page<Navigate>.PROCEDURE<FindRecords>

484

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<Sales-Post>.<OnRun>

1286

Codeunit<Purch.-Post>.<OnRun>

1276

Page<Reservation>.PROCEDURE<DrillDownTotalQuantity>

802

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

492

Page<Navigate>.PROCEDURE<FindRecords>

484

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<Reservation>.PROCEDURE<DrillDownTotalQuantity>

802

Page<Navigate>.PROCEDURE<FindRecords>

484

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

227

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

190

Page<Item Tracking Lines>.PROCEDURE<RegisterChange>

169

Page<Item Tracking Lines>.PROCEDURE<SetSourceSpec>

155

Page<Navigate>.PROCEDURE<ShowRecords>

147

Page<Item Tracking Lines>.PROCEDURE<WriteToDatabase>

133

Page<Apply Vendor Entries>.PROCEDURE<CalcApplnAmount>

127

Page<Apply Customer Entries>.PROCEDURE<CalcApplnAmount>

127

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

444953

464447

Total Functions

44137

47729

Average number of lines per function

10,08

9,73

Maximum number of lines in one function

1286

802

Code Lines on Pages

72191

77762

Total page functions that contains code

16998

17948

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.

Permanent link to this article: http://www.waldo.be/2017/03/02/microsoft-dynamics-nav-source-code-analysis-linecount/

9 comments

1 ping

Skip to comment form

  1. David Singleton.

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

    1. waldo

      Well .. I am lazy for sure!

    2. David Singleton.

      To Paraphrase Churchill.

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

  2. Guido robben

    Event functions have no lines. So the minimum is 0

    1. waldo

      Well .. I was counting C/AL code lines :-)

  3. R

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

    1. waldo

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

  4. A Random Passer-by

    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… :)

    1. waldo

      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 .. .

Leave a Reply

%d bloggers like this: