Episode 335: In the Dynamics Corner Chair: Understanding Clean Code and The Importance of Code Reviews

WEBVTT

00:00:00.300 --> 00:00:06.250
Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics.

00:00:06.250 --> 00:00:16.753
Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365, this is your place to gain insights, learn new tricks and reviewing the reviews of code.

00:00:16.753 --> 00:00:18.385
I'm your co-host, chris.

00:00:19.580 --> 00:00:20.263
And this is Brad.

00:00:20.263 --> 00:00:23.873
This episode is recorded on August 1st 2024.

00:00:23.873 --> 00:00:25.463
Chris, chris, chris.

00:00:25.463 --> 00:00:27.289
Reviewing of code.

00:00:27.289 --> 00:00:29.724
What is the reviewing of code?

00:00:29.724 --> 00:00:32.268
Do you know what the reviewing of code is?

00:00:32.268 --> 00:00:42.244
Well, today we had the opportunity to speak with two amazing guests to talk all about code reviews, clean code and several other points With us.

00:00:42.244 --> 00:00:45.412
Today we spoke with Natalie Karalik and Stephen Martin.

00:00:45.412 --> 00:01:01.680
Good afternoon.

00:01:01.801 --> 00:01:02.161
Hello, I'm fine.

00:01:02.161 --> 00:01:04.602
How are you Doing very well?

00:01:04.602 --> 00:01:06.885
Thank you, good afternoon Hello.

00:01:06.944 --> 00:01:07.885
I'm fine, how are you Doing?

00:01:07.885 --> 00:01:08.385
Very well, thank you.

00:01:08.406 --> 00:01:11.608
Good morning, good morning, good afternoon Stefan and Natalie.

00:01:11.608 --> 00:01:12.909
Great to see you.

00:01:12.909 --> 00:01:14.811
I've been looking forward to talking with you both.

00:01:14.811 --> 00:01:17.653
I have a lot of things I'd like to talk with you about.

00:01:17.653 --> 00:01:30.468
You know, I hear a lot about source control management, hear a lot about test automation, hear a lot about pipeline CICD, but one thing that comes in with the source code source control management.

00:01:30.468 --> 00:01:31.852
I hear people use different terms.

00:01:31.852 --> 00:01:37.091
Maybe we can get into that a little bit as well, but one of the things is code reviews.

00:01:37.091 --> 00:01:49.054
You know, everyone talks about let's do code reviews, let's talk about pull requests, let's talk about a number of different things, and I thought who else could we talk to about code reviews and clean code than the two of you?

00:01:49.054 --> 00:01:57.230
So, before we jump into that conversation, though, would you mind telling everyone who's listening a little bit about yourselves?

00:01:57.230 --> 00:01:58.712
We can start with Natalie.

00:02:00.614 --> 00:02:01.736
Yeah, hello everybody.

00:02:01.736 --> 00:02:03.602
So my name is Nathalie Karolak.

00:02:03.602 --> 00:02:14.010
I'm located in Germany, working for Cosmo Consult as a programmer for solutions published to the AppSource, so this is my main focus.

00:02:14.010 --> 00:02:18.033
I'm doing this since quite a long time already.

00:02:18.033 --> 00:02:25.225
I'm in the business since 2006 and I'm also a Microsoft MVP for business solutions, and I'm also a Microsoft MVP for.

00:02:25.246 --> 00:02:25.750
Business Solutions.

00:02:25.750 --> 00:02:27.019
That's right, congratulations.

00:02:27.019 --> 00:02:32.650
Fantastic Congrats you had received that recently, and also this is your second time speaking with us.

00:02:32.650 --> 00:02:43.930
We were fortunate and lucky enough to have you speak with us early on while we're still trying to figure all this out, so we appreciate your support and speaking with us then and also returning to speak with us again.

00:02:43.930 --> 00:02:46.242
Stefan sir, how are you doing?

00:02:47.967 --> 00:02:48.968
Yeah, thanks, I'm doing good.

00:02:48.968 --> 00:03:15.031
Hello everyone, I'm Stefan and I've been working with NAV since I started with NAV actually, so many folks as of today are not familiar with NAV anymore, so I want to point that out With NAV 2016, so not quite as long as Natalie, and I am originally from Germany.

00:03:15.031 --> 00:03:37.228
I'm now located in Poland for almost a year now and I'm working as a freelance developer, so mostly doing coding stuff, but then again all the as Brad already mentioned all the stuff that comes with us going through pipelines and code reviews and clean coding and stuff excellent, great.

00:03:37.247 --> 00:03:39.901
And you also have the BC coding stream which I like to watch.

00:03:39.901 --> 00:03:42.687
Unfortunately, I see that you had moved it over to YouTube.

00:03:42.687 --> 00:03:46.186
I have to try to figure out the timing on that, but that's.

00:03:46.186 --> 00:03:47.829
I appreciate seeing that.

00:03:47.829 --> 00:03:48.912
It's weird.

00:03:48.912 --> 00:03:52.991
Sometimes I just put it on and play it and just watch when I'm working or do whatever.

00:03:52.991 --> 00:03:55.087
So it's nice to have stuff like that.

00:03:55.087 --> 00:03:57.769
I kind of feel like I'm in the office with you or something.

00:03:59.501 --> 00:04:00.383
Well, that's the intention.

00:04:01.228 --> 00:04:03.526
Yes, well, the intention worked.

00:04:03.526 --> 00:04:10.268
I'm sure many others listen to it or watch it, and if they don't, um, I suggest they do so.

00:04:10.268 --> 00:04:31.086
When it comes to code reviews, um, and I deal with it, I get asked this often, even within you know, when I'm working, because we're talking, okay, well, we're going to write code, we're going to do a pull request, now someone's going to do a code review, and what is a code review, and what should someone do during a code review?

00:04:31.086 --> 00:04:34.225
Because that's what I get asked and there's some basic stuff I can say.

00:04:34.225 --> 00:04:36.846
Well, you know, I look at some of the simple things.

00:04:36.846 --> 00:04:38.725
So, what is a code review?

00:04:38.725 --> 00:04:42.312
What should a code reviewer do?

00:04:42.312 --> 00:04:51.620
What should a code reviewer do?

00:04:51.620 --> 00:04:52.523
What should a code reviewer look for?

00:04:52.543 --> 00:04:55.629
These are all the questions I have, so we'll hopefully get to them in the conversation.

00:04:55.629 --> 00:04:57.333
So what are your thoughts with that?

00:04:57.333 --> 00:05:02.682
Natalie, I know you work with code reviewers quite a bit, yeah, so if I should start, maybe I start with what it is not supposed to be.

00:05:02.682 --> 00:05:10.047
I simply get a formula called a pull request where I simply hit the approve button and that's it.

00:05:11.180 --> 00:05:22.189
My task as a reviewer is to look at the code, to check what is possible, at least within a short time, at least looking at it directly in the pull request itself.

00:05:22.189 --> 00:05:24.271
I could also download the old branch and check it all in the pull request itself.

00:05:24.271 --> 00:05:29.132
I could also download the old branch and check it all in my development environment, but this is something that I, for example, do not do.

00:05:29.132 --> 00:05:34.541
However, I want to check formal stuff.

00:05:34.541 --> 00:05:45.211
I want to see that code applies to certain conventions, to style guides, to style guides in order to help us to read the code easily.

00:05:45.951 --> 00:06:16.187
And the other task I have but it's not always possible is to also validate actually code, to look out for maybe errors or even just spelling mistakes, whatever it can be so simple things, but sometimes you're lucky and if you have a good reviewer, he or she can also point you to real logical bugs that even a test did not discover earlier.

00:06:16.187 --> 00:06:23.334
That's the ideal part, but at least you have the formal stuff, because this is the easiest thing to do and usually doesn't cost too much time.

00:06:23.334 --> 00:06:35.572
Yeah, but also it's always a question of how much you go into detail, but maybe this is something that Stefan first can talk about as well.

00:06:37.242 --> 00:06:37.644
Stefan Hoferlund.

00:06:37.644 --> 00:06:41.988
Yeah well, code reviews it's such a huge topic we could probably talk for hours straight about this.

00:06:41.988 --> 00:06:52.016
It really depends how you yeah what kind of change you're reviewing, I think, especially with how much you go into detail.

00:06:52.016 --> 00:07:08.827
If I'm just looking at a small change, which also should receive reviews, I think, in my opinion, then you can maybe go a little bit more into details, or maybe you don't need to go into details at all because you can look through it in a few minutes and there is nothing special going on.

00:07:08.827 --> 00:07:19.509
And I probably go into detail for certain parts of code changes, of a feature change or something, when I feel the need to it.

00:07:19.509 --> 00:07:33.129
And then I sometimes also download the code onto my machine to be able to really do code navigation and stuff, to really look through the code change, yeah, and then other changes really don't need much detail.

00:07:34.521 --> 00:07:35.363
I had another thought.

00:07:35.363 --> 00:07:52.862
What was it discovered was during code reviews that I saw a colleague, maybe not as familiar with Microsoft's code base, rewriting stuff or functionality that's already implemented in some of their helper code units.

