April 15, 2025

Episode 415: Waffles, Beer, and Code Cops: Food in Belgium, Source Code Analysis and LinterCop

Episode 415: Waffles, Beer, and Code Cops: Food in Belgium, Source Code Analysis and LinterCop

In this episode of Dynamics Corner, Kris and Brad are joined by Arthur van de Vondervoort for a lively conversation on source code analysis. The talk explores source code analysis, its benefits, and the tools available to developers, including LinterCop, a community-driven code analyzer for the AL language built on the Roslyn framework. Arthur elaborates on LinterCop’s evolution, its 90+ rules (with expansion plans), and its role in enhancing performance, security, and coding standards. Emphasis is on its ease of integration, customization potential, and ability to catch bugs early while highlighting the importance of team collaboration in defining coding rules and bridging cultural appreciation with technical innovation, showcasing how tools like LinterCop are shaping modern development. 

Send us a text

Support the show

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

00:00 - Episode Introduction with Arthur

05:42 - Life in Belgium & Cultural Exchange

10:58 - Understanding Source Code Analysis

17:22 - History of NAV Development & Analyzers

25:19 - Introduction to LinterCop Benefits

36:48 - Creating Custom Rules & Implementation

43:08 - Security Rules & Team Adoption

50:36 - Closing Thoughts & Connections

WEBVTT

00:00:00.542 --> 00:00:03.770
Welcome everyone to another episode of Dynamics Corner.

00:00:03.770 --> 00:00:06.607
Can cop analyze things?

00:00:06.607 --> 00:00:08.865
I'm your co-host, chris.

00:00:09.840 --> 00:00:10.542
And this is Brad.

00:00:10.542 --> 00:00:14.112
This episode is recorded on March 6, 2025.

00:00:14.112 --> 00:00:15.804
Chris, chris, chris.

00:00:15.804 --> 00:00:24.865
Another day, another great episode, another great discussion about rules and code analyzers.

00:00:24.865 --> 00:00:26.528
Source code cops.

00:00:26.528 --> 00:00:33.140
Do we have custom cops and beer With us today?

00:00:33.140 --> 00:00:48.009
We had the opportunity to speak with Arthur.

00:00:48.348 --> 00:00:58.634
Good morning Good afternoon.

00:01:01.296 --> 00:01:02.258
Good afternoon Hi.

00:01:02.817 --> 00:01:03.357
How are you doing?

00:01:04.359 --> 00:01:04.884
I'm doing great, excellent.

00:01:04.884 --> 00:01:05.367
I'll be here in Belgium.

00:01:05.367 --> 00:01:06.296
It's Thursday afternoon, hi, how are you doing?

00:01:06.296 --> 00:01:06.840
I'm doing great, excellent.

00:01:06.840 --> 00:01:13.272
I'll be here in Belgium Thursday afternoon, so looking forward for heading into the weekend almost.

00:01:14.481 --> 00:01:14.864
Excellent.

00:01:15.465 --> 00:01:15.746
Excellent.

00:01:16.159 --> 00:01:25.012
I'm envious when we talk with individuals that are ahead of us in time, because you're going to get into your weekend or to your evening before we do.

00:01:25.012 --> 00:01:36.108
I'm a little bit ahead of Chris so I can get into my evening and weekend and I let him know that regularly how I'm starting my weekend or I'm already into my evening while he's still working.

00:01:36.108 --> 00:01:37.825
So I feel like just a little bit.

00:01:38.060 --> 00:01:44.411
But you go back to work before me, so I get to savor my weekend at least.

00:01:48.120 --> 00:01:49.081
Oh, I go back to work way before you.

00:01:49.081 --> 00:01:51.144
Yeah, for many reasons, for many reasons.

00:01:51.144 --> 00:01:54.831
So, uh, I've never been to belgium.

00:01:54.831 --> 00:01:58.903
I would like to go to belgium oh, you should absolutely do that.

00:01:59.082 --> 00:02:00.344
it's a fantastic year.

00:02:00.344 --> 00:02:06.155
Um, I'm originally from the Netherlands and then I moved over here to Belgium.

00:02:06.155 --> 00:02:07.865
I think it's a great country.

00:02:07.865 --> 00:02:16.528
It has some complexity on structures and everything, but I like the mentality and hospitality that's here in Belgium.

00:02:16.528 --> 00:02:22.747
So every year we have also BC Tech Days, of course, so you're more than welcome.

00:02:23.469 --> 00:02:24.091
Yes, yes.

00:02:27.680 --> 00:02:28.481
But no, I really like it here.

00:02:28.481 --> 00:02:44.784
It's more smooth going and I'm living in the green area of Belgium and it's called the Kempen, so there's a lot of green around us, of nature, so that's a really lovely place here to live in.

00:02:46.502 --> 00:02:56.347
I like the green areas that's interesting that they call it the green area and all the conferences in Europe I would love to get to and I try to get to every year.

00:02:56.347 --> 00:02:57.746
It's just a challenge.

00:02:57.746 --> 00:03:02.724
I'm certain if you've ever come to the United States it's not so close.

00:03:02.724 --> 00:03:12.008
We're so close with each other from communication and talking, but sometimes there's quite a bit of logistics that need to go into it and sometimes we just got to get on a plane and do it.

00:03:12.008 --> 00:03:18.091
I'm hopeful that you know SpaceX or something will be able to just make a rocket to fly us over the pond.

00:03:19.280 --> 00:03:20.623
They're trying to bring back that.

00:03:20.623 --> 00:03:25.383
Supersonic flights Was the Concorde.

00:03:25.383 --> 00:03:27.921
Yeah, yeah, they're trying to bring about concord.

00:03:27.921 --> 00:03:30.227
That'd be amazing to be able to get on that.

00:03:30.227 --> 00:03:33.533
Just get to europe quickly and uh.

00:03:33.533 --> 00:03:38.087
Then, yeah, I'll definitely fly, I'll definitely go there much easy.

00:03:39.270 --> 00:03:48.641
Uh, he has something to do with some safety stuff, I think, and many other factors, and that's why they stopped the noise.

00:03:48.641 --> 00:03:54.052
The environmental factor, I think, was one of the reasons why they stopped.

00:03:54.052 --> 00:04:11.954
And so they're trying to build a technology on those where it'll minimize the noise that sonic boom it makes, I guess apparently, minimize the noise that sonic boom it makes, I guess apparently, and once they figure that out we'll be back on bringing those flights across intercontinental.

00:04:11.954 --> 00:04:12.713
That would be amazing.

00:04:12.993 --> 00:04:13.615
That would be great.

00:04:13.615 --> 00:04:24.355
I did have a lot I'd like to speak with you about, but speaking about Belgium, is that where the Belgian waffle started?

00:04:24.375 --> 00:04:25.959
That's a good question.

00:04:25.959 --> 00:04:30.682
I'm not sure, to be honest.

00:04:30.682 --> 00:04:31.244
That's a very good question.

00:04:31.244 --> 00:04:33.430
I do think it's really a thing you have to try if you're here in Belgium.

00:04:33.430 --> 00:04:42.312
If I did some holidays here in Europe and stuff, nothing beats a Belgian waffle In other parts of Europe.

00:04:42.312 --> 00:04:43.302
It's still different.

00:04:43.302 --> 00:04:50.490
There are a few things here in Belgium that I just have to taste here to get a great experience on it.

00:04:50.490 --> 00:05:01.343
It's strange because the recipe is known and it's not hard to make a waffle if you look at the recipe, but if you then taste it in another country it's still different.

00:05:01.343 --> 00:05:05.629
So that's a funny thing from here.

00:05:05.629 --> 00:05:07.026
But we have more delicious things.

00:05:07.026 --> 00:05:07.461
Of course.

