Dynamics Corner
About Dynamics Corner Podcast "Unraveling the World of Microsoft Dynamics 365 and Beyond" Welcome to the Dynamics Corner Podcast, where we explore the fascinating world of Microsoft Dynamics 365 Business Central and related technologies. Co-hosted by industry veterans Kris Ruyeras and Brad Prendergast, this engaging podcast keeps you updated on the latest trends, innovations, and best practices in the Microsoft Dynamics 365 ecosystem. We dive deep into various topics in each episode, including Microsoft Dynamics 365 Business Central, Power Platform, Azure, and more. Our conversations aim to provide valuable insights, practical tips, and expert advice to help users of businesses of all sizes unlock their full potential through the power of technology. The podcast features in-depth discussions, interviews with thought leaders, real-world case studies, and helpful tips and tricks, providing a unique blend of perspectives and experiences. Join us on this exciting journey as we uncover the secrets to digital transformation, operational efficiency, and seamless system integration with Microsoft Dynamics 365 and beyond. Whether you're a business owner, IT professional, consultant, or just curious about the Microsoft Dynamics 365 world, the Dynamics Corner Podcast is the perfect platform to stay informed and inspired.
Dynamics Corner
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.
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
Welcome everyone to another episode of Dynamics Corner. Can cop analyze things? I'm your co-host, chris.
Speaker 2:And this is Brad. This episode is recorded on March 6, 2025. Chris, chris, chris. Another day, another great episode, another great discussion about rules and code analyzers. Source code cops. Do we have custom cops and beer With us today? We had the opportunity to speak with Arthur.
Speaker 1:Good morning Good afternoon.
Speaker 3:Good afternoon Hi.
Speaker 2:How are you doing?
Speaker 3:I'm doing great, excellent. I'll be here in Belgium. It's Thursday afternoon, hi, how are you doing? I'm doing great, excellent. I'll be here in Belgium Thursday afternoon, so looking forward for heading into the weekend almost.
Speaker 2:Excellent.
Speaker 3:Excellent.
Speaker 2: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. 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. So I feel like just a little bit.
Speaker 1:But you go back to work before me, so I get to savor my weekend at least.
Speaker 2:Oh, I go back to work way before you. Yeah, for many reasons, for many reasons. So, uh, I've never been to belgium. I would like to go to belgium oh, you should absolutely do that.
Speaker 3:it's a fantastic year. Um, I'm originally from the Netherlands and then I moved over here to Belgium. I think it's a great country. It has some complexity on structures and everything, but I like the mentality and hospitality that's here in Belgium. So every year we have also BC Tech Days, of course, so you're more than welcome.
Speaker 2:Yes, yes.
Speaker 3:But no, I really like it here. 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.
Speaker 2: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. It's just a challenge. I'm certain if you've ever come to the United States it's not so close. 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. I'm hopeful that you know SpaceX or something will be able to just make a rocket to fly us over the pond.
Speaker 1:They're trying to bring back that. Supersonic flights Was the Concorde. Yeah, yeah, they're trying to bring about concord. That'd be amazing to be able to get on that. Just get to europe quickly and uh. Then, yeah, I'll definitely fly, I'll definitely go there much easy.
Speaker 1:Uh, he has something to do with some safety stuff, I think, and many other factors, and that's why they stopped the noise. The environmental factor, I think, was one of the reasons why they stopped. 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. That would be amazing.
Speaker 2:That would be great. I did have a lot I'd like to speak with you about, but speaking about Belgium, is that where the Belgian waffle started?
Speaker 3:That's a good question. I'm not sure, to be honest. That's a very good question. I do think it's really a thing you have to try if you're here in Belgium. If I did some holidays here in Europe and stuff, nothing beats a Belgian waffle In other parts of Europe. It's still different. There are a few things here in Belgium that I just have to taste here to get a great experience on it. 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. So that's a funny thing from here. But we have more delicious things. Of course. We can talk hours of all kinds of beer.
Speaker 2:Oh, Belgian beer.
Speaker 3:It's a luxury beer. 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. Then I really experienced what beers could do and what tastes and flavors there are. 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.
Speaker 2:I wish we had something like that here. I don't know what people think of. When you think of the United States, what do you think of for food? Because I hear Italy, I think of pizza and wine. I hear France, I think of pastries. I hear Belgium, I think of waffles and beer. I think of Ireland, I think of whiskey.
Speaker 1:And I'm not saying, this is the.
Speaker 2:Yes, and Guinness whiskey, right, and I'm not saying this is the. I'm not saying yes, and Guinness beer, but I primarily think of whiskey and Guinness. 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. 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. But what do you think of food-wise when you hear the United States?
Speaker 3:It's funny that you say so. We share that little bit in common. I only have on this side of the ocean. I've never been across the other side, to be honest, so only from a European guy perspective. 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.
Speaker 3:Uh, that has to be a bad thing. 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. But that's something that pops in my head. I can't explain why.
Speaker 2:That's good. 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. So I've been curious to know what others from Europe, such as yourself, think of for food countries. So I've been curious to know what others from Europe, such as yourself, think of for food when they hear the United States.
Speaker 1:A quick question when you talk about beer, are beers typically served room temperature in Belgium, Not like ice cold beer?
Speaker 3:Not room temperature. That's not going to be okay. 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. Maybe there are some that are better if they're going to room temperature, but it's not common to do that. I don't think I can have a warm beer.
Speaker 1:How about sour beer? Do you guys have sour beer in Belgium?
Speaker 3:What do you mean by sour beer?
Speaker 1:Can you?
Speaker 3:help me a little bit on that.
Speaker 1: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. 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.
Speaker 2:Key lime pie is really good. I don't know if I'd have a key lime pie flavored beer and sour beer and hops. I'm. I've gotten to the point now, chris. Everything you say I'm grokking. So you, you gave me oh you were correct, washington's is.
Speaker 2:According to grok, again, washington is the state in the us that produces the most hops. In 2023, it accounted for approximately 76.6 million pounds of hops. 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. I'm redoing my setup after this to have Grog on speed typing. I'll move my setup around so I can type all this stuff up. I enjoy the beer conversation. I enjoy the food conversation even more, but that's not the reason why we're all here today. But before we jump into the conversation, would you mind telling everybody a little bit about yourself, please?
Speaker 3:Yeah, absolutely, my name is Arthur van de Vondelvoort. 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.
Speaker 2: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. 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. There are a few, but you're one of the source code analyzer guys to go to if you have any questions. So, if you would, can you tell us a little bit about source code analysis and what it is?
Speaker 3:Yeah, absolutely. The source code analysis is from the product. Microsoft also includes three of them. You have the UI cop, the code cop and then an extension cop and also for AppSource one. So four of them in total and what they will help you is well doing development. 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. That's really doing that without even running the code. 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. So more like maybe, an assistant role. You can look at it a little bit like that.
Speaker 2:So source code analysis. Would you classify it? You had mentioned that within VS Code we have four analyzers. Would you mention it to be more of a syntactical, cosmetic-type analysis, or a functional-type analysis, or both?
Speaker 3:I believe my opinion is that it will do both type analysis or a functional type analysis, or both. I believe my opinion is that it will do both. It will mostly, indeed, run on the syntax. That is the most easy part to analyze. 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. So it'll try to figure out as much as possible. So it's not only the syntax but it's more of an whole package that it can cover to analyze on.
Speaker 2:I'm a big fan of source code analysis, just for many reasons, but I often wonder how does it work, right? So it's how does it work and how does it really analyze the code? 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? Because, just like with many things, the concept is great, I understand it, but the practical application of it is challenging.
Speaker 3:Okay, I think we have to get a little bit back in time. If we go back to the Nevision timeframe, we had the good old seaside development. We had our own development environment within the application itself and you can write the code in there, and that was okay-ish.
Speaker 2:Well, okay-ish, we called it the Wild Wild West. Back in the early days. It was the Wild Wild West, I think. Now, eventually, when they gave you the breaks for the functions, you know where they had the bar. 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. So I really need to get my hands on version 1.2. I don't know if you could get a license for it, but I started with version 1.1. I would love to go back in time and install that and take a look at it or even all of the subsequent versions.
Speaker 2:But I don't mean to interrupt. Go back to the OK-ish.
Speaker 3: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. 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. That was the era we were used to, maybe as an Envision developer and I also had those days. I started really on development in NAV 2017 something-ish. 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. 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. So we received VS Code where we can develop them we have.
Speaker 3: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. If you look, for example, if you are a C-sharp developer, it's quite normal to have your VS Code or Visual Studio. You have Git all the stuff that was new for us back in those days. 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. Microsoft has provided a platform on that. It's under the hood, it's called the Roslyn Analyzer. That's a framework that can analyze your code for you in development. 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.
Speaker 2: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.
Speaker 3:Correct. The AL language is depending on Roslyn, as I think it's a framework. 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. More languages can use the Roslyn analyzer, so that's a great benefit of that. 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.
Speaker 2:Okay, and with the source code analysis, just to go back. So Microsoft has four. You have the UI, which I think will help with some UI structure. 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. You have two other ones you had mentioned.
Speaker 3:You have the general CodeCop analysis. That will be more of a generic approach. We'll look at if there are some syntaxes that maybe aren't right. That's not specific targeting, that's more looking at the syntax of the code itself. And you mentioned the UICop. For example, tooltips are there, maybe an option? Are there or set visibility of fields? And then you also have, of course, depending on if you go to AppSource or a per-tenant extension. Both of them have their own AppSource cop and for a per-tenant extension it will, for example, look at the object numbers. That has to be in the 50,000 to 100,000 range, for example. That kind of stuff will help one of those code analyzers help you with to make those mistakes during your development.
Speaker 2:Excellent, excellent. You with to make those mistakes during your development, Excellent, Excellent. You know I always end up putting the per-tenant extension and the app source extension excuse me analyzer. It's been one of those mornings. I'm lost. I often put the per-tenant extension analyzer and the app source extension analyzer together in a project. I always just use all of them and I always have to put in a suppression of warnings for the ID. It's interesting enough.
Speaker 3:That's funny. You mentioned that there are more colleagues also there, I know of them. They also said I'm not going to use one or the other. I'm going to use both of them because both of them have. They also said I'm not going to use one or the other. 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.
Speaker 3:For example, we still need to have prefixes or suffixes on our objects. The namespacing is getting less and less depending, but as of today we still need them. A rule for that is in the AppSource pop code analyzer, not in a patented extension. 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. So you can also have all four of them active. But then you have to suppress some specific rules that don't apply for the target you're targeting on your extension.
Speaker 2:I'm happy to hear that I'm not alone in that. That makes me feel good, absolutely so. 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. So it's a fifth code analyzer, correct, and can you tell us a little bit about Linterkop?
Speaker 3:Absolutely. Linterkop is a community-driven code analyzer. 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. He called it Lintocop as an open source code analyzer. So that's free available on GitHub so you can use it and see how it's built and worked. And he started that Lintocop back in 2021. And I've got it on my radar. I think like a half year later, something is beginning on 2022.
Speaker 3:And I was quite enthusiastic about it. There are some great rules already in there in the beginning that I said. It's quite obvious to have them and to help you during your development. What's always in my head is why I do really like the LinterCop as a product and also the other ones, of course. It will help you resolve problems by taking away its root cause. What am I going to say with that?
Speaker 3: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? What's going wrong? And I can explain what was going wrong and why and all the stuff around it, and he challenged me always with. But what was the root cause? Can we take away the root cause that the problem will never reoccur again? 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?
Speaker 3:And Linterkop has a quite simple rule that I think is fantastic. 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. 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. And to prevent that, lintercop will during development.
Speaker 3: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. 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. Everything you test works. You ship it off to maybe your consultant or the customer and then you can get that feedback back from. I see a problem. 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. 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.
Speaker 2:That's good. 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. 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. If you edited a flow field that was a sum of data it would actually change the data in a sense underlying of it. But way back, I haven't tried it now because I've been so used to making flow fields non-editable. It's just out of habit. 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. So that's a little go back in time way back oh wow, I didn't.
Speaker 3:I didn't know it would change your data, that's that's mind-blowing.
Speaker 2: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. I could be talking, you know, sideways, but that's what I remember. It's um that's dangerous yes, that's why.
Speaker 2:That's why he said the number one rule is to make a flow field non-editable. 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. I like that. That's a great analogy to what it was like editing or developing in Notepad.
Speaker 2:But, this was over 20 years ago too, so a lot of improvements have been made. So Lintocop works in addition to the Microsoft code analyzers that come as part of the application. 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. It's nice to have some sort of standard.
Speaker 3: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. There are, I think, currently more than 90 rules on it. 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. 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. It's going multiple directions, so it's not focusing on one thing. It's getting more, broader and broader to indeed try to solve as much ground as possible to help improving.
Speaker 2:See, I like that. It does more than just formatting standards you had mentioned. It can also help catch some performance considerations as well, too, within the code.
Speaker 3:Yeah, absolutely so. 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. Then it grew with help of the community and that for performance. It has a few nice rules. But for example, like is we're all known to the log table command we can use In some scenarios. It's necessary to use that for processing data in some scenarios. 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. That's a better approach on it.
Speaker 3:And also some other fun stuff. 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. Is it really the result zero? 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. 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.
Speaker 2:So LinterCop you had mentioned has 90 rules to date and this year you're expecting that it would go over 100 rules. 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? Yes, suppression in the app file.
Speaker 3:Yeah, the great part is that LinterCop behaves exactly the same as the other code analyzers. That ships with the product, so there isn't really much difference between them. 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. Lintercop is compatible with the other code analyzers on the same way.
Speaker 3: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. What should be the default severity? 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. That's always a little bit of a struggle. There are some rules where maybe personally, I think there should be at least a warning or even maybe an error.
Speaker 3: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. So a new rule it's always a little bit of a balance. How severe is this rule and what should we set it as a default behavior to it? It's always a little bit something a struggle to find the right path on it. 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. 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. You can also improve it to an error if you think, oh wow, we should really do this prove it to an error.
Speaker 2:If you think, oh wow, we should, really should do this. Um, I like everything errors, just make it all an error. 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. You get sort of like a christmas tree type scenario where you have reds, yellows, blues from the info. So you can have a lot of fun with it.
Speaker 3: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. So we tend to take the best approach on that, but it's difficult, of course, to have something that everybody agrees on. So the best part is on the rule set, you can change their behavior quite easily. That's quite helpful.
Speaker 2:That's excellent. 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. I was a little intimidated because it's so easy to go into your settings and enable the existing source code analyzers. And then LinterCop was a new analyzer. And how do I install it to get it to work? What is the typical process or how complicated is it to install?
Speaker 3:In the beginning days it was quite hard. In the beginning days it was quite hard. You have to copy files around in specific directories and get it to work. The great part is there is a VS Code extension available in the marketplace Also. Again, stefan Braun helped a lot on it. He built that that. 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. 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. 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.
Speaker 2:So it is. See, it's much easier and with that, to use Linterkop in your pipelines. You still would need to copy the files over, correct.
Speaker 3: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. 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. 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. 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.
Speaker 3: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. 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. For example, for ALGo, freddy did an awesome job. We can just paste in a URL set one setting. You have to additionally also enable, and then you're good to go. It's not more than adding two lines in a config file and the cop is there in AL go, for example.
Speaker 2:That's amazing and I enjoy seeing more partners, or even more app developers. It has nothing to do with being a partner. 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. That's a community-driven program, the E or application, and within AL itself they have their own rules that are enabled. Is it something that someone can add their own rule to without making it part of the application? 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?
Speaker 3:Yeah, that is quite good. Yeah, quite possible. Yeah, that is quite good. Yeah, quite possible. 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. If you have specific rules that you set up aren't really generic, you could also build your own on it. And we introduced that.
Speaker 3:I was on directions last year in Vienna. 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. So we have those shipped by the product, by Microsoft. We have our community-driven LinterCop. 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. And code spaces of GitHub is just awesome on that. 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. All that kind of stuff we already wrapped in a template for you, so you can easily start creating your own rules.
Speaker 2:See, that is that I like. I haven't. 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. 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. Some will put capital. Because if you work with a team of developers, if they're creating applications, the publisher name. Some will put capital letters, some will put no letters, some will put whatever.
Speaker 1:So is that?
Speaker 2:something that, with a custom code analyzer, we would be able to create a rule for.
Speaker 3:Yeah, absolutely. 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. So those quite more easy to start on because you don't have to build it really generic. You can pinpoint it more to your use case and then build on it. 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. 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. That's the best advice I can give to look at already the rules we built. If you can then look something that is quite familiar, you will only have a starting point. You don't have to start with a blank canvas, figuring out everything yourself.
Speaker 2:I like that.
Speaker 1:You're going to build one now, Brad.
Speaker 2:I'm going to build a lot. Build your own cop, I will. We'll call it the Brad Cop. That's what it will be. You'll see that soon, Chris the Brad Cop. 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. 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?
Speaker 3:I think the most important part for me is there are some studies out there that will show mostly in a graph.
Speaker 3: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. 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. So there's lots of overhead on bugs if you catch them on later on in the process. So much earlier on will benefit you in getting more ahead of the game and make sure that you don't have. 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. That is, I think, a really powerful one. And the second one is that you can also agree on standards you want to do. 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.
Speaker 1:So if you store.
Speaker 3:Yes, you know exactly what I mean. 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.
Speaker 2:One moment, Chris. You hear all this. You're going to see all of this this later.
Speaker 2:I'm just letting you know okay, but it drives me crazy that I see is it's away from the car. 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. Oh, I see that so many times. 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. The parameters are username and password and they're plain text and there isn't the listen. 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. But I always look back with now that the secret test text exists in isolated storage exists. Why anybody's storing within a database a username and password just drives me crazy.
Speaker 3:Now it's 2025. That's, from a security perspective, a no-go. That's not okay. It's back of the wild days you mentioned.
Speaker 2:Yes, and I had a conversation with somebody. You know how you can mask the field for the UI oh yeah, the UI part. Yeah, that's what they said. They said, oh well, we can mask. They don't understand the concept of if somebody's debugging that, it's just. I can't even get into that. But thank you for bringing that up. You'll send me on a spiral now. Now I need to calm down.
Speaker 3:You'll send me on a spiral now. Now I need to calm down. 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. It will then again show a diagnostic and then you can decide on is that for me an info, an error or a warning? And then, as a whole team, you can then decide on. We're all going to do the same approach, Do know.
Speaker 3:A really important part, what I believe is, is that you have to discuss those rules with your team. 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. That's not, I think, not the best approach on it. 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. As he says, I see the benefit of the rule, I know. It's why I know it's why the rule is there. I know what to prevent and also do the commitment that and that's what we did in our company.
Speaker 3:If we adapt a new rule it will be for all of our projects. 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. We treat every warning as an error. 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. And that's sometimes quite oppressive with some rules. 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. 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. That's a really important part, not only for the LinterCOP, for all of them. Other code cops analyze important part not only for the LinterCOP, for all of them, other CodeCops, analyzers also, I believe.
Speaker 2:So this all covers the importance of having those source code analyzers, as you had mentioned, and the benefits of it. 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. 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. 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.
Speaker 3:Absolutely, and those examples could also be the base app See mostly beginning AL developers. They will also be the base app See mostly beginning AL developers. 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. So LittleCop will then help you. If you have a piece of code, it will then help you advise to restructure some parts. So it's also not your own code, but also the BaseApp is also sometimes not the best example to start off.
Speaker 2:So you mean, are you telling me that the BaseApp would be a Christmas tree?
Speaker 3:Yeah, I've recently did the BaseApp to do some performance tuning and there were quite a lot of warnings. I think it also take, I think, almost a minute to also output all of those infos, warnings, diagnostics. There are quite a lot of them in there. 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. But the base app itself, of course, that's again a Christmas tree lighting up, if you, for example, enabled.
Speaker 2:Lentikop on that. No, it's good, I understand it too, but it's one of those. It's interesting. I tried it once before too, and it's just interesting to see what you have. Listen, I will always say nobody, nothing is perfect. 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. But I just like to say the word Christmas tree, absolutely, which is nice.
Speaker 2:Well, mr Arthur, sir, we appreciate you taking the time to speak with us, to talk with us about source code analyzers. I personally feel they're extremely important in development and thank you for sharing your insights. 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. 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.
Speaker 3: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. It's a community project. I'm not the only one on it, absolutely not, and it's helpful if we all chip in. 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. 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. Oh that.
Speaker 2:Oh, that's great. That's great. 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. 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?
Speaker 3:You can always look me up on LinkedIn or connect with me on LinkedIn. I try to send the updates I do on LinkedIn and also on Blue Skies. You can also find me there to also post some fun things or some updates also on there.
Speaker 2:Excellent, excellent. Thank you, we appreciate your time and I look forward to seeing you again soon. Ciao, ciao. Thank you, we appreciate your time and I look forward to seeing you again soon. Ciao ciao.
Speaker 1:Thank you, bye-bye.
Speaker 2:Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.
Speaker 1:Thank you, brad, for your time. It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. 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. Via Twitter, d-v-l-p-r-l-i-f-e. You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.