00:07:52.862 --> 00:07:57.312
So it was really a possibility to point that out to them.

00:07:57.312 --> 00:08:04.687
So they learned code units, new code units from the base of the system app and reuse that and could get rid of some custom code.

00:08:04.687 --> 00:08:07.952
Yeah, so that's also a good thing.

00:08:08.673 --> 00:08:09.834
Very important point indeed.

00:08:12.279 --> 00:08:14.004
That is a big point and it goes with.

00:08:14.004 --> 00:08:23.610
You hit a couple points with the comments that you made and you touched upon maybe who should be doing the code review.

00:08:23.610 --> 00:08:38.711
Touched upon maybe who should be doing the code review because I also like to believe that code reviews can also be a learning experience or a teaching experience for someone, because I've had some individuals go through the code review experience that were new to AL development.

00:08:38.711 --> 00:08:48.769
Not necessarily to the code review purpose for, you know, validating the code, necessarily, but looking through it they were able to learn new things by looking at some code that others had created.

00:08:48.769 --> 00:08:52.433
So that's one aspect that I like about the code reviews.

00:08:52.433 --> 00:08:58.460
So they were doing it, not necessarily, like I said, for the approval process, but it was more of a training process.

00:09:01.347 --> 00:09:20.109
So your points, stefan, about learning the Microsoft-based code units or the base library, is important because so many things have been added, or so many new methods, so many new code units have been added, that a lot of developers do recreate that unintentionally, you know, unintentional duplication of what Microsoft already has.

00:09:20.109 --> 00:09:28.812
So being able to have multiple people look at it give some good insight and also provide the feedback with it.

00:09:28.812 --> 00:09:37.513
I like your approach Natalie too of what it is not, and it's one of those daunting tasks as well, because it does take time to do it.

00:09:37.513 --> 00:09:51.110
So the size of the code review matters as well, because I've seen pull requests with hundreds of files and I've looked at it and I just scratched my head and I'm like, do I just click approve or do I have to go through all of these changes Sometimes?

00:09:51.129 --> 00:09:51.551
you have to.

00:09:52.320 --> 00:09:57.706
Yeah, that's one thing to keep into consideration, I think, is the size of the code review.

00:09:57.706 --> 00:10:02.629
So, with that, what is your take on who should be doing the code review?

00:10:02.629 --> 00:10:12.044
Is it a senior developer, a developer functional consultant type, or or how do you if you fit the code review in the process?

00:10:13.467 --> 00:10:23.922
ideally everybody, but of course, this is not the way how we live it, due to organizational restrictions, maybe also permissions, whatever.

00:10:23.922 --> 00:10:29.474
It's a question of how your pull requests are actually set up in your environment.

00:10:29.474 --> 00:10:39.899
For example, we are using DevOps and we have some policies attached, branches that define that we have to create pull requests for everything.

00:10:39.899 --> 00:11:03.331
All of them have to be reviewed by at least one external let's say second developer, and this is very, very useful in my opinion, and I also really see the progress and quality since we switched from CIL to AL and this whole request approach.

00:11:03.331 --> 00:11:04.312
With code reviewing.

00:11:04.312 --> 00:11:10.528
You can learn so much on both sides really and prevent many mistakes, so glad.

00:11:13.301 --> 00:11:24.743
Now you had mentioned CAL back in the old you know the older versions of NAV and how the objects were embedded within the application, within the object designer.

00:11:24.743 --> 00:11:25.513
So the objects were built within the application, within the object designer.

00:11:25.513 --> 00:11:28.216
So the objects were built as part of the application.

00:11:28.216 --> 00:11:36.451
So keeping track of changes and doing code reviews if anybody did code reviews back then were extremely difficult.

00:11:36.451 --> 00:11:40.191
I know I used to export the text files, just to track changes.

00:11:40.659 --> 00:11:51.955
I had PowerShell scripts set up just to export the text files and then each day load them into a repository, so we could see the difference of what it changed, because it was very difficult in that environment to do it.

00:11:51.955 --> 00:12:02.500
So I'm happy to see that with AL we moved forward to Visual Studio Code and having separate files to build these extensions Exactly.

00:12:02.542 --> 00:12:09.120
So I suppose none of us is missing these old times I'm not missing it for one moment at all.

00:12:09.240 --> 00:12:13.491
So, finally, even doing since the 2016, so you had the opportunity to experience that as well too.

00:12:13.491 --> 00:12:16.948
Um, and it was similar process back all the way.

00:12:16.948 --> 00:12:23.323
If you go way back to in the vision when it first started, it was the same concept, other than the rotator, all the way up through.

00:12:23.323 --> 00:12:24.928
So so we had some challenges.

00:12:24.928 --> 00:12:31.630
So it's refreshing, and it's also depending upon when someone started working with it.

00:12:31.630 --> 00:12:40.133
It is a learning experience, or someone needs to adapt to the changes of the way things used to be done in Cal versus where they are with AL.

00:12:40.133 --> 00:12:44.667
And you mentioned one thing spelling mistakes.

00:12:44.667 --> 00:12:54.620
I'm famous for making a couple of those, by the way.

00:12:54.620 --> 00:12:56.427
With those Spelling mistakes, how do you determine it's a spelling mistake?

00:12:56.427 --> 00:12:59.337
And I did see a topic recently that someone spoke about is which language someone should code in.

00:12:59.337 --> 00:13:10.052
So that would actually, I think, would attribute to what constitutes a spelling mistake, because if someone's doing a code review and they're determining if the word's spelled correctly, what is your thoughts on that?

00:13:14.105 --> 00:13:15.410
My take on that is really simple.

00:13:15.410 --> 00:13:32.802
I have a VS Code extension that checks it and if it yells at me, I review that and that would be the benefit of actually downloading the the branch to have uh, um yeah, helper tools locally to help with the code review and spelling mistakes, and that that extension would be one of them.

00:13:32.802 --> 00:13:35.951
And whenever it's it's blue, it's an info.

00:13:35.951 --> 00:13:52.379
Then I I look at it and I usually keep some of the warnings that it spits out in the, either in my user settings or in the workspace settings, as exceptions, because sometimes abbreviations are treated as a spelling mistake, although they are not.

00:13:52.379 --> 00:13:58.602
But it does a really good job also with camera casing and everything to pick the words up and check everything correctly.

00:13:59.004 --> 00:14:03.917
So that really helps a lot which extension is that that you use for that?

00:14:03.917 --> 00:14:05.100
That sounds helpful.

00:14:06.062 --> 00:14:06.904
I would need to check.

00:14:06.904 --> 00:14:10.837
From the top of my head I don't know, but yeah.

00:14:15.697 --> 00:14:16.480
Can you repeat that please?

00:14:18.368 --> 00:14:19.272
Sorry, the spell checker.

00:14:19.902 --> 00:14:20.623
Oh, the spell checker.

00:14:20.623 --> 00:14:23.971
Okay, so the spell checker extension?

00:14:23.971 --> 00:14:26.600
Does it work with any language, or just english?

00:14:28.043 --> 00:14:31.009
there are extensions like additional extensions per language.

00:14:31.211 --> 00:14:39.154
I think english is base and then not you, you can load multiple languages and create your own libraries.

00:14:39.154 --> 00:14:51.495
Um, I've activated for american english and british english because because I have to develop some elements really in British English for a very specific application and this really works.

00:14:51.495 --> 00:14:53.947
So it has different libraries.

00:14:55.320 --> 00:15:01.792
Well, that's one I know many people use it and I work with many that use it and I haven't.

00:15:01.792 --> 00:15:12.345
But I think I'm going to start as soon as we're done with this, just to see, I'm afraid, I think think sometimes to see what comes up with it, but we'll see you really didn't use it yet?

00:15:12.345 --> 00:15:15.631
No, no, no, no.

00:15:15.631 --> 00:15:18.860
Do you believe that all these years?

00:15:20.101 --> 00:15:22.025
how can you survive any day like that?

00:15:24.750 --> 00:15:25.293
I've made it.

00:15:25.293 --> 00:15:41.390
I've made it, but I have I know many use it because I end up sometimes seeing in the pull request the dictionaries where they add words, as you had mentioned to you know, as the info for the words that they want to accept with the spelling.

00:15:41.390 --> 00:15:42.846
So I know others use it, which is good.

00:15:42.846 --> 00:15:59.767
So, with the code review and the code review process you had mentioned what it's not and looking for structural changes and coded changes how do you base it?

00:15:59.767 --> 00:16:15.370
What do you base it on as far as when you look at these you had mentioned structural changes and content Is it based on just experience or are there certain standards that you follow as far as like a library or documented somewhere?

00:16:17.201 --> 00:16:26.971
In my personal opinion, I try to stick to the Microsoft standards of what they are using in their base apps the base app.

00:16:26.971 --> 00:16:45.315
Plus and this is very important in the newer repositories like BC apps for the system application and the business foundation app, because other apps who depend on us or Microsoft.