00:05:07.461 --> 00:05:09.788
We can talk hours of all kinds of beer.

00:05:11.884 --> 00:05:12.747
Oh, Belgian beer.

00:05:14.682 --> 00:05:16.067
It's a luxury beer.

00:05:16.067 --> 00:05:25.483
That's how you get quite easy used to it Because, coming from the Netherlands, we had a few beers on there and then moved over to Belgium.

00:05:25.483 --> 00:05:30.014
Then I really experienced what beers could do and what tastes and flavors there are.

00:05:30.014 --> 00:05:42.196
But then again, if you go across Europe and also maybe in other parts, it's not quite common to find a real good Belgian beer.

00:05:44.541 --> 00:05:46.048
I wish we had something like that here.

00:05:46.048 --> 00:05:47.225
I don't know what people think of.

00:05:47.225 --> 00:05:50.065
When you think of the United States, what do you think of for food?

00:05:50.065 --> 00:05:53.110
Because I hear Italy, I think of pizza and wine.

00:05:53.110 --> 00:05:55.327
I hear France, I think of pastries.

00:05:55.327 --> 00:05:57.769
I hear Belgium, I think of waffles and beer.

00:05:57.769 --> 00:06:01.790
I think of Ireland, I think of whiskey.

00:06:02.800 --> 00:06:03.704
And I'm not saying, this is the.

00:06:04.579 --> 00:06:05.533
Yes, and Guinness whiskey, right, and I'm not saying this is the.

00:06:05.533 --> 00:06:07.911
I'm not saying yes, and Guinness beer, but I primarily think of whiskey and Guinness.

00:06:07.911 --> 00:06:14.649
But you have some countries and I'm not saying that's the only thing, that's there, I'm just saying from a food product point of view.

00:06:14.649 --> 00:06:27.892
That's what comes to my mind, based on what I hear, because I've only been to countries on this side of the world, so I haven't been to any European countries.

00:06:27.892 --> 00:06:32.112
But what do you think of food-wise when you hear the United States?

00:06:33.721 --> 00:06:34.646
It's funny that you say so.

00:06:34.646 --> 00:06:36.326
We share that little bit in common.

00:06:36.326 --> 00:06:38.447
I only have on this side of the ocean.

00:06:38.447 --> 00:06:44.970
I've never been across the other side, to be honest, so only from a European guy perspective.

00:06:44.970 --> 00:06:54.341
If I think America, the first thing for me is a little bit thinking of burgers, the first part burgers good yeah, but it has it to be.

00:06:54.682 --> 00:06:55.865
Uh, that has to be a bad thing.

00:06:55.865 --> 00:07:04.507
Um, of course you have your mcdonald's kind of area, but a good quality burger I can also really appreciate that, so it's not really bad.

00:07:04.507 --> 00:07:06.432
But that's something that pops in my head.

00:07:06.432 --> 00:07:07.514
I can't explain why.

00:07:10.346 --> 00:07:10.887
That's good.

00:07:10.887 --> 00:07:21.425
That's exactly what I was looking for Because, as I had mentioned, I hear countries and I think of I must say a lot about me, but I immediately think of food products that I think of from those countries.

00:07:21.425 --> 00:07:23.754
So I've been curious to know what others from Europe, such as yourself, think of for food countries.

00:07:23.754 --> 00:07:28.367
So I've been curious to know what others from Europe, such as yourself, think of for food when they hear the United States.

00:07:29.290 --> 00:07:41.290
A quick question when you talk about beer, are beers typically served room temperature in Belgium, Not like ice cold beer?

00:07:43.401 --> 00:07:44.326
Not room temperature.

00:07:44.326 --> 00:07:45.766
That's not going to be okay.

00:07:45.766 --> 00:07:55.507
It's cold, but it doesn't have to be freezing cold, but it has to be chilled from a refrigerator part, otherwise it's now.

00:07:55.507 --> 00:08:01.867
Maybe there are some that are better if they're going to room temperature, but it's not common to do that.

00:08:01.867 --> 00:08:03.947
I don't think I can have a warm beer.

00:08:04.862 --> 00:08:05.745
How about sour beer?

00:08:05.745 --> 00:08:08.509
Do you guys have sour beer in Belgium?

00:08:11.261 --> 00:08:12.526
What do you mean by sour beer?

00:08:12.660 --> 00:08:12.901
Can you?

00:08:12.920 --> 00:08:13.846
help me a little bit on that.

00:08:14.740 --> 00:08:28.841
I guess it's a certain thing that maybe Germany has some sour beer and it's kind of a sour beer is is trying to pick up here, at least where I'm at in washington state.

00:08:28.841 --> 00:08:59.967
But you know, washington state is, I think, one of the biggest producers of hops in the us and so they're starting to bring in uh, sour beer and so they're typically served as kind of like room temperature and it's it's really a little bit of sour and it's sometimes a different taste or different flavors, like there was one time I drank a key lime pie sour beer and it's beer, but I can taste key lime pie, which is amazing, so it's pretty interesting.

00:09:01.322 --> 00:09:02.580
Key lime pie is really good.

00:09:02.580 --> 00:09:08.884
I don't know if I'd have a key lime pie flavored beer and sour beer and hops.

00:09:08.884 --> 00:09:09.125
I'm.

00:09:09.125 --> 00:09:10.448
I've gotten to the point now, chris.

00:09:10.448 --> 00:09:11.731
Everything you say I'm grokking.

00:09:11.731 --> 00:09:16.450
So you, you gave me oh you were correct, washington's is.

00:09:16.770 --> 00:09:21.687
According to grok, again, washington is the state in the us that produces the most hops.

00:09:21.687 --> 00:09:26.375
In 2023, it accounted for approximately 76.6 million pounds of hops.

00:09:26.375 --> 00:09:36.424
You were supposed to be the Chris GPT, but now, just on the Grog, grog, bad Grog I hear some of these things and now I'm going to have to.

00:09:36.424 --> 00:09:41.368
I'm redoing my setup after this to have Grog on speed typing.

00:09:41.368 --> 00:09:44.850
I'll move my setup around so I can type all this stuff up.

00:09:44.850 --> 00:09:48.885
I enjoy the beer conversation.

00:09:48.885 --> 00:09:55.107
I enjoy the food conversation even more, but that's not the reason why we're all here today.

00:09:55.107 --> 00:09:59.067
But before we jump into the conversation, would you mind telling everybody a little bit about yourself, please?

00:10:00.340 --> 00:10:03.583
Yeah, absolutely, my name is Arthur van de Vondelvoort.

00:10:03.583 --> 00:10:28.753
I work as a solution architect at Verrui here in Belgium, where most of the days I spend on Business Central as part of the product, but also I like the areas around it, like, of course, the Power Platform, but also DevOps is also an area of interest of me, so I'm moving around in that area a little bit of the product in our community.

00:10:29.902 --> 00:10:44.013
Excellent, excellent, and I've been talking with Chris and others a lot about development standards and how individuals create code and put together their code and structure their code.

00:10:44.013 --> 00:10:59.571
And one of the things that's available within VS Code or for the AL language excuse me, when you're using VS Code now, others are using other environments as well is source code analyzers, and word on the street is there are many.

00:10:59.571 --> 00:11:04.870
There are a few, but you're one of the source code analyzer guys to go to if you have any questions.

00:11:04.870 --> 00:11:09.428
So, if you would, can you tell us a little bit about source code analysis and what it is?

00:11:10.731 --> 00:11:11.573
Yeah, absolutely.

00:11:11.573 --> 00:11:16.947
The source code analysis is from the product.

00:11:16.947 --> 00:11:18.952
Microsoft also includes three of them.

00:11:18.952 --> 00:11:25.870
You have the UI cop, the code cop and then an extension cop and also for AppSource one.

