Happy New Year everyone, with a little delay. I was busy in the first two weeks of this year preparing and delivering the “Leveraging Git” webinar. It turned out to be quite a success, but it also prevented me from doing my live session last Friday.
But this short break doesn’t mean I am not going to get busy with my blog and live blog again. This is what’s coming up.
(more…)
It's been a few days that I announced the "Leveraging Git" webinar on my Twitter and LinkedIn and I hope nobody will mind if I announce it on my blog.…
Source code files are living things. We add new ones and change their content on daily basis. Occasionally we delete them, too. Git is amazingly efficient when it comes to tracking these kinds of changes.
However, sometimes we need to change the file name, or file path, or both. And if you are an AL developer who has ever transformed a C/AL project into AL, you have probably done this at least once, for all .al files in the project.
And this is where git may surprise you. After you rename a file, sometimes you’ll notice that git detects it as a rename. But on other occasions it will not be the case.
Let’s dive in.
(more…)
One of good practices of writing C/AL Code for Microsoft Dynamics NAV since the dawn of civilization was annotating (commenting) code changes. If you are not sure what I mean by that, this is what I am talking about:
While standards varied about > vs +, or < vs -, or what the annotations should include, there was absolute consensus that annotating changes is an absolute must.
And it was a must. It was such an important rule that everyone followed it without questions asked. In my career, I’ve seen one or two situations of somebody changing or deleting a line of code without leaving any comment, and I’ve seen quite a lot of code, believe you me. It was that important.
It was that important in fact that it was one of the first things developers learned when they signed up for the job, and it was one of the rules they all followed from their first day.