00:16:45.315 --> 00:16:47.899
They should not switch between language styles.

00:16:47.899 --> 00:16:55.206
They should find the same style of code to attach to to read it easily.

00:16:55.206 --> 00:17:02.013
But I'm not telling that I'm applying everything blindly.

00:17:02.013 --> 00:17:04.146
There is always some criticism in it.

00:17:04.146 --> 00:17:17.413
I would not really stick to everything, but at least to everything that really makes sense and makes things easier to read.

00:17:17.413 --> 00:17:18.605
That's very important to me.

00:17:18.605 --> 00:17:40.826
What I have found helpful which is not followed, for example, by Microsoft is that properties within an object or whatever are sorted alphabetically, because only that way you can easily compare what's different between two versions of a file, between two different files actually.

00:17:40.826 --> 00:17:42.791
Yeah.

00:17:43.520 --> 00:17:44.124
That I do use.

00:17:45.101 --> 00:17:48.951
Some database structure that I I do use.

00:17:49.191 --> 00:18:06.826
By the way, I use azl tools and I set up the code cleanup to go through and clean up all of the sorting because I found, like you, it's easier to do a compare of what had changed if things are sorted in a certain manner because that way they're aligned, even if you use it to sort the procedures.

00:18:06.859 --> 00:18:14.891
I know there's some topic individuals have about how do you sort the procedures with the locals and the globals or do you group them together, sort them by name?

00:18:14.891 --> 00:18:25.673
But I have found in the code review process it's helpful to have it sorted and that's a valid reason for having them sorted, in my opinion as well to make it easier to do the review.

00:18:25.673 --> 00:18:31.811
So we talked about the use of a spell checker.

00:18:31.811 --> 00:18:35.069
Stefan, you mentioned downloading the source so you could have the spell checker.

00:18:35.069 --> 00:18:37.440
What about some of the other source code analyzers?

00:18:37.440 --> 00:18:48.547
Do you think that should be part of the process, because we know, with the source code as the app source cop, for example, and there's other tools available.

00:18:48.547 --> 00:18:50.817
Do you use those as part of the code view?

00:18:50.817 --> 00:18:52.584
Do you think they're helpful as part of the code review?

00:18:53.748 --> 00:18:55.513
absolutely yes, and that's actually.

00:18:55.513 --> 00:19:01.928
I did a live stream recently about where I reviewed one of the pull requests from microsoft and that's exactly what I did.

00:19:01.928 --> 00:19:17.188
I just ran this through all the analyzers, also the the linter cop, to get all the different warnings and everything right right away in VS code and then I could just write comments where where I, where I thought it was useful.

00:19:17.188 --> 00:19:24.252
I don't need to find those things myself if there is like helper tools that can do the work for you.

00:19:24.252 --> 00:19:30.049
And I just wanted to pick up on Natalie's comment on the guidelines introduced by Microsoft.

00:19:30.049 --> 00:19:38.549
I really agree with the approach to follow them where it makes sense, and I just wanted to give an example where I actively decided to not follow their guidelines.

00:19:38.980 --> 00:19:46.586
I think there is one rule for the variable naming that it should be exactly like the type you're using, for example, for table name.

00:19:46.586 --> 00:20:00.526
That rule is disabled in all my repositories, for example, because it makes sense to a certain degree, but there's just too many false positives where I wouldn't agree to this rule, so it doesn't make sense for me.

00:20:00.526 --> 00:20:14.143
And the object naming I decided a while ago already that I just cannot afford to have spaces in my object names, since we are limited to 30 characters, so it's a pascal case for me now through like everything.

00:20:14.143 --> 00:20:15.626
Same goes for field names.

00:20:15.626 --> 00:20:31.903
Um, so I know there was a this unwritten rule since forever that it should always be with spaces and everything, and then you end up abbreviating, then you add dots and then it's all just abbreviations, so no one knows what it actually has to mean if they don't look at the caption.

00:20:31.903 --> 00:20:34.352
So that doesn't make sense for me at all.

00:20:35.296 --> 00:20:50.450
I have to chuckle because I I feel what you're saying with the naming, with the 30 characters, because even if you try to do a customer card ext, if you're doing a customer card extension right, and then you have to put in a fix on it, yeah you end up.

00:20:50.450 --> 00:20:52.727
People start I see crazy abbreviations.

00:20:52.727 --> 00:20:57.326
Wherever you get some of the longer pages you know, like the sales credit memo, they start dropping off words.

00:20:57.446 --> 00:21:11.988
Or, you know, journal gets abbreviated a number of different ways and then you add up and then like, if you're doing app source or even for PDEs, you're recommended to use a suffix, an ethics, at least a prefix or a suffix of three characters.

00:21:11.988 --> 00:21:15.630
Now I like to add two extra characters per app.

00:21:15.630 --> 00:21:16.281
I'm doing so.

00:21:16.281 --> 00:21:18.525
It's five characters already for the ethics.

00:21:18.525 --> 00:21:23.468
I'm left with 25 characters, and that's just not enough if you have spaces and all this stuff.

00:21:27.480 --> 00:21:29.343
So it's just not enough if you have spaces and all this stuff.

00:21:29.343 --> 00:21:31.183
So it's a best-case case for me for a few years already.

00:21:31.183 --> 00:21:34.186
Although your approach makes a lot of sense, I totally agree.

00:21:34.186 --> 00:21:34.567
I don't do it.

00:21:34.567 --> 00:21:43.635
I only try still, because it's just the rest of being an OG, I think it's just I'm just being used to that.

00:21:43.635 --> 00:21:45.665
Oh my God, yeah, business Central Life and OG.

00:21:45.665 --> 00:21:46.404
I think I was being used to that all my business central life.

00:21:46.404 --> 00:21:57.528
I try to create it in the old way as possible, and if the space doesn't fit there then I simply squeeze it into a Pascal case or just remove one space and then the next.

00:21:59.061 --> 00:22:11.413
I think in the end it's all about consistency, and when I work for companies which have existing code and they want me to add code into their app or just help them develop and they decide to have the spaces, I of course adjust.

00:22:11.413 --> 00:22:12.865
So this is the second part.

00:22:12.865 --> 00:22:32.701
While Microsoft sets somewhat of the base of guidelines, I think if a company agrees for themselves, like we want to do certain things differently, this should also be, um, like always used, sorry, um, so like a company-wide rule.

00:22:32.701 --> 00:22:37.770
Set of of guidelines is the next part, the next layer, in my opinion.

00:22:38.311 --> 00:22:53.645
So, yeah, when, when a company agrees to do like the old way, then of course, so that that is a good point where you can start that the rules and the guidelines and to use can be company specific, whatever fits the, the company that's managing the code or the code that's theirs.

00:22:53.645 --> 00:23:03.326
And as long as I agree with you, as long as you're consistent with what you're doing, it makes it easier for whoever's working with it or anybody who is going to come in to do the code rework with the code after.

00:23:04.569 --> 00:23:16.035
I think one good example for this is this keyword I think, natalie, you posted the point where Microsoft agreed on or said that they are going to do it everywhere.

00:23:16.035 --> 00:23:21.872
So they are going to prefix variables System app, system app Okay.

00:23:21.872 --> 00:23:23.221
System app yeah, I mean.

00:23:23.221 --> 00:23:24.567
Base app is another story.

00:23:24.567 --> 00:23:27.480
System app okay.

00:23:27.480 --> 00:23:28.142
System app yeah, I mean.

00:23:28.142 --> 00:23:28.983
Base app is another story.

00:23:29.003 --> 00:23:41.201
So they're they're going to prefix globals and functions that are in a code unit scope with this, although it's not mandatory by the language, um, and I know, or I read a lot of comments on twitter, that many people do not agree with this.

00:23:41.201 --> 00:23:53.670
So then again, if I would do a review at a company where it was agreed that they're not going to use it, then you should never use it that way, because I feel like, in my opinion, consistency is key.

00:23:53.670 --> 00:24:03.476
So if you want to use it, then use it and always, if you do not want to use it, then only use it in those specific cases where it's necessary to use it and otherwise not.

00:24:03.476 --> 00:24:10.405
In those specific cases where it's necessary to use it and otherwise not, but not switching around from code unit to code unit, because this ends up being annoying, in my opinion.

00:24:11.950 --> 00:24:15.380
It does, which brings me to another.

00:24:15.380 --> 00:24:37.390
I have so many questions about this with code, code reviews and code processes, because you hit on a key point with this being added to the language as the language evolves and functionality evolves within the language and maybe even standards evolve with the language.

00:24:37.390 --> 00:24:42.435
Some code is created in earlier versions.

00:24:42.435 --> 00:24:52.761
Some code gets created all the way back from Cal and it's a functionality that needed to be migrated or moved or upgraded to work with AL or even in earlier versions of ALs.

00:24:52.761 --> 00:24:54.001
Maybe you can pick a version.

00:24:54.001 --> 00:25:06.461
What about bringing in and using some of that new functionality where there wasn't a standard before and there is a standard now or there's new addition now?