00:11:25.870 --> 00:11:31.083
So four of them in total and what they will help you is well doing development.

00:11:31.083 --> 00:11:56.988
So your NVS code, your app writing code, and it will then immediately analyze every line of rule that you write to see if there are maybe code smells or some things that could go wrong, and it will then help you do the development already to see are there things I need to change or things that maybe can go wrong, or are there some problems in your code.

00:11:56.988 --> 00:12:00.047
That's really doing that without even running the code.

00:12:00.047 --> 00:12:18.691
So there inside your VS Code, it's already like more of an assistant that looks over your shoulder and then if you do a wrong syntax or something, it will gently say to you oh, look over there, maybe you should try something else or that's not going to work.

00:12:18.691 --> 00:12:21.970
So more like maybe, an assistant role.

00:12:21.970 --> 00:12:24.347
You can look at it a little bit like that.

00:12:25.320 --> 00:12:27.125
So source code analysis.

00:12:27.125 --> 00:12:28.309
Would you classify it?

00:12:28.309 --> 00:12:31.886
You had mentioned that within VS Code we have four analyzers.

00:12:31.886 --> 00:12:44.428
Would you mention it to be more of a syntactical, cosmetic-type analysis, or a functional-type analysis, or both?

00:12:46.586 --> 00:12:49.200
I believe my opinion is that it will do both type analysis or a functional type analysis, or both.

00:12:49.200 --> 00:12:52.149
I believe my opinion is that it will do both.

00:12:52.149 --> 00:12:55.285
It will mostly, indeed, run on the syntax.

00:12:55.285 --> 00:12:56.453
That is the most easy part to analyze.

00:12:56.453 --> 00:13:07.407
It will also look on the structure of your code or how the codes interact with other parts from other parts of code or maybe other extensions we have a dependency on.

00:13:07.407 --> 00:13:10.706
So it'll try to figure out as much as possible.

00:13:10.706 --> 00:13:18.850
So it's not only the syntax but it's more of an whole package that it can cover to analyze on.

00:13:20.360 --> 00:13:28.629
I'm a big fan of source code analysis, just for many reasons, but I often wonder how does it work, right?

00:13:28.629 --> 00:13:35.214
So it's how does it work and how does it really analyze the code?

00:13:35.214 --> 00:13:47.368
And then also word on the street, as I say, is you also participate in another source code analyzer, so you may be able to tell us a little bit of how the analysis works?

00:13:47.368 --> 00:13:56.466
Because, just like with many things, the concept is great, I understand it, but the practical application of it is challenging.

00:13:56.586 --> 00:14:03.789
Okay, I think we have to get a little bit back in time.

00:14:03.789 --> 00:14:11.774
If we go back to the Nevision timeframe, we had the good old seaside development.

00:14:11.774 --> 00:14:21.990
We had our own development environment within the application itself and you can write the code in there, and that was okay-ish.

00:14:23.052 --> 00:14:25.687
Well, okay-ish, we called it the Wild Wild West.

00:14:25.687 --> 00:14:28.745
Back in the early days.

00:14:28.745 --> 00:14:31.000
It was the Wild Wild West, I think.

00:14:31.000 --> 00:14:35.250
Now, eventually, when they gave you the breaks for the functions, you know where they had the bar.

00:14:35.250 --> 00:14:43.628
Early in the days, back when I started, it was just basically a text file within the development environment and you couldn't do anything.

00:14:43.628 --> 00:14:49.052
So I really need to get my hands on version 1.2.

00:14:49.052 --> 00:14:52.888
I don't know if you could get a license for it, but I started with version 1.1.

00:14:52.888 --> 00:14:58.687
I would love to go back in time and install that and take a look at it or even all of the subsequent versions.

00:14:58.860 --> 00:15:00.767
But I don't mean to interrupt.

00:15:00.767 --> 00:15:01.609
Go back to the OK-ish.

00:15:03.760 --> 00:15:09.808
No, no, it's good to know, because I think that's a great example to start on, because it felt a little bit like programming in Notepad.

00:15:09.808 --> 00:15:23.966
That was kind of thinking what you're doing right, so if you make a syntax error or everything, you would get punished if you rolled it out to a test environment, or if you're unlucky, you'll notice it when it's in production.

00:15:23.966 --> 00:15:32.466
That was the era we were used to, maybe as an Envision developer and I also had those days.

00:15:32.466 --> 00:15:36.571
I started really on development in NAV 2017 something-ish.

00:15:36.571 --> 00:15:55.028
So I know the hurdle of exporting FOP files or exporting to TXT files, and now, with some tools, merging some of your code with your colleague codes and all that fun stuff notepad-wise to develop on, and with Business Central.

00:15:55.028 --> 00:16:06.024
I think it was a huge opportunity and I really think it was awesome that we then moved over to a modern development toolset maybe the right word on it.

00:16:06.024 --> 00:16:10.860
So we received VS Code where we can develop them we have.

00:16:10.880 --> 00:16:24.250
The AL language was then brought on and also other kind of stuff like, for example, git was just a normal factor, and all those things that were new for us were, in other programming languages, quite common to use.

00:16:24.250 --> 00:16:32.172
If you look, for example, if you are a C-sharp developer, it's quite normal to have your VS Code or Visual Studio.

00:16:32.172 --> 00:16:35.970
You have Git all the stuff that was new for us back in those days.

00:16:35.970 --> 00:16:50.832
They were already using it and quite good at it, and the great part is that when we moved over to the AL language, the code analyzer was also a part that's already in there for C-sharp developers already there.

00:16:50.832 --> 00:16:54.405
Microsoft has provided a platform on that.

00:16:54.405 --> 00:16:57.452
It's under the hood, it's called the Roslyn Analyzer.

00:16:57.452 --> 00:17:02.548
That's a framework that can analyze your code for you in development.

00:17:02.548 --> 00:17:12.188
So if you, for example, would do a C-sharp project, you'll also get maybe warnings or errors or info messages right there in Visual Studio.

00:17:13.180 --> 00:17:24.984
So Roslyn is another architecture or language or application that's within the AL language, to help with the source code analysis or the source code structure.

00:17:26.169 --> 00:17:26.450
Correct.

00:17:26.450 --> 00:17:30.788
The AL language is depending on Roslyn, as I think it's a framework.

00:17:30.788 --> 00:17:43.131
If I'm not mistaking, the AL language is depending on that to help to analyze the code on it and the benefit of it is that it's not only specific for the AL language.

00:17:43.131 --> 00:17:47.810
More languages can use the Roslyn analyzer, so that's a great benefit of that.

00:17:47.810 --> 00:17:56.326
Of course, it has some adaptions on it for the specific syntaxes of the AL language, like a code unit or that kind of stuff.

00:17:58.612 --> 00:18:02.690
Okay, and with the source code analysis, just to go back.

00:18:02.690 --> 00:18:04.227
So Microsoft has four.

00:18:04.227 --> 00:18:09.251
You have the UI, which I think will help with some UI structure.

00:18:09.251 --> 00:18:19.807
You have the AppSource analyzer, which has specific rule sets, for when you submit an app to AppSource, there are certain rules that need to be applied.

00:18:19.807 --> 00:18:22.567
You have two other ones you had mentioned.

00:18:23.701 --> 00:18:26.891
You have the general CodeCop analysis.

00:18:26.891 --> 00:18:28.746
That will be more of a generic approach.

00:18:28.746 --> 00:18:34.531
We'll look at if there are some syntaxes that maybe aren't right.

00:18:34.531 --> 00:18:41.270
That's not specific targeting, that's more looking at the syntax of the code itself.

00:18:41.270 --> 00:18:44.046
And you mentioned the UICop.

00:18:44.046 --> 00:18:46.877
For example, tooltips are there, maybe an option?