00:25:06.461 --> 00:25:09.013
Is that something where you fix it as you go?

00:25:09.013 --> 00:25:14.371
Should someone review and update the code base to use some of these new functionality for the standards?

00:25:17.275 --> 00:26:07.777
there's the challenge with that as far as adoption of new techniques and practices with code that hasn't been around for the inception of those changes that's a delicate topic, if I understood it correctly, because there are different approaches and when it comes to such new standards as introducing this Microsoft, for example, they have decided that they want to make it the new standard and the base app, but they also decided that for pull requests that are now already created for any new lines of code they already want to edit, or at least allow it to edit now from then on, want to edit or at least allow it to edit now from then on, what they do not do is to choose one point at a time and convert everything in a separate pull request.

00:26:08.345 --> 00:26:13.755
And this is what I would actually do with my apps, which are smaller than the base app or any other standard app, obviously.

00:26:13.755 --> 00:26:23.689
But when I want to switch to another coding standard, for me this is a topic for a separate pull request which is doing only that.

00:26:23.689 --> 00:26:39.452
And I don't want to have pull requests that have one main task to change some functionality, some funky stuff but then they also format this one, some totally unrelated code line, in that object changing to this and that I don't know.

00:26:39.452 --> 00:26:41.657
This is at least in my head.

00:26:41.657 --> 00:26:45.753
This is just one big mess and I don't see the the benefit of that.

00:26:45.753 --> 00:26:47.377
How do you think about that?

00:26:49.968 --> 00:26:54.615
I think, um, it's, yeah, it's somewhat agree with you.

00:26:55.355 --> 00:27:10.848
Um, I think my take on this is really as you said it has to be a separate code pull request and it's also like, if you change it through, like adjust something throughout the whole extension, this can introduce bugs, since you change everything, you touch the code.

00:27:10.888 --> 00:27:18.355
Basically, if you change it, something can break, and so this has to be where outside of the group of developers.

00:27:18.415 --> 00:27:32.130
In my opinion, if you're working on a pretend extension, the customer needs to know they need to test again and they probably need to test everything, so it should sit somewhere in in a testing environment for some time so they have time to review whether everything still works.

00:27:32.130 --> 00:27:40.511
If you're working for a product, then well, whoever like the testers, needs to know that they potentially need to retest everything because you really touched everything.

00:27:40.511 --> 00:28:02.395
The other approach is, if you do not want to do like a major change like this, I feel like when you're working on one code unit given that you don't have like code units with thousands and thousands of lines, if you have them separately, separately created and like smaller code units, I would probably convert them one by one as I work on them.

00:28:02.395 --> 00:28:15.451
If I'm working on one topic, then I can convert that topic because I know it will be tested anyways, because I'm doing changes to that topic so that I can adjust language and bring in those new language features as we go.

00:28:18.609 --> 00:28:19.874
It's a mixed approach.

00:28:19.874 --> 00:28:21.229
I think it sounds situational.

00:28:21.229 --> 00:28:22.532
Now you mentioned a point.

00:28:22.532 --> 00:28:29.448
If you're uh doing it for a small app, maybe it's easier to to do it all at once to find you brought up some points of.

00:28:29.448 --> 00:28:31.776
You know, maybe as you work through and you go through it.

00:28:31.776 --> 00:28:44.673
Uh, you also, natalie, you mentioned uh something I I think for the the two of the topic of and we started talking, I guess, around it is what's in a pull request for a code review.

00:28:44.855 --> 00:28:58.355
You had mentioned that upgrading functionality within the language, language functionality or language standards should be its own separate pull request, where feature or fixes should be their own separate pull request.

00:28:58.355 --> 00:29:01.842
What do you both think of?

00:29:01.842 --> 00:29:11.156
What should be in a pull request and what should be included with a pull request, and what I mean by that is is it one issue per pull request?

00:29:11.156 --> 00:29:15.016
Is it one major feature per pull request?

00:29:15.016 --> 00:29:17.750
And within the pull request?

00:29:17.750 --> 00:29:21.096
You know, if you use GitHub, you use DevOps.

00:29:21.096 --> 00:29:22.338
Those are the two popular tools.

00:29:22.338 --> 00:29:25.134
I know there are many other tools available that can be used.

00:29:25.134 --> 00:29:31.817
What documentation should be included with the pull request for the reviewer?

00:29:31.817 --> 00:29:37.472
Either one of you can jump on this one.

00:29:37.472 --> 00:29:39.231
I'm interested in hearing both of your opinions.

00:29:39.231 --> 00:29:47.838
You both have great opinions on all of this in points of view, so I'm eager to hear Stefan first.

00:29:49.526 --> 00:29:50.288
Okay, we'll alternate.

00:29:50.288 --> 00:29:51.112
Stefan, you go first.

00:29:51.112 --> 00:29:53.112
This time We'll alternate.

00:29:54.965 --> 00:30:03.138
Yeah, I mean again hours of potential talking First what should be an issue.

00:30:03.138 --> 00:30:04.611
I mean again hours of potential talking First what should be an issue.

00:30:04.611 --> 00:30:17.530
I mean if you and there is probably a line between what should be an issue or a feature request, possibly, and what should be an epic, with lots and lots of issues or features, depending on the platform you're using.

00:30:17.530 --> 00:30:20.733
So that shouldn't be too big either.

00:30:20.733 --> 00:30:25.652
And then, if you need to have a bigger issue, how many pull requests should you do?

00:30:25.652 --> 00:30:35.810
And I think this is also important if you want to control the or if you want to improve the quality of the code review itself.

00:30:35.810 --> 00:30:47.688
Because, as you said, if you have thousands of objects touched in a single pull request, you're not going to expect that anyone takes the time, sits down eight hours straight and just reviews everything you did there for the last three months.

00:30:48.189 --> 00:30:55.813
So, not to mention the, the merging conflicts that arise with this, with those kind of huge changes.

00:30:55.813 --> 00:31:00.865
So I'm really in favor of small pull requests.

00:31:00.865 --> 00:31:07.991
I can imagine lots of pull requests for a single issue, as long as you have something that can be merged.

00:31:07.991 --> 00:31:22.268
It's really hard to come up with an example here, but if you're working on a feature and you can encapsulate a few things out of this feature, like first I'm going to introduce this change and then I need to introduce five change and then I'm I need to introduce five more changes.

00:31:22.268 --> 00:31:22.628
I can.

00:31:22.628 --> 00:31:27.611
I can separate those and merge them without breaking anything in the target branch I'm merging to.

00:31:28.113 --> 00:32:03.921
I can totally imagining splitting it up just to make it easier to merge, to review and to test possibly um, I have problems with the 100% agile paradigm, like making hundreds of tiny pull requests one by one, then fixing some previous pull requests and this and that, and you have a long, long commit list of tiny changes or mostly bug fixes, that nobody can really understand.

00:32:03.921 --> 00:32:35.236
And why I'm mentioning that is I'm developing, as I said, apps for AppSource and they are also to be used on on-premise environments, and we have teams that create also on-premise extensions, maybe from our AppSource extensions and for them although no one has approached me yet to do that, but in my opinion the ideal way is that I provide such pull requests that any other extension developer can use as a pick list.

00:32:35.236 --> 00:32:44.233
They want a feature A and then this and that, and they don't want to pick 100 pull requests, but only a few with the functionality they need.

00:32:44.233 --> 00:32:49.251
They don't need to search for a bundle of pull requests for actually one big feature.

00:32:49.251 --> 00:33:14.773
So usually I try to really keep pull requests clean so they cover a specific feature topic or bug fix for something, however very encapsulated, and sometimes I do hit the situation that my pull request becomes too big in terms of the number of objects to look at.

00:33:15.464 --> 00:33:35.019
However, even when I do that, I still take care of my commits inside that pull request that they are separated nicely so you can click through the commits and check them individually, like, for example, when I just did a code cleanup using the AZAL tools.

00:33:35.019 --> 00:33:43.852
Then per single conversion step I do a single commit so you can check them one by one.

00:33:43.852 --> 00:33:45.912
This is helpful for the reviewer.

00:33:45.912 --> 00:33:53.298
But overall I still follow the line or the paradigm.

00:33:53.298 --> 00:33:59.057
You have to keep them small enough because it's a hazard to look at two and two-thirds.

00:33:59.057 --> 00:34:00.780
But again.

00:34:01.082 --> 00:34:10.931
I found it important to keep the commit history readable even to human beings, anybody else handing it that way.

00:34:12.905 --> 00:34:21.862
Yes, I prefer, as you had mentioned, I prefer the smaller pull requests for the individual changes, and I too too do.

00:34:21.862 --> 00:34:26.356
Commits are tough because it depends on what you're working on.

00:34:26.356 --> 00:34:30.510
I do go back and if I'm doing a code review I will look through the commit history.

00:34:30.510 --> 00:34:43.585
But, depending upon the scope or the size of what the developer has with working on, some of their commits may be just a sense of saving and getting the code into the repository in the branch for that.

00:34:43.585 --> 00:34:50.326
Whatever they're working on Some of that I know we promote committing it to get it stored in there.

00:34:50.326 --> 00:35:01.393
In the event that you have a problem with the system that you're working on, or if somebody needs to take leave because of illness or from other emergencies, somebody else can go pick back right up where they have and see the changes that they've made.

00:35:01.393 --> 00:35:07.889
So some of that with me is also with the commits depends upon the duration of the modification that you're working on.

00:35:07.889 --> 00:35:15.193
But those large pull requests I think are very difficult to go through.

00:35:15.193 --> 00:35:20.510
And also a pull request per I don't know if you want to call it issue.

00:35:20.510 --> 00:35:21.969
I mean, again, it depends what you're working on.

00:35:21.969 --> 00:35:23.773
But one small topic.

00:35:23.773 --> 00:35:32.675
I'll leave the word as a topic so that somebody's reviewing is they're not trying to look at multiple things, they're looking at one specific topic at a time so that they can put.

00:35:32.675 --> 00:35:37.768
You know, I like to put my mind into that one topic and not try and say, okay, well, this goes with this, this goes with that.

00:35:37.768 --> 00:35:42.271
I can see the changes all for this one thing and see where it touches and be able to work with it.

00:35:42.271 --> 00:35:47.634
And then, as far as some of the comments, you know.

00:35:47.653 --> 00:35:56.960
To go back to the code review as well, I know sometimes I go with you know I saw TNA's code review session at Directions, north America.

00:35:56.960 --> 00:36:10.126
I know he did it in Europe as well and you know I follow it and I it's one of the things that really got me thinking about this topic is even like putting in, like the nitpicking, because it you know how deep do you go with the comments that you're making?

00:36:10.126 --> 00:36:13.644
I mean, there's some things that are fundamentally wrong, but then there's other things.

00:36:13.644 --> 00:36:15.208
Sometimes I have to go.

00:36:15.208 --> 00:36:18.393
Eh, it's okay, but do we let it go?

00:36:18.393 --> 00:36:19.295
Do we not let it go?

00:36:19.295 --> 00:36:21.840
Maybe you may want to change it or think about doing it this way.

00:36:21.840 --> 00:36:25.233
So I'm with Stefan.

00:36:25.233 --> 00:36:30.034
We could talk about this for days, I think, and not cover all the code review processes.

00:36:31.309 --> 00:36:32.713
I want to comment on that real quick.

00:36:32.713 --> 00:36:36.414
When I was reviewing the Microsoft code I had exactly that thought.

00:36:36.414 --> 00:36:47.335
Do I really complain about all the different typing mismatches and everything that the lindelkop warns about, because I really don't like those um?

00:36:47.335 --> 00:36:49.327
Or do I just let it go and just?

00:36:49.327 --> 00:36:49.967
I mean it?

00:36:49.967 --> 00:36:52.094
Functionality wise it doesn't change anything.

00:36:52.094 --> 00:36:58.577
But what I know is in microsoft's code base it's really hard to have them change anything once it's in there.

00:36:58.577 --> 00:37:09.168
So I decided to to comment on everything, because now there is the opportunity to fix those and I don't need to look at this for the next like 20 years, um.

00:37:09.168 --> 00:37:18.067
So yeah, because I'm like in in partner code, I think it's way easier to fix those kind of things afterwards.

00:37:18.067 --> 00:37:25.456
If you come across those kind of um, yeah, I wouldn't, wouldn't call it issues for the lack of a better word.

00:37:25.456 --> 00:37:27.545
But yeah, you can, you can fix those afterwards.

00:37:27.545 --> 00:37:29.289
But for microsoft's code it's a different story.

00:37:29.289 --> 00:37:31.313
Another reason.

00:37:31.474 --> 00:37:45.061
A good argument to handle it that way, as you said, is um, I don't know how you handle it, but in my career, it was always very helpful for me to look at Microsoft code, to learn from it, to copy some patterns or whatever.

00:37:45.061 --> 00:37:56.865
And if we let now bad Microsoft code into the code base, this will multiply by everyone who will see it and work with it, and this is something that I cannot live with.

00:37:56.865 --> 00:38:28.451
This is something that I cannot live with, and so my pull requests, my code reviews sorry, always very nitty if such an adjective exists, and it can be very annoying in that, and I am also fearing that people get really irritated by that, and I hope nobody takes it personally, because even if you do that, the writer of this pull request, the author, still is king.

00:38:28.851 --> 00:38:41.159
He or she can always decline anything or accept it or at least talk about it, and we never know what's on their mind, like how they want it to be.

00:38:41.159 --> 00:38:51.458
And I've made the experience that at Microsoft they are open to even those little nit things of code reviews.

00:38:51.458 --> 00:38:57.371
Most of them are really considered and sometimes you get a thank you oh, I didn't see that, or whatever.

00:38:57.371 --> 00:39:06.213
So if you have the time and if you have the nerve to really do that, just go for it and see what happens.

00:39:07.505 --> 00:39:09.554
What I also did in the code review.

00:39:09.554 --> 00:39:12.034
I ended up actually doing those changes for them.

00:39:12.034 --> 00:39:27.114
I created a pull request onto the pull request branch because I said, well, I've downloaded the branch, I'm working on it and while I'm looking at it I can right away fix those little like here is a semicolon too much or here's like a casing mid-mesh.

00:39:27.114 --> 00:39:33.634
And I said, oh, here would I just add some spaces like empty lines, to just make it more readable.

00:39:33.634 --> 00:39:54.052
Just those kind of things I usually do right away in pull requests because I'm looking at it anyways, and then the reviewer still needs to review my review pull request and accept all the changes to their branch and then that way they know about what I changed but they don't need to do the work again, which I already did before.

00:39:55.440 --> 00:39:56.045
That's a good point.

00:39:56.045 --> 00:39:56.144
Which?

00:39:56.164 --> 00:40:01.137
wouldn't be necessary if Microsoft used all those tools available in their own repository.

00:40:05.726 --> 00:40:17.898
It is true, because if you run through even their base OS code analyzers, some of their base code will not pass any of those as well.

00:40:17.898 --> 00:40:36.032
So it's good your point is valid, natalie, as well is if they cleaned up some of those inconsistencies and if we're using that as a model to go by, we could eliminate the multiplication of potential other bad habits, bad design or other issues with the code as well too.

00:40:36.032 --> 00:40:47.391
But sometimes I think we've all been in the case as well as oh, I'm just going to add this, I'll add this, I'll add this, and then you go back and look and say, ha, had I known this from the beginning, I would have redone this whole thing and done it this way.

00:40:47.391 --> 00:40:52.697
Uh, so there's sometimes I it goes back to your word I like likes your new word, nitty.

00:40:52.697 --> 00:41:12.045
Uh, you know when you're nitpicking at some of this stuff and just trying to, you know, get an understanding of what the I guess I have a new nickname nitty natalie.

00:41:12.065 --> 00:41:12.989
I like that that right there.

00:41:12.989 --> 00:41:13.411
See, we can coin.

00:41:13.411 --> 00:41:14.074
That is nitty natalie.

00:41:14.074 --> 00:41:16.081
Well, you have the librarian, but so it's nitty natalie, the bc docs library.

00:41:16.101 --> 00:41:22.210
Maybe I will need the other one, or maybe it's already my internal name in Microsoft, but nobody called me that way.

00:41:24.166 --> 00:41:26.510
I'll have to make sure we Niddy, natalie.

00:41:26.510 --> 00:41:32.373
No, my thoughts to you is with that Niddy, with anybody who makes the comments, I always look at the intent.

00:41:32.373 --> 00:41:39.891
I mean, there's nothing wrong with constructive criticism because, as you both had mentioned, sometimes someone may not be aware of something, or they can.

00:41:39.891 --> 00:41:48.007
Always, you know, I know myself, I always want to learn to do, you know, do things better if possible, or even learn different ways to do things.

00:41:48.007 --> 00:41:56.427
It doesn't necessarily, you know, different doesn't always mean better, but sometimes difference there, and I think it's all in the intent of who's doing the review and the comments they make.

00:41:56.427 --> 00:42:09.679
If it's meant to be helpful or constructive, then people should be receptive to it and they make a decision on it and not think of them as being, you know, nitty-nattly how does that?

00:42:10.126 --> 00:42:10.766
how does that work?

00:42:10.766 --> 00:42:16.666
If you're on your own, like if you're an independent developer, like, how do you code review?

00:42:16.666 --> 00:42:21.155
Do you find peers to help you review your code?

00:42:21.155 --> 00:42:22.438
How does that work?

00:42:24.311 --> 00:42:42.871
sometimes there are in companies I work with, there are other developers who can do the review, but sometimes there's just no one, so I, uh, mostly review myself after a time you sleep on it first yeah, but I mean you always go back to your own code and wonder what you did there and why you did that.

00:42:43.485 --> 00:42:57.315
So yeah, but again, mostly using tools to get as much like warnings and infos and errors up front to do as less mistakes as I possibly can.