00:18:46.877 --> 00:18:49.515
Are there or set visibility of fields?

00:18:49.515 --> 00:18:55.710
And then you also have, of course, depending on if you go to AppSource or a per-tenant extension.

00:18:55.710 --> 00:19:02.339
Both of them have their own AppSource cop and for a per-tenant extension it will, for example, look at the object numbers.

00:19:02.339 --> 00:19:06.339
That has to be in the 50,000 to 100,000 range, for example.

00:19:06.339 --> 00:19:13.894
That kind of stuff will help one of those code analyzers help you with to make those mistakes during your development.

00:19:14.339 --> 00:19:15.153
Excellent, excellent.

00:19:15.153 --> 00:19:16.368
You with to make those mistakes during your development, Excellent, Excellent.

00:19:16.368 --> 00:19:22.905
You know I always end up putting the per-tenant extension and the app source extension excuse me analyzer.

00:19:22.905 --> 00:19:26.104
It's been one of those mornings.

00:19:26.104 --> 00:19:28.088
I'm lost.

00:19:28.088 --> 00:19:36.634
I often put the per-tenant extension analyzer and the app source extension analyzer together in a project.

00:19:36.634 --> 00:19:44.173
I always just use all of them and I always have to put in a suppression of warnings for the ID.

00:19:44.173 --> 00:19:46.305
It's interesting enough.

00:19:47.101 --> 00:19:47.522
That's funny.

00:19:47.522 --> 00:19:51.289
You mentioned that there are more colleagues also there, I know of them.

00:19:51.289 --> 00:19:53.468
They also said I'm not going to use one or the other.

00:19:53.468 --> 00:19:55.309
I'm going to use both of them because both of them have.

00:19:55.309 --> 00:19:55.715
They also said I'm not going to use one or the other.

00:19:55.715 --> 00:20:11.749
I'm going to use both of them because both of them have interesting rules for, depending on what I say One step back, let's go to sentence that again you can use both of them because there are some rules in the EpsosCOP that are also valid for a patented extension.

00:20:12.500 --> 00:20:17.144
For example, we still need to have prefixes or suffixes on our objects.

00:20:17.144 --> 00:20:22.346
The namespacing is getting less and less depending, but as of today we still need them.

00:20:22.346 --> 00:20:28.345
A rule for that is in the AppSource pop code analyzer, not in a patented extension.

00:20:28.345 --> 00:20:40.746
But it is a good practice to also have that for your PTs Patented extension also, to have that rule active that you don't forget to set a suffix or a prefix on your objects.

00:20:40.746 --> 00:20:44.252
So you can also have all four of them active.

00:20:44.252 --> 00:20:51.662
But then you have to suppress some specific rules that don't apply for the target you're targeting on your extension.

00:20:52.544 --> 00:20:54.488
I'm happy to hear that I'm not alone in that.

00:20:54.488 --> 00:20:57.981
That makes me feel good, absolutely so.

00:20:57.981 --> 00:21:10.450
With those four extensions, and as I started to get into a few moments ago, there's another code analyzer that is quite popular among AL development and that's Linterkop.

00:21:10.450 --> 00:21:17.105
So it's a fifth code analyzer, correct, and can you tell us a little bit about Linterkop?

00:21:18.190 --> 00:21:18.671
Absolutely.

00:21:18.671 --> 00:21:23.890
Linterkop is a community-driven code analyzer.

00:21:23.890 --> 00:21:37.207
I have to do a shout-out to Stefan Moran on that, and I think it was September 21 that he paved the road a little bit to create a fifth one.

00:21:37.207 --> 00:21:41.069
He called it Lintocop as an open source code analyzer.

00:21:41.069 --> 00:21:48.450
So that's free available on GitHub so you can use it and see how it's built and worked.

00:21:48.450 --> 00:21:54.932
And he started that Lintocop back in 2021.

00:21:54.932 --> 00:21:57.645
And I've got it on my radar.

00:21:57.645 --> 00:22:02.625
I think like a half year later, something is beginning on 2022.

00:22:03.720 --> 00:22:05.184
And I was quite enthusiastic about it.

00:22:05.184 --> 00:22:09.785
There are some great rules already in there in the beginning that I said.

00:22:09.785 --> 00:22:14.185
It's quite obvious to have them and to help you during your development.

00:22:14.185 --> 00:22:23.205
What's always in my head is why I do really like the LinterCop as a product and also the other ones, of course.

00:22:23.205 --> 00:22:32.026
It will help you resolve problems by taking away its root cause.

00:22:32.026 --> 00:22:34.865
What am I going to say with that?

00:22:35.259 --> 00:22:47.265
In my previous company, when sometimes I was struggling with something or trying to solve a problem, I know my boss already asked me what problem are you trying to solve, artur?

00:22:47.265 --> 00:22:48.023
What's going wrong?

00:22:48.023 --> 00:22:55.285
And I can explain what was going wrong and why and all the stuff around it, and he challenged me always with.

00:22:55.285 --> 00:22:57.570
But what was the root cause?

00:22:57.570 --> 00:23:01.343
Can we take away the root cause that the problem will never reoccur again?

00:23:01.343 --> 00:23:11.262
That was really a helpful mindset for me that instead of trying to fix the problems, why don't we take away what's causing it, before the problem even can occur?

00:23:12.920 --> 00:23:17.105
And Linterkop has a quite simple rule that I think is fantastic.

00:23:17.105 --> 00:23:48.645
The first rule of the collection is if you, for example, make a flow field type in the product, that's mostly a field that is being calculated and then shown on a page or on a list, for example, for the user, by default that field is editable, and that is a little bit strange Because, for example, you go to your customer overview and you see that the balance is calculated, but then you can write something over that field, and that's, of course, strange.

00:23:48.645 --> 00:23:59.705
There are maybe some scenarios that it could be OK, but most of the time it's strange to have a calculated field that you can add it on as the user.

00:23:59.705 --> 00:24:04.289
And to prevent that, lintercop will during development.

00:24:04.380 --> 00:24:14.208
If you make a field like that, you forget to set a property it's already in VS Code show you a warning or a diagnostic.

00:24:14.208 --> 00:24:27.087
That is a flow field and you're advisable to set the property and it's able to false, and in that way I think it's quite helpful because as a developer, you can maybe forget to set a property.

00:24:27.087 --> 00:24:29.747
Everything you test works.

00:24:29.747 --> 00:24:35.488
You ship it off to maybe your consultant or the customer and then you can get that feedback back from.

00:24:35.488 --> 00:24:36.342
I see a problem.

00:24:36.342 --> 00:24:49.107
That field should be editable and you have to do the cycle again to modify your code, releasing all the steps, and you can take away that causing the problem by, for example, using Lintacop.

00:24:49.107 --> 00:24:57.115
So that's what I really like about it it will help you take away, maybe, the causing of a problem instead of trying to fix your problems.

00:24:58.479 --> 00:24:58.799
That's good.

00:24:58.799 --> 00:25:12.036
So Lintocop is a code analyzer that you use in addition to the other standard AL code analyzers that will help come up with resolving problems that you just mentioned.

00:25:12.036 --> 00:25:24.968
That whole editable flow field, that was a problem way back in the early days as well because it did some strange things to your data if you edited a flow field Early on.

00:25:24.968 --> 00:25:33.328
If you edited a flow field that was a sum of data it would actually change the data in a sense underlying of it.

00:25:33.328 --> 00:25:39.284
But way back, I haven't tried it now because I've been so used to making flow fields non-editable.

00:25:39.284 --> 00:25:40.666
It's just out of habit.

00:25:40.666 --> 00:25:50.262
But I have to do a quick test, if you can if you change the value, what happens with the underlying data that it's calculating, or if at this point it just looks strange.

00:25:50.262 --> 00:25:56.133
So that's a little go back in time way back oh wow, I didn't.

00:25:56.452 --> 00:26:00.644
I didn't know it would change your data, that's that's mind-blowing.

00:26:00.705 --> 00:26:17.864
Unless my dinosaur brain forgets and I assumed it, but I remember back in the earlier versions of nav, if you edited a flow field, it would adjust the data to make sure that the total matches, or something like that oh wow, the source data would adjust it yeah interesting.

00:26:17.864 --> 00:26:20.631
I could be talking, you know, sideways, but that's what I remember.

00:26:20.631 --> 00:26:24.568
It's um that's dangerous yes, that's why.

00:26:25.030 --> 00:26:29.182
That's why he said the number one rule is to make a flow field non-editable.

00:26:29.182 --> 00:26:36.713
Yeah, and I think if I were a betting man it'd go way back in time to then back to the days of editing in Notepad.

00:26:36.713 --> 00:26:37.315
I like that.

00:26:37.315 --> 00:26:42.792
That's a great analogy to what it was like editing or developing in Notepad.

00:26:43.240 --> 00:26:47.007
But, this was over 20 years ago too, so a lot of improvements have been made.

00:26:47.007 --> 00:26:54.032
So Lintocop works in addition to the Microsoft code analyzers that come as part of the application.

00:26:54.032 --> 00:27:11.286
With it being community-driven, the community, in essence, can come up with their own standards as well, I guess, because with many languages there is nice to have some sort of standardization, because as applications get moved from developer to developer, other developers come onto a product.

00:27:11.286 --> 00:27:13.827
It's nice to have some sort of standard.

00:27:13.887 --> 00:27:27.336
I guess you could say Absolutely, and it's getting more of a Swiss Army knife it's becoming, because now you're, for example, mentioning also standards to use on.

00:27:27.336 --> 00:27:29.240
There are, I think, currently more than 90 rules on it.

00:27:29.240 --> 00:27:36.133
I think this year we're going to cap the 100 different rules in there, and it's a mix of different kind of stuff.

00:27:36.133 --> 00:27:51.190
It could be for structure parts on it how should something look, or something involved but also there are some stuff on performance, some stuff on also linting a bit, a little bit of security.

00:27:51.190 --> 00:27:55.847
It's going multiple directions, so it's not focusing on one thing.

00:27:55.847 --> 00:28:03.994
It's getting more, broader and broader to indeed try to solve as much ground as possible to help improving.

00:28:05.621 --> 00:28:06.844
See, I like that.

00:28:06.844 --> 00:28:11.800
It does more than just formatting standards you had mentioned.

00:28:11.800 --> 00:28:17.865
It can also help catch some performance considerations as well, too, within the code.

00:28:18.867 --> 00:28:19.490
Yeah, absolutely so.

00:28:19.490 --> 00:28:28.465
The name Linterkop is quite known, so I don't think we're going to change that, but it started a little bit, I think, in that direction.

00:28:28.465 --> 00:28:33.305
Then it grew with help of the community and that for performance.

00:28:33.305 --> 00:28:35.946
It has a few nice rules.

00:28:35.946 --> 00:28:44.343
But for example, like is we're all known to the log table command we can use In some scenarios.

00:28:44.343 --> 00:28:49.008
It's necessary to use that for processing data in some scenarios.

00:28:49.008 --> 00:29:19.845
But recently not recently, I think, only two or three versions ago-ish we have the new property read isolation, so we could get more granularly set that instead of the log table and that's something the code analyzer also will detect what version you're programming against of your extension and it will then show a diagnostic on all your log table you have in your extension to change that and update the new read isolation.

00:29:19.845 --> 00:29:22.487
That's a better approach on it.

00:29:23.660 --> 00:29:24.944
And also some other fun stuff.

00:29:24.944 --> 00:29:43.365
For example, if you have the general letter entries, for example, and you have some function you want to know do account that's equals to zero, for example, and you have some function you want to know do account that's equals to zero, for example, if you'd have that encode, it will do a full run on the whole table to figure out.

00:29:43.365 --> 00:29:46.307
Is it really the result zero?

00:29:46.307 --> 00:30:04.894
But we also have the isEmpty calls added to the product a while ago and it's much more performance than doing account, because account will do some stuff on indexing, on SQL stuff and it's more heavy for the SQL server to come up with and as empty as it's blazing fast.

00:30:04.894 --> 00:30:18.402
So also there are some areas where LidlCop will help you improve your code to uptake new features that were there or to gently help you to switch some syntax in to have a better performance on it.

00:30:19.845 --> 00:30:29.803
So LinterCop you had mentioned has 90 rules to date and this year you're expecting that it would go over 100 rules.

00:30:29.803 --> 00:30:44.902
When using LinterCop, can you enable and disable the rules, similar to what we can do with the standard code analyzers through pragmas, through rule sets or through suppression, warnings or suppression?

00:30:44.902 --> 00:30:46.387
Yes, suppression in the app file.

00:30:48.381 --> 00:30:54.290
Yeah, the great part is that LinterCop behaves exactly the same as the other code analyzers.

00:30:54.290 --> 00:30:59.048
That ships with the product, so there isn't really much difference between them.

00:30:59.048 --> 00:31:22.807
So indeed, if you want to change the rules what you feel is best for maybe you or your team or the organization you work on, you can indeed use, for example, rule sets, same as the built-in code analyzers, also supported on it, and also the pragmas and all that good stuff you have will also work for the LinterCOP.

00:31:22.807 --> 00:31:27.123
Lintercop is compatible with the other code analyzers on the same way.

00:31:28.941 --> 00:31:37.907
Only though it's nice you mentioned that because for me also, and I know for multiple people out there, by bringing on the rules it's always difficult.

00:31:37.907 --> 00:31:40.847
What should be the default severity?

00:31:40.847 --> 00:31:51.403
We call that If I added a new rule, should I then throw an error or a warning or show it as an info, or I can even hide it by default that you manually should enable it.

00:31:51.403 --> 00:31:53.685
That's always a little bit of a struggle.

00:31:53.685 --> 00:31:59.848
There are some rules where maybe personally, I think there should be at least a warning or even maybe an error.

00:32:00.660 --> 00:32:17.766
But introducing a new rule that does default as error, that could be quite harsh, especially for already running pipelines out there maybe, or people working on projects that they have a new rule and instantly throws arrows at you.

00:32:17.766 --> 00:32:20.708
So a new rule it's always a little bit of a balance.

00:32:20.708 --> 00:32:26.328
How severe is this rule and what should we set it as a default behavior to it?

00:32:26.328 --> 00:32:30.429
It's always a little bit something a struggle to find the right path on it.

00:32:30.429 --> 00:32:42.133
So we have to go into a little bit of the approach that if it will cause a runtime error, then we dare to up it to a warning as a default severity.

00:32:42.133 --> 00:32:49.633
But then of course, with rule sets you can lower it back to an info or maybe hide it and also go the other way around.

00:32:49.633 --> 00:32:57.941
You can also improve it to an error if you think, oh wow, we should really do this prove it to an error.

00:32:57.961 --> 00:32:59.002
If you think, oh wow, we should, really should do this.

00:32:59.002 --> 00:33:00.445
Um, I like everything errors, just make it all an error.

00:33:00.445 --> 00:33:10.181
It's fun and it's even better, like you said, for the mature projects to go back that have been worked on over time, to just turn it on and you see, and you can do some as warnings.

00:33:10.181 --> 00:33:16.713
You get sort of like a christmas tree type scenario where you have reds, yellows, blues from the info.

00:33:16.713 --> 00:33:18.025
So you can have a lot of fun with it.