00:42:57.315 --> 00:42:58.550
But yeah, you're absolutely right.

00:42:58.550 --> 00:43:00.764
I mean, if there is no one to review, there is no one to review, there is no one to review.

00:43:00.764 --> 00:43:04.612
And sometimes it would be better if someone would have reviewed my code.

00:43:07.065 --> 00:43:16.994
Would you still go through the same process as if you're reviewing someone else's code or because you're on your own, do you just speed through it?

00:43:19.206 --> 00:43:27.751
Well, to be honest with you, I mean mostly it's, uh, going through the code, getting it in, getting it tested, and if it works, it works.

00:43:27.751 --> 00:43:36.146
But, um, yeah, sometimes for for more crucial stuff, I really go back to it after a few days and review myself, as I would normally review others.

00:43:36.146 --> 00:43:49.291
Um, but most of the code I just end up being working on and reviewing and reading what again and over again, and then if I notice something, I obviously, um, yeah, correct it that's good.

00:43:49.351 --> 00:44:04.505
It's a good habit to have because you know, I I know there's plenty of independent developers out there that they'll probably skip through some of that, unfortunately so just to kind of, we're talking about code views.

00:44:04.585 --> 00:44:08.134
I do want to talk about clean code and what clean code is.

00:44:08.134 --> 00:44:15.503
In a minute I think there's something else that we wanted to discuss, but now I'm thinking of this from the process point of view.

00:44:15.503 --> 00:44:17.447
Stefan, you're talking about testing.

00:44:17.447 --> 00:44:18.989
Natalie, you mentioned it as well.

00:44:20.512 --> 00:44:30.152
So you have within a repository, you'll have a main branch, and the main branch, I'm assuming, should be whatever is loaded in production, whatever is in someone's production environment.

00:44:30.152 --> 00:44:34.215
But there also is a point where there is a test environment.

00:44:34.215 --> 00:44:42.838
So someone will make a branch, that will make a modification for a branch and they'll make a pull request.

00:44:42.838 --> 00:45:06.425
What are your thoughts on having a branch for whatever's in Sandbox, the Sandbox environment, so that we know what's in testing or what somebody's working on a pull request into a test branch to have that code be tested and then, once that passes, have a pull request from the test branch into the main branch for the features that they'd want to bring forward?

00:45:06.425 --> 00:45:15.791
Or would you load code into the test branch from a developer branch and then, once it's completed, do a pull request to bring it into the main branch?

00:45:16.974 --> 00:45:47.192
I still don't get what a test branch is, because I'm developing a development branch, a feature branch, so to speak, and when I'm finished and I'm creating the pull request, the pull request policies attached to Azure DevOps, they just run pipelines based on the newly created code, temporarily merged into the target branch, and this is then tested by running automated tests.

00:45:47.192 --> 00:45:49.456
So what is a test branch?

00:45:50.585 --> 00:45:53.237
Well, I was thinking more of when you had user-based testing.

00:45:53.237 --> 00:45:58.713
Stefan mentioned having the users test some functionality and test some changes Automated testing.

00:45:58.713 --> 00:46:00.577
I'm a huge advocate for automated testing.

00:46:00.577 --> 00:46:01.067
That's a whole.

00:46:01.067 --> 00:46:02.733
We could talk days about that too.

00:46:02.733 --> 00:46:10.112
So, yes, when you create a pull request to get brought into, we'll call the main branch production.

00:46:10.112 --> 00:46:10.809
You could run those.

00:46:11.130 --> 00:46:16.576
All those automated tests should be executed to ensure that they pass as function.

00:46:16.576 --> 00:46:28.018
But all of those automated tests or in some cases, when working for customers or if you're working for an end user, you still have to pass user acceptance testing in some cases.

00:46:28.018 --> 00:46:35.492
So at that point you will have a sandbox environment with changes that are loaded for the users to test afterwards at a point.

00:46:35.492 --> 00:46:43.097
I mean you can't have some automated tests for those, but in this type of environment you still would want to have user acceptance before moving it to production.

00:46:43.097 --> 00:46:48.356
So maybe it's good that you don't have to deal with that.

00:46:48.356 --> 00:46:50.932
Stefan, what are your thoughts on that?

00:46:50.932 --> 00:46:54.416
Do you have to do the same type of process or have you worked with that same type of process?

00:46:56.186 --> 00:46:57.242
Yes, and it's challenging.

00:46:57.242 --> 00:47:00.427
Yes, and it's challenging.

00:47:00.427 --> 00:47:10.612
Through the conversation I tried to think about how that used to be before we were using extensions in the CL days, but I can't really remember anymore.

00:47:10.612 --> 00:47:15.155
So the challenge is really that you have one code base.

00:47:15.155 --> 00:47:24.099
So if you have one testing environment and one test branch and you have multiple features, what are you doing if one feature gets approved but three are still waiting for testing?

00:47:24.099 --> 00:47:24.920
How can you deploy?

00:47:24.920 --> 00:47:29.742
Because you cannot just merge the branch, because it contains all the feature branches that are ready for testing.

00:47:31.965 --> 00:47:39.235
So I'm using AeroGo mostly and I think I'm not sure if it supports more than that one branching strategy.

00:47:39.235 --> 00:47:45.197
But my main branch is basically that what's currently currently the bleeding edge of development.

00:47:45.197 --> 00:48:07.813
If I do feature branch and if I do that because I don't do that usually and I will come to that in a minute then that will obviously be separate, but once it's done it will be merged into main and then, when I'm ready to deploy to production and that's what I would call a clean deployment then I would merge this main branch.

00:48:07.813 --> 00:48:12.737
If everything gets approved, I would create a release and that would then create a release branch.

00:48:12.737 --> 00:48:15.614
So my main branch actually is not in production.

00:48:15.614 --> 00:48:31.432
It's my latest release branch that allows me to do not clean deployments but one feature at a time, where I would then cherry-pick those changes, those commits, onto that latest release branch and then redeploy that as a new version.

00:48:31.432 --> 00:48:48.989
That's how I do that and since I'm mostly on my own, I do not do feature branches for smaller things I'm doing there is a word for that I'm doing that Backlog development or something.

00:48:48.989 --> 00:48:51.376
No, I don't remember.

00:48:51.376 --> 00:48:59.907
But what I do if something is not yet ready to deployment to production and I need to do that clean deployment, I will do feature flex.

00:49:06.344 --> 00:49:07.246
There is a nice open source extension.

00:49:07.246 --> 00:49:08.449
I would need to look that up.

00:49:08.449 --> 00:49:11.878
I think we can put it in some description afterwards or something.

00:49:11.878 --> 00:49:13.682
But that will let you do like code.

00:49:13.682 --> 00:49:27.137
Like if basically you can switch off code, you can do application areas by features and the features can be enabled and disabled separately in the environment, per company or not per company, don't quote me on that please.

00:49:27.137 --> 00:49:34.278
But you, what you can do is you can push code to production and you just don't enable it.

00:49:34.278 --> 00:49:44.815
So the pages are not there, the code is not executed, table fields get created, because that's just how it is, but nothing runs and if you do that correctly it really works very good.

00:49:44.815 --> 00:49:48.775
So that's how I usually do that approach.

00:49:48.775 --> 00:49:57.838
Obviously, if I do have a bigger feature then I will put it on a different feature branch because it's too much of a hassle to put those feature conditions everywhere.

00:49:57.838 --> 00:50:05.269
But yeah, I mostly do development on the branch itself and then push everything to production once it's ready.

00:50:05.269 --> 00:50:06.653
That's good.

00:50:07.596 --> 00:50:08.818
That's good, it's interesting.

00:50:08.818 --> 00:50:13.275
I like to talk and to see how others do it as well.

00:50:13.275 --> 00:50:26.286
I mean, there's many different options and again, I think it does come down to what works for the environment, as long as there's some standards and checks in place to make sure that some management of the source code, which is important.

00:50:26.286 --> 00:50:31.326
Clean code what is clean code?

00:50:31.326 --> 00:50:35.838
Who wants?

00:50:35.858 --> 00:50:36.179
to go first.

00:50:36.179 --> 00:50:37.846
That depends who you ask.

00:50:37.927 --> 00:50:38.449
Stefan, go ahead.

00:50:38.449 --> 00:50:42.304
We went to Natalie first last time, so we have to go to you this time.

00:50:42.324 --> 00:50:43.608
I was about to say that it depends.

00:50:44.902 --> 00:50:55.420
It totally depends and I think it's again what you agree on in a certain group of developers, and what that group is or how the scope is, is probably variable.

00:50:55.420 --> 00:51:16.592
But, um, yeah, there are guidelines introduced by microsoft, there are guidelines introduced by the language itself, um, for example, just to pick one, the the set load fields, um, which just plain improves performance if you use it or makes it worse if you do not use it.

00:51:16.592 --> 00:51:18.306
So that's a guideline, I consider.