00:33:18.740 --> 00:33:36.142
Yeah, that's what we're trying to prevent, because at least for larger projects, and eventually even if they were migrated from the old Navision days, we could easily throw a lot of warnings at you and the developer then can look at it and say, oh boy, what am what I'm going to do with all this fun.

00:33:36.142 --> 00:33:43.445
So we tend to take the best approach on that, but it's difficult, of course, to have something that everybody agrees on.

00:33:43.445 --> 00:33:49.843
So the best part is on the rule set, you can change their behavior quite easily.

00:33:49.843 --> 00:33:50.765
That's quite helpful.

00:33:51.606 --> 00:33:52.528
That's excellent.

00:33:52.528 --> 00:34:10.047
One of the things, and when I first heard of Lintocop and I started seeing the information about it because I've, like you had mentioned it's, I see a lot of conversation about it, individuals talking about it Before I first used it one of the first things that came to my mind is it's so easy to add.

00:34:10.047 --> 00:34:17.052
I was a little intimidated because it's so easy to go into your settings and enable the existing source code analyzers.

00:34:17.052 --> 00:34:19.507
And then LinterCop was a new analyzer.

00:34:19.507 --> 00:34:24.692
And how do I install it to get it to work?

00:34:24.692 --> 00:34:29.072
What is the typical process or how complicated is it to install?

00:34:30.760 --> 00:34:31.663
In the beginning days it was quite hard.

00:34:31.663 --> 00:34:34.009
In the beginning days it was quite hard.

00:34:34.009 --> 00:34:43.695
You have to copy files around in specific directories and get it to work.

00:34:43.695 --> 00:34:50.539
The great part is there is a VS Code extension available in the marketplace Also.

00:34:50.539 --> 00:34:51.543
Again, stefan Braun helped a lot on it.

00:34:51.543 --> 00:34:52.003
He built that that.

00:34:52.003 --> 00:35:03.793
You can just install the VS Code extension it's also called the same name, linterkop and it will then automatically enable for you to use Linterkop in VS Code.

00:35:03.793 --> 00:35:13.215
So it's just quite as easy just to go to the marketplace of VS Code or search in VS Code itself for Linterkop, install the extension and you're good to go.

00:35:13.215 --> 00:35:22.608
You can then enable the Linterkop and then, like you said, the Christmas tree will then probably go turn on all your projects and you have all those new rules in place.

00:35:24.742 --> 00:35:25.284
So it is.

00:35:25.284 --> 00:35:29.980
See, it's much easier and with that, to use Linterkop in your pipelines.

00:35:29.980 --> 00:35:33.431
You still would need to copy the files over, correct.

00:35:34.721 --> 00:35:46.965
There has been quite some movement in the past year, but I'm quite happy about it Because my personal view is, if you only install it if you're working in a team, that's the prerequisite.

00:35:46.965 --> 00:35:57.409
If you're working for yourself, you can install the VS Code and you can look at it, but I'm a company working in a team of developers and we want to agree on the rules.

00:35:57.409 --> 00:36:04.742
What we want to do as a whole company and then implement it in your CSED or your pipelines is, for me, an absolute must.

00:36:04.742 --> 00:36:17.954
And also there in the beginning days it was again PowerShell and writing code to grab those files and copying to left to right to get it to work.

00:36:18.940 --> 00:36:32.909
The good news is that all the solutions I know of, as you have your ALGo for GitHub, for example, but also Azure DevOps there are some other solutions for partners out there they all natively support the LintelCop.

00:36:32.909 --> 00:36:42.188
It is quite easy to set up and even in our GitHub project we specified a few of them and also added some documentation how to set it up.

00:36:42.188 --> 00:36:45.949
For example, for ALGo, freddy did an awesome job.

00:36:45.949 --> 00:36:49.409
We can just paste in a URL set one setting.

00:36:49.409 --> 00:36:52.983
You have to additionally also enable, and then you're good to go.

00:36:52.983 --> 00:36:59.411
It's not more than adding two lines in a config file and the cop is there in AL go, for example.

00:37:00.413 --> 00:37:07.612
That's amazing and I enjoy seeing more partners, or even more app developers.

00:37:07.612 --> 00:37:09.280
It has nothing to do with being a partner.

00:37:09.280 --> 00:37:24.545
Even app developers, partners and end customers or users, as they're commonly referred to, that have their own development group or team to use some source code analysis With LinterCop or even any of the other source code analysis we're talking about.

00:37:24.545 --> 00:37:32.300
That's a community-driven program, the E or application, and within AL itself they have their own rules that are enabled.

00:37:32.300 --> 00:37:40.114
Is it something that someone can add their own rule to without making it part of the application?

00:37:40.114 --> 00:37:49.268
So is there a way to have, within an organization, your own custom rules that may not exist within Linterkop or one of the existing ones?

00:37:50.960 --> 00:37:52.360
Yeah, that is quite good.

00:37:52.360 --> 00:37:53.364
Yeah, quite possible.

00:37:53.364 --> 00:37:55.135
Yeah, that is quite good.

00:37:55.135 --> 00:37:55.538
Yeah, quite possible.

00:37:55.538 --> 00:38:05.320
As LinterCorp is, like we said, the fifth code analyzer out there, you can also create your own, the sixth one, and also use that for your company.

00:38:05.320 --> 00:38:12.246
If you have specific rules that you set up aren't really generic, you could also build your own on it.

00:38:12.246 --> 00:38:15.809
And we introduced that.

00:38:17.041 --> 00:38:19.570
I was on directions last year in Vienna.

00:38:19.570 --> 00:38:37.630
We were on stage together with Stefan and there we wrapped a new feature also where we have now in GitHub with Codespaces, we created a template where you can build your own code analyzer.

00:38:37.630 --> 00:38:42.170
So we have those shipped by the product, by Microsoft.

00:38:42.170 --> 00:38:44.067
We have our community-driven LinterCop.

00:38:44.067 --> 00:39:01.266
If you say we have one to build our own code analyzer, we have now provided a template that you could quite easily start building your own code analyzer with your own rules, and you can also add that then in VS Code or to your pipelines as an additional one.

00:39:01.266 --> 00:39:05.007
And code spaces of GitHub is just awesome on that.

00:39:05.007 --> 00:39:14.023
It will help you with the template and it will set everything up with kind of like think of dependencies, but also a release pipeline to build your DLLs.

00:39:14.023 --> 00:39:19.871
All that kind of stuff we already wrapped in a template for you, so you can easily start creating your own rules.

00:39:21.240 --> 00:39:23.608
See, that is that I like.

00:39:23.608 --> 00:39:24.221
I haven't.

00:39:24.221 --> 00:39:36.860
I can honestly say I haven't really dug deep into creating my own custom rules because I haven't had a need to with using all of the analyzers with the five, because a lot of the common rules come into play.

00:39:36.860 --> 00:39:54.423
But I was thinking of other cases where I wanted to have specific rules for app settings, for values for creating applications, just to make sure that some standards or consistency within even publisher name, for example, because if you work with a team of developers, if they're creating applications, the publisher name.

00:39:54.423 --> 00:39:54.865
Some will put capital.

00:39:54.865 --> 00:39:56.873
Because if you work with a team of developers, if they're creating applications, the publisher name.

00:39:56.873 --> 00:39:58.721
Some will put capital letters, some will put no letters, some will put whatever.

00:39:59.242 --> 00:40:00.385
So is that?

00:40:00.405 --> 00:40:04.702
something that, with a custom code analyzer, we would be able to create a rule for.

00:40:06.166 --> 00:40:06.869
Yeah, absolutely.

00:40:06.869 --> 00:40:27.686
I think the great part is if you build your own analyzer you can take some shortcuts and, for example, if you want to have the same publisher, you can just hard code that value and don't have to do around settings or other kind of complexity stuff, because if it will change you can just easily change it in your own code analyzer.