00:51:18.306 --> 00:51:29.731
If you do not use it, it's not clean code, because there is something which, with no question, makes it faster and I think Waldo proved that a couple of times and asked Microsoft why it is that way.

00:51:29.731 --> 00:51:33.210
And I'm not loading the correct fields.

00:51:33.210 --> 00:51:38.105
It's still faster that way that even if you end up not loading the correct fields, it's still faster.

00:51:38.105 --> 00:51:42.693
So any time I see a read operation to the database where no setLoadFields is set, I question that.

00:51:44.440 --> 00:51:45.324
That's a good strategy.

00:51:45.324 --> 00:51:46.789
I like that with the setLoadFields.

00:51:50.364 --> 00:52:08.088
So there are those kind of guidelines by the language and then it's just what you agree on as style guides, like the nice-to-have features, where you're just saying, well, we do add this keyword in front of everything in our company, we follow Microsoft's guidance there.

00:52:08.088 --> 00:52:13.211
Then that's like anything that's not following this, not clean code in my opinion.

00:52:13.840 --> 00:52:15.262
I got it Understood, Natalie.

00:52:15.262 --> 00:52:16.465
What is your take on clean code?

00:52:17.907 --> 00:52:20.994
um, I agree, but I would start somewhere else.

00:52:20.994 --> 00:52:30.894
When I imagine clean code, I imagine a code base consisting of good structured code.

00:52:30.894 --> 00:52:46.021
Good structured code, easy to read, also to humans, with having procedures, with speaking names so one could derive what are they actually doing?

00:52:46.021 --> 00:52:51.405
I want to keep it as redundancy-free as possible.

00:52:51.405 --> 00:52:54.949
We don't want to multiply code, we want to reuse it.

00:52:54.949 --> 00:52:59.306
It's code that uses the Microsoft base as much as possible.

00:52:59.306 --> 00:53:10.806
Reuse as much as possible and following the same rules everywhere to be consistent in general.

00:53:10.806 --> 00:53:22.601
This is for me one of the most important rules, and on top of all that is everything that Stefan already mentioned To comply to some rules, conventions that we already know.

00:53:22.601 --> 00:53:31.074
It's about formatting that, luckily, the AL language itself already does for us more or less.

00:53:31.074 --> 00:53:45.442
It does for us more or less, but if a code base is really well readable and maintainable, I think then we've come close to the goal of having clean code.

00:53:45.461 --> 00:53:55.655
You mentioned at the last sentence what I wanted to ask next about all of this, and that's where does code readability come into this?

00:53:55.655 --> 00:54:00.978
Again, we've seen topics recently where people have shared, where they talked about the tyranny operator.

00:54:00.978 --> 00:54:03.889
Does it make the code more readable or less readable?

00:54:03.889 --> 00:54:10.771
Is it better to have less lines of code that have a lot of calculations, for example, in it?

00:54:10.771 --> 00:54:26.150
Or, if you have a procedure that returns a Boolean, just have a result and just exit the word result, instead of exit and having a if not, then this, that case, this type of process when does code readability?

00:54:26.150 --> 00:54:29.101
What is your take on the code readability in here?

00:54:29.101 --> 00:54:38.965
Should you try to have as few aligns as possible or should you expand it out as much as possible to make it logically flow?

00:54:40.690 --> 00:54:41.351
Depends.

00:54:41.351 --> 00:54:52.784
Think of when IA was introduced, that we finally could get rid of the superfluous begin-ends because the code cop or another code analyzer just warned about them.

00:54:52.784 --> 00:54:55.130
Like you don't need them here, put them away.

00:54:55.130 --> 00:55:01.730
So I did, for example, that, and this already decreased the code to some level.

00:55:01.730 --> 00:55:08.623
Yeah, help me out.

00:55:10.719 --> 00:55:14.625
Stefan, what do you think with code readability or what can make it helpful?

00:55:17.523 --> 00:55:21.731
Yeah, that also picks up a little bit on the take from Natalie before.

00:55:21.731 --> 00:55:28.039
I think readability sometimes comes at a cost or the other way around.

00:55:28.039 --> 00:55:34.030
If you want to improve something else, another aspect of your, your application, it might decrease readability.

00:55:34.030 --> 00:55:49.958
And the approach I'm thinking of is what vieko is showing on every session, I think recently his approach to testing and unit testing with interfaces and really extracting dependencies from your functions.

00:55:49.958 --> 00:55:52.806
That really makes it way easier to test functions.

00:55:52.806 --> 00:56:01.164
It also makes sure that functions only serve a single purpose and really a single purpose decreases dependency and like database dependency.

00:56:01.184 --> 00:56:02.108
I never thought about that.

00:56:02.108 --> 00:56:02.670
It's and it's.

00:56:02.670 --> 00:56:05.541
It's awesome to that that he brought that up.

00:56:05.541 --> 00:56:11.271
But what I notice is that, um, readability really is not better with this.

00:56:11.271 --> 00:56:25.889
If I have like 10 different interfaces that are just there to make it easier to test those functions and if I have everything split out so every function really does one thing and one thing only, it does not help readability at all.

00:56:25.889 --> 00:56:39.326
And also, if you increase readability or if you really make a function more generic so it can be reused wherever it needs to be reused, it can decrease performance, for example.

00:56:39.326 --> 00:56:48.432
And the question always is how much do you want to increase readability at the cost of other questions, other topics, and how much do you?

00:56:48.432 --> 00:56:53.692
How much value does those other topics maybe have, and how much can you decrease readability?

00:56:53.692 --> 00:56:57.885
So it's still good enough, I would say so.

00:56:57.945 --> 00:57:03.855
It's really not that easy no, it is, and a lot of this is, it's, it's.

00:57:03.855 --> 00:57:09.472
I hear the word depends and I get asked a lot of questions and sometimes I say the same thing.

00:57:09.472 --> 00:57:20.826
I'm like well, it depends, because, unfortunately, fortunately depends how you look at it, with development there isn't, or with a lot of things in life, it's not just development, there isn't a one-size-fits-all right.

00:57:20.826 --> 00:57:35.590
There's a lot of things that are situational, depending upon how it's going to be used, depending upon the environment you're in or depending upon you know, a number of factors, but I'm just trying to narrow it down to also get some, um, good ideas.

00:57:35.590 --> 00:57:38.161
Uh, myself, to see, I do this.

00:57:38.161 --> 00:57:45.528
I just like to learn and to pick up and to have the great conversations with, uh, some of the great members of the community that we have, such as, uh, yourselves.

00:57:45.528 --> 00:57:47.981
And now I'm going to stick with that nitty natalie.

00:57:48.003 --> 00:58:01.516
I have to keep telling myself in my head nitty natalie nitty natalie, and just add one more thing, maybe, um, to how complexity and code readability conflict with other things in your code you need to worry about as well.

00:58:01.516 --> 00:58:10.532
That's maybe where code review can help again, so you can have others read your code and say, well, I don't have a clue what you're doing there.

00:58:10.532 --> 00:58:34.434
Either you need to document it or you need to just change the way you write this, this code, make it more, more readable, and I'm I'm not sure where I picked up that um, but basically a quote what, um, what makes a developer a senior developer or an experienced developer if they can develop complicated code and make it look easy, like complicated functionality in in easy code.

00:58:34.434 --> 00:58:36.021
Make it easy to understand.

00:58:36.021 --> 00:58:38.427
That's where what is really difficult, I think.

00:58:40.284 --> 00:58:40.905
I like that.

00:58:40.905 --> 00:58:44.088
That is a good approach to have with that.

00:58:45.400 --> 00:58:47.143
Maybe it's time for some confession.

00:58:48.226 --> 00:58:49.009
Some what.

00:58:50.010 --> 00:58:59.175
Some confession, because if anybody asks me, natalie, does your code base, is it clean?

00:58:59.175 --> 00:59:00.762
Do you produce only clean code?

00:59:00.762 --> 00:59:02.346
My answer would be no.

00:59:02.346 --> 00:59:09.425
You would for sure find many places that are not perfect, although I'm that nitty, but um, um it's.

00:59:09.425 --> 00:59:27.179
It can never be perfect, and sometimes I'm struggling with inner conflicts similar to those that Stefan already described, and sometimes it's a lack of time, and then you're not patient enough, whatever, and so my code base isn't perfect either.

00:59:27.621 --> 00:59:36.467
And this is where, really, the code reviews from others who are as nitty as me are so important, because they remind me hey, why didn't you do that here?

00:59:36.467 --> 00:59:38.342
And what's what's happening here?

00:59:38.342 --> 00:59:39.344
I don't understand this.

00:59:39.344 --> 00:59:52.711
This is so good input, and if this is, yeah, practiced vividly, this improves really a lot, and and I really love that approach.

00:59:52.711 --> 01:00:03.635
So please don't ever uh assume because somebody like me is needy that that we are, uh, or think we are perfect ourselves.

01:00:03.635 --> 01:00:04.416
We are surely not.

01:00:04.898 --> 01:00:14.327
And one thing I would like to pick up um, half an hour ago, I think you, uh, br, mentioned a word that was criticism or criticize.