00:40:27.686 --> 00:40:35.329
So those quite more easy to start on because you don't have to build it really generic.

00:40:35.329 --> 00:40:39.168
You can pinpoint it more to your use case and then build on it.

00:40:39.168 --> 00:40:47.483
And the great part is you can take a look at LindaCop, maybe a rule that you can see that already does a little bit the same.

00:40:47.483 --> 00:40:55.184
As you want to take a spiral to see how it's built and then maybe start from that rule and adapt it to your needs.

00:40:55.184 --> 00:41:02.583
That's the best advice I can give to look at already the rules we built.

00:41:02.583 --> 00:41:07.925
If you can then look something that is quite familiar, you will only have a starting point.

00:41:07.925 --> 00:41:12.385
You don't have to start with a blank canvas, figuring out everything yourself.

00:41:14.114 --> 00:41:14.576
I like that.

00:41:14.809 --> 00:41:15.972
You're going to build one now, Brad.

00:41:16.574 --> 00:41:18.938
I'm going to build a lot.

00:41:18.938 --> 00:41:20.802
Build your own cop, I will.

00:41:20.802 --> 00:41:22.594
We'll call it the Brad Cop.

00:41:22.594 --> 00:41:24.960
That's what it will be.

00:41:24.960 --> 00:41:27.336
You'll see that soon, Chris the Brad Cop.

00:41:27.336 --> 00:41:34.655
Now that I have that insight, it will be an extension of some other things that I'm already working on, and we'll call it the Brad Cop.

00:41:34.655 --> 00:41:50.003
If you look at source code analysis, what would you say would be some of the biggest benefits to a development group or anybody managing a development group that has a development group for mandating or using source code analyzers?

00:41:54.230 --> 00:42:01.916
I think the most important part for me is there are some studies out there that will show mostly in a graph.

00:42:01.936 --> 00:42:16.981
For example, if you find a bug in the system, if you catch it early on, the amount of time spent to resolve the bug is a bit lower than going through any detected in production, going through already detected in production.

00:42:16.981 --> 00:42:27.516
For example, if you have a small, if you have an issue in production, somebody has to flag it, maybe create a ticket on it, test to get maybe some analysis go to the developer has to change his code, test again.

00:42:27.516 --> 00:42:33.657
So there's lots of overhead on bugs if you catch them on later on in the process.

00:42:33.657 --> 00:42:41.329
So much earlier on will benefit you in getting more ahead of the game and make sure that you don't have.

00:42:41.329 --> 00:42:50.184
You can prevent bugs before they even get rolled out with testing for a consultant or testing for the user acceptance of the customer itself.

00:42:50.184 --> 00:42:54.021
That is, I think, a really powerful one.

00:42:54.021 --> 00:42:59.461
And the second one is that you can also agree on standards you want to do.

00:42:59.461 --> 00:43:11.775
For example, maybe if I dive into one rule that's more helpful, quite recently we had a new variable that's called secret text.

00:43:12.056 --> 00:43:13.018
So if you store.

00:43:13.460 --> 00:43:16.755
Yes, you know exactly what I mean.

00:43:16.755 --> 00:43:31.139
If you store credentials like you have an all-out client secret or a password or something I hope most of you already don't show its default in the text field, maybe using the isolated storage model already of Business Central.

00:43:32.492 --> 00:43:33.134
One moment, Chris.

00:43:33.134 --> 00:43:34.097
You hear all this.

00:43:34.097 --> 00:43:36.253
You're going to see all of this this later.

00:43:36.393 --> 00:43:45.543
I'm just letting you know okay, but it drives me crazy that I see is it's away from the car.

00:43:45.543 --> 00:43:53.829
You see, now you're going to get me down a tangent to see a field in a table in business central called username and called password.

00:43:53.829 --> 00:43:57.496
Oh, I see that so many times.

00:43:57.496 --> 00:44:06.563
And then I also see where they'll have a procedure for whatever it may be, for sending a rep request or validating the user.

00:44:06.563 --> 00:44:16.284
The parameters are username and password and they're plain text and there isn't the listen.

00:44:16.284 --> 00:44:25.867
I have seen it and some people will throw in the non-debugable attribute, which I'm not going to argue that I mean I will say at least they tried.

00:44:25.867 --> 00:44:32.956
But I always look back with now that the secret test text exists in isolated storage exists.

00:44:32.956 --> 00:44:41.045
Why anybody's storing within a database a username and password just drives me crazy.

00:44:43.132 --> 00:44:44.438
Now it's 2025.

00:44:44.438 --> 00:44:47.498
That's, from a security perspective, a no-go.

00:44:47.498 --> 00:44:48.320
That's not okay.

00:44:48.320 --> 00:44:50.416
It's back of the wild days you mentioned.

00:44:50.838 --> 00:44:55.340
Yes, and I had a conversation with somebody.

00:44:55.340 --> 00:44:59.634
You know how you can mask the field for the UI oh yeah, the UI part.

00:44:59.634 --> 00:45:01.534
Yeah, that's what they said.

00:45:01.534 --> 00:45:03.096
They said, oh well, we can mask.

00:45:03.096 --> 00:45:08.731
They don't understand the concept of if somebody's debugging that, it's just.

00:45:08.731 --> 00:45:10.880
I can't even get into that.

00:45:10.880 --> 00:45:12.235
But thank you for bringing that up.

00:45:12.235 --> 00:45:14.936
You'll send me on a spiral now.

00:45:14.936 --> 00:45:17.164
Now I need to calm down.

00:45:17.184 --> 00:45:18.570
You'll send me on a spiral now.

00:45:18.570 --> 00:45:19.958
Now I need to calm down.

00:45:19.958 --> 00:45:35.277
There is something that I think also could help on, because there are rules in there that it will detect if you do an HTTP call and you're storing authorization headers I would expect that to be a secret text, and the same for the isolated storage.

00:45:35.277 --> 00:45:43.679
It will then again show a diagnostic and then you can decide on is that for me an info, an error or a warning?

00:45:43.679 --> 00:45:46.657
And then, as a whole team, you can then decide on.

00:45:46.657 --> 00:45:49.914
We're all going to do the same approach, Do know.

00:45:50.155 --> 00:45:55.554
A really important part, what I believe is, is that you have to discuss those rules with your team.

00:45:55.554 --> 00:46:07.835
A bad idea would be on a Monday morning to see some rules in LintelCop and say, oh, this was fun and just enable them and all the team, surprise your whole team with new rules and new warnings.

00:46:07.835 --> 00:46:10.637
That's not, I think, not the best approach on it.

00:46:10.637 --> 00:46:25.081
The best approach would be to the rules, to have a discussion with your team to see do we see the benefit on it or not, because I think it's best if everybody's on board and also does this commitment.

00:46:25.081 --> 00:46:27.514
As he says, I see the benefit of the rule, I know.

00:46:27.514 --> 00:46:29.942
It's why I know it's why the rule is there.

00:46:29.942 --> 00:46:35.996
I know what to prevent and also do the commitment that and that's what we did in our company.

00:46:36.197 --> 00:46:40.523
If we adapt a new rule it will be for all of our projects.

00:46:40.523 --> 00:46:54.496
So larger extensions, where they've been there, have to be changed and update those changes to resolve those warnings of the Linterkop, as in our pipelines we are quite harsh.

00:46:54.496 --> 00:46:57.135
We treat every warning as an error.

00:46:57.135 --> 00:47:07.893
So if you have a warning in our pipeline it will stop building and you have to first fix all the warnings before we can proceed.

00:47:07.893 --> 00:47:11.918
And that's sometimes quite oppressive with some rules.