01:00:14.327 --> 01:00:30.664
No matter whether I add 10 comments in a PR as a reviewer or 100, no matter whether they are nits or bigger issues.

01:00:30.664 --> 01:00:31.248
None of them is a criticism.

01:00:31.248 --> 01:00:32.150
They are just issues that I see, that I read.

01:00:32.150 --> 01:00:36.148
It's like reading a text and decide okay, there's a spelling mistake or I don't know.

01:00:36.148 --> 01:00:52.635
But this is really no criticism at all and if any coder out there feels like it is, this is something that needs to be worked on because it doesn't help.

01:00:52.635 --> 01:01:09.150
Needs to be worked on because it doesn't help and of course, I, as a reviewer, can reduce my amount of nits that I'm pushing in there, but it's all a question of communication.

01:01:11.541 --> 01:01:12.405
No, I like that.

01:01:12.405 --> 01:01:21.809
And to go back to your confession, I agree with you because I look at some code that I have written and I sometimes scratch my head and say why do you do it that way?

01:01:21.809 --> 01:01:24.702
Um, well, why did you do it that way?

01:01:24.702 --> 01:01:48.092
Or you know you could have done it a different way, and sometimes it's a point in time, uh, sometimes it's a matter of understanding, it's a matter of, I think, for all of us and I mean my point in time it's maybe you weren't aware of something at the time, whatever it may be that you know, a guideline, process, practice, or even just the requirement that you had changed through the process, as it does happen to.

01:01:48.280 --> 01:02:27.000
So I agree with you that everybody can benefit from a review and the comments of others of what they may see, because, um, you can sometimes become blind, uh, to yourself, and sometimes another fresh point of view can help help you, or another perspective I guess you could say it's the word I like to use can help you see things a little bit differently and understand, because of you know, sometimes we get set in our thoughts and our patterns ourselves that hearing and seeing the perspective of others is important and, yeah, I think that it's the word people use, the word constructive criticism.

01:02:27.000 --> 01:02:33.876
I think it should be feedback or something like a less harsh word, I guess.

01:02:33.876 --> 01:02:54.505
I guess you could say, because it is that sometimes just looking to help each other or to give different perspective, I call it like I had mentioned, just so that you can see it maybe from a different point of view and get understanding with that I feel like, in the end, we are all like working together on a code base, and that's really how I think about that.

01:02:54.639 --> 01:02:55.021
It's just.

01:02:55.021 --> 01:02:58.806
I'm not criticizing yourself, I'm not criticizing the code you're writing.

01:02:58.806 --> 01:03:01.568
I'm just telling you that I would do that differently.

01:03:01.568 --> 01:03:04.730
Or here you did something that I wouldn't expect there to be.

01:03:04.730 --> 01:03:09.840
If it comes to logic, or if it's just those kind of small things like here's a typo or something, it's just.

01:03:09.840 --> 01:03:11.722
I mean review my mail, my email.

01:03:11.722 --> 01:03:12.563
Well, I mean review my mail, my email.

01:03:12.563 --> 01:03:13.666
Well, I would write it differently.

01:03:14.065 --> 01:03:15.487
All right, take what you want.

01:03:15.487 --> 01:03:21.536
With this, I mean, you don't need to implement it, but it's just my opinion about what I, what you wanted me to review.

01:03:22.280 --> 01:03:23.606
So no, I like that.

01:03:24.563 --> 01:03:27.885
It's good, or even asking why you're doing it that way.

01:03:29.530 --> 01:03:36.644
Yeah, sometimes sometimes I also in pull requests or in code reviews I ask questions like what is about the?

01:03:36.644 --> 01:03:39.072
Why did you implement it like this and not like this?

01:03:39.072 --> 01:03:43.005
I would have done it like this, why are you doing it not like this?

01:03:43.005 --> 01:03:46.684
So yeah, definitely, it's a conversation, I think.

01:03:47.628 --> 01:03:48.050
That's good.

01:03:48.050 --> 01:03:52.130
When I used to do implementations, I used to always ask why.

01:03:52.130 --> 01:03:54.101
When I was going to requirements gatherings, I used to always ask why.

01:03:54.101 --> 01:03:55.844
Or when I was going to requirements gatherings, I used to always ask people why.

01:03:55.844 --> 01:03:57.947
And that was the toughest thing and people sometimes would get annoyed.

01:03:57.947 --> 01:03:59.070
It says, why do you do it this way?

01:03:59.070 --> 01:03:59.871
Why do you do it that way?

01:03:59.871 --> 01:04:02.715
It wasn't a why, because I thought it was wrong.

01:04:02.715 --> 01:04:06.425
It was a why?

01:04:06.485 --> 01:04:17.922
to get a better understanding of what they're doing and why they're doing it this way, you know, can you validate it a lot.

01:04:17.922 --> 01:04:18.726
So it's, it is good.

01:04:18.726 --> 01:04:20.733
I think that we all do have the same you know intentions, which is good.

01:04:20.733 --> 01:04:21.476
Uh, which is one thing I really like.

01:04:21.476 --> 01:04:21.717
I know this.

01:04:21.717 --> 01:04:24.684
This business, central nav, the vision community, has been my life.

01:04:24.684 --> 01:04:49.349
You know, it's a lot different as a now than it was 300 years ago, but now it seems that everybody works really well together and everybody's striving to help each other out, just to lift the product up, because you know, rise and tides raise off ship and we have a bunch of passionate individuals in the community that want everything to work well and you know be, I guess you could say the best it could be, to use that loosely.

01:04:49.349 --> 01:04:55.329
So with that, stefan, natalie, thank you very much for taking the time to speak with us today.

01:04:55.329 --> 01:04:56.239
I appreciate both of your time.

01:04:56.239 --> 01:04:58.159
I appreciate the conversation, appreciate your insight.

01:04:58.440 --> 01:05:01.550
I could literally talk for hours about this.

01:05:01.550 --> 01:05:08.739
We could go down so many different paths with this, but I've been enlightened and learned a lot from the conversation.

01:05:08.739 --> 01:05:10.045
I have a few things I want to do.

01:05:10.045 --> 01:05:12.000
I will definitely put back that spelling.

01:05:12.000 --> 01:05:14.465
I've seen so many people use it and I've never used it.

01:05:14.465 --> 01:05:17.472
And now, as you had mentioned, how could I have survived without it?

01:05:17.472 --> 01:05:17.882
I don't know.

01:05:17.882 --> 01:05:24.204
I'm going to probably put it back because, even with you know, my eyes are getting worse and worse too, so sometimes I miss that.

01:05:24.204 --> 01:05:27.740
But again, thank you for the conversation, thank you for your time.

01:05:27.740 --> 01:05:28.402
We appreciate it.

01:05:28.402 --> 01:05:43.360
If someone would like to get in contact with you to learn more about what you do uh, talk more about um code reviews, clean code or even any other rules or practices how can they get into contact with you, stefan?

01:05:44.844 --> 01:05:48.831
um, probably best would be over twitter, or x like it's called today.

01:05:48.831 --> 01:05:52.344
Um, I think I'm accepting messages right away.

01:05:52.344 --> 01:05:56.277
Otherwise, just post a tweet and ping me and I will respond for sure.

01:05:56.998 --> 01:06:01.751
Excellent, we'll put a link in the show notes to your ex Twitter handle.

01:06:01.751 --> 01:06:06.952
I'll keep calling it Twitter for, I think, for the rest of the time that it exists.

01:06:06.952 --> 01:06:08.846
And, natalie, how about yourself?

01:06:09.800 --> 01:06:10.664
Very same for me.

01:06:10.664 --> 01:06:20.090
So I'm very active on my Twitter or X profile and you can also drop me a private message, I think, and if not, at least a public post, and I will easily pick it up.

01:06:20.090 --> 01:06:26.936
If you're a partner and you're on the partner network on Yammer or Viva Engage, you can also reach me there.

01:06:28.519 --> 01:06:29.342
Perfect, thank you.

01:06:29.342 --> 01:06:30.744
Thank you both again for your time.

01:06:30.744 --> 01:06:32.708
We appreciate it, I look forward to talking with you soon.

01:06:32.708 --> 01:06:34.653
Ciao, ciao, bye.

01:06:34.653 --> 01:06:43.989
Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.

01:06:44.260 --> 01:06:45.766
Thank you, brad, for your time.

01:06:45.766 --> 01:06:49.230
It is a wonderful episode of Dynamics Corner Chair.

01:06:49.230 --> 01:06:52.730
I would also like to thank our guests for joining us.

01:06:52.730 --> 01:06:55.768
Thank you for all of our listeners tuning in as well.

01:06:55.768 --> 01:07:10.293
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.

01:07:10.293 --> 01:07:23.704
You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I O, and my Twitter handle is matalino16.

01:07:23.704 --> 01:07:27.333
And you can see those links down below in the show notes.

01:07:27.333 --> 01:07:28.704
Again, thank you everyone.

01:07:28.704 --> 01:07:30.248
Thank you and take care.