00:47:11.918 --> 00:47:28.577
If you have all the extensions and, like I said, mostly if they already may migrate from the division area, it's quite there can be a lot of rules then showing up on older code.

00:47:28.577 --> 00:47:33.577
So that's, I think, a really important part also to look at the rules and analyze them and see are they beneficial for us and do we commit to them.

00:47:33.577 --> 00:47:36.472
That's a really important part, not only for the LinterCOP, for all of them.

00:47:36.472 --> 00:47:40.373
Other code cops analyze important part not only for the LinterCOP, for all of them, other CodeCops, analyzers also, I believe.

00:47:42.478 --> 00:47:50.577
So this all covers the importance of having those source code analyzers, as you had mentioned, and the benefits of it.

00:47:50.577 --> 00:48:02.137
It's not only the standardization, as we talked about, but you can save a lot of time from debugging issues or some from production issues, excuse me, by catching some issues ahead of time.

00:48:02.137 --> 00:48:21.018
And also, if we talk about the secret text, even in the case of security issues, in some instances that may be easily caught, that are often overlooked by many developers that either, as you had mentioned, will migrate code or they'll create new code by taking a look at another example.

00:48:21.018 --> 00:48:32.860
That's one of the things that we talk about is, oh, when we look at a previous example and that previous example may be not proper in some respect, and to be able to catch it with a code analyzer is important.

00:48:34.449 --> 00:48:40.606
Absolutely, and those examples could also be the base app See mostly beginning AL developers.

00:48:40.606 --> 00:48:42.679
They will also be the base app See mostly beginning AL developers.

00:48:42.679 --> 00:48:54.041
They will look at the base app and see inspire on how it's programmed there and the difficult part of that is it's probably for quite old code, not the best to do as of today.

00:48:54.041 --> 00:48:56.655
So LittleCop will then help you.

00:48:56.655 --> 00:49:01.918
If you have a piece of code, it will then help you advise to restructure some parts.

00:49:01.918 --> 00:49:08.597
So it's also not your own code, but also the BaseApp is also sometimes not the best example to start off.

00:49:09.099 --> 00:49:11.695
So you mean, are you telling me that the BaseApp would be a Christmas tree?

00:49:13.360 --> 00:49:23.077
Yeah, I've recently did the BaseApp to do some performance tuning and there were quite a lot of warnings.

00:49:23.077 --> 00:49:31.420
I think it also take, I think, almost a minute to also output all of those infos, warnings, diagnostics.

00:49:31.420 --> 00:49:33.697
There are quite a lot of them in there.

00:49:33.697 --> 00:49:49.400
But yeah, understandable of course that that is built years ago, so everything now taking a part in it and in an extension model, I see there it's quite a good practice on that.

00:49:49.400 --> 00:49:56.737
But the base app itself, of course, that's again a Christmas tree lighting up, if you, for example, enabled.

00:49:56.777 --> 00:49:57.378
Lentikop on that.

00:49:57.378 --> 00:50:01.117
No, it's good, I understand it too, but it's one of those.

00:50:01.117 --> 00:50:03.898
It's interesting.

00:50:03.898 --> 00:50:08.219
I tried it once before too, and it's just interesting to see what you have.

00:50:08.219 --> 00:50:11.840
Listen, I will always say nobody, nothing is perfect.

00:50:11.840 --> 00:50:19.521
Everybody has a reason why they're doing a certain thing, whether it's by creating something from before and you need to have it for compatibility or the such.

00:50:19.521 --> 00:50:24.315
But I just like to say the word Christmas tree, absolutely, which is nice.

00:50:25.297 --> 00:50:31.340
Well, mr Arthur, sir, we appreciate you taking the time to speak with us, to talk with us about source code analyzers.

00:50:31.340 --> 00:50:36.735
I personally feel they're extremely important in development and thank you for sharing your insights.

00:50:36.735 --> 00:50:50.721
A little bit more about source code analysis source code analysis as well as LinterCop, and I hope those that aren't aware of LinterCop or haven't used LinterCop give it a shot and try, because it does expand and add to the existing Microsoft source code analyzers.

00:50:50.721 --> 00:51:01.063
And, as you had mentioned, now that there's a template where you can create your own custom analyzers, you can have a little a little more control over the rules for an individual application or organization, which is important.

00:51:02.144 --> 00:51:29.356
Absolutely and, as I mentioned, if you're struggling a little bit or do you say creating my own rules is a little bit steep leaning curve, you could also start with on our GitHub to start with a discussion If you have an idea for a new rule so we can maybe discuss a little bit on it, and if I can assist in something, feel free to reach out, because I really love that.

00:51:29.356 --> 00:51:30.320
It's a community project.

00:51:30.320 --> 00:51:36.059
I'm not the only one on it, absolutely not, and it's helpful if we all chip in.

00:51:36.059 --> 00:51:45.324
Not, and that's helpful if we all chip in and it will help all of us in our community um to to improve the, for example, the linter cop on it.00:51:45.324 --> 00:51:55.054


So if you're thinking building your own rules is a little bit, uh, still a steep learning curve to start on that, you could also start, for example, with discussions or helping on the cop itself on there.00:51:55.054 --> 00:51:55.414


Oh that.00:51:56.436 --> 00:51:56.896


Oh, that's great.00:51:56.896 --> 00:51:57.257


That's great.00:51:57.257 --> 00:52:06.358


So we can reach out to go to search for Linterkop, and we'll put a link in the notes for Linterkop how to access Linterkop on GitHub.00:52:06.358 --> 00:52:17.135


If anyone has additional questions or would like to see some of the other great things that you've been doing and you do some great things with Linterkop, and we appreciate all that you're doing for the community as well what's the best way to get in contact with you?00:52:18.599 --> 00:52:21.925


You can always look me up on LinkedIn or connect with me on LinkedIn.00:52:21.925 --> 00:52:27.242


I try to send the updates I do on LinkedIn and also on Blue Skies.00:52:27.242 --> 00:52:33.519


You can also find me there to also post some fun things or some updates also on there.00:52:34.722 --> 00:52:35.503


Excellent, excellent.00:52:35.503 --> 00:52:37.889


Thank you, we appreciate your time and I look forward to seeing you again soon.00:52:37.889 --> 00:52:38.110


Ciao, ciao.00:52:38.110 --> 00:52:39.070


Thank you, we appreciate your time and I look forward to seeing you again soon.00:52:39.070 --> 00:52:41.134


Ciao ciao.00:52:41.153 --> 00:52:42.556


Thank you, bye-bye.00:52:43.358 --> 00:52:50.382


Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.00:52:50.769 --> 00:52:52.275


Thank you, brad, for your time.00:52:52.275 --> 00:52:55.786


It is a wonderful episode of Dynamics Corner Chair.00:52:55.786 --> 00:52:59.239


I would also like to thank our guests for joining us.00:52:59.239 --> 00:53:02.259


Thank you for all of our listeners tuning in as well.00:53:02.259 --> 00:53:14.992


You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E.00:53:14.992 --> 00:53:16.873


Via Twitter, d-v-l-p-r-l-i-f-e.00:53:16.873 --> 00:53:30.204


You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16.00:53:30.204 --> 00:53:33.847


And you can see those links down below in the show notes.00:53:33.847 --> 00:53:35.208


Again, thank you everyone.00:53:35.208 --> 00:53:38.494


Thank you and take care.

Arthur van de Vondervoort Profile Photo

Arthur van de Vondervoort

Solution Architect

My journey started with ERP software implementation in 2010. Since then, I have grown into a Solution Architect specializing in Microsoft Dynamics 365 Business Central.

During the transition from NAV to Business Central, I expanded my expertise to include areas such as DevOps and the Power Platform.

I am particularly passionate about automating business processes and continuously strive to innovate and improve in this field.