CompGeek (Arjan van de Logt) has been around in the Dynamics world for quite some time. So like many of us he's got enough "powder to fire a gun". But as modest as he is never wanted, needed, could, ... Luckily he "finally" found a good reason to start writing: "... write about subjects I had to figure out but also about subjects I bump into and which I think might be interesting to other people."
Reading the posts, ComGeek has been writing sofar, I know I will turn to them in some near future as these typically contain info on tasks I have to do infrequently and thus will not recall all details.
Go and read and judge for yourself.
Keep it rolling CompGeek!
Building numerous of pages I ran into this issue already ages ago. Because of that I had registered the issue on msconnect asking Microsoft to fix this.
Already on August 26, 2011 (!) Microsoft - by means of Stuart Glasson - answered that it had been fixed in NAV 7.
But NAV 2013 was released, and we know NAV 2013 R2 en NAV 2015 also were, but still the issue is there. o I have created a new entry for it and go there and give your vote.
Browsing through msconnect I stumbled across one of my entries: Remove COMMIT from a number of Codeunits. A perfect member of my Cleanup series. Small, but as we started to "clean up" let's pick up this one too.
If you agree go there and give your vote.
Last year was the year of (the release of) NAV 2015. A major new release bringing NAV another step forward. As before it was presented at a number of events of which I did attend a significant number. Directions US, Dutch Dynamics Community, Directions EMEA and NAV TechDays. And apart from the major part of the content they all had one striking thing in common.
Now picture yourself sitting in those rooms at these events, where various speakers are delivering their well prepared presentation. Envision what they are presenting and how the audience is reacting to that. Enthusiasm? Disappointment? Annoyance? Amazement? Or as diverse that all these emotions show up at the same time ... I recon Microsoft was quite happy with the positive (I even think enthusiastic) reception that they got for the tablet client. Surely given the effort they have put in it and the goal they want to achieve. And maybe some more other new features.
Thinking however of this one, I guess this was unexpected and ... inexpensive. If the sound level of the applause would have been measured, it by far would be number 1. And it was exactly the same on all 4 conferences. Whether Dmitry Chadayev showed it in between all the more sophisticated technical feature during the key note sessions in San Diego; or Arend-Jan Kauffmann demoed it at the Dutch Dynamic Community event in Nuland; Stuart Glasson mentioning it shortly during a O365 integration session in Poznan; or, who was it, did the same in Antwerp. In all cases the Comment and Uncomment Selection feature did rouse the audience. It surely made me laugh.
But to be honest, it also made me somewhat disappointed. As IMHO it is not complete. Surely it's great that we can (un)comment a block of code in one action and not having to use the curly brackets to do this efficiently. But I hardly uncomment blocks of code temporarily. However I do it frequently when replacing/removing existing code by new code, like in this small example:
But the Comment and Uncomment Selection feature does not support this as comment slashes are always added at the start of a line, i.e. on the first position, and not related to the indentation of the lines being commented.
So I suggest to have v2.0 for the Comment and Uncomment Selection feature by means of a setting on the Options:
Comment and Uncomment Selection – 2.0 will allow you to comment code as is now possible in NAV 2015, i.e. Comment Selection=Normal. Or (new) it will allow you to comment code in such a way that the slashes are put a the most left indentation position of the selected lines, i.e. Comment Selection=Indented.
If you agree please go to my msconnect entry and vote for it.
Did you read Soren's last post? You should as it contains a worthwhile standpoint regarding commenting code. And it's down right clear that Soren abhors commenting code. Even that much that he doesn't allow me putting a comment to his post!
So here I am ending up on my own blog with a comment on comments that are considered evil.
... SQUARE(Evil) ...
Here I go ...
I cannot but support your standpoint. Indeed we should all write clear code that needs no comments. It makes it much easier to create, understand and maintain. The funny thing is that we - NAV developers as a group - keep on generating unreadable code; for ages already. And not only those "out in the field", also at Microsoft. Just have a look a codeunit 80. Even printing the darn OnRun code gives you a fifty pager that will keep you busy for a good number of hours to unravel. Facing that fact we could recon ourselves happy with the comment lines provided here, even if they are "evil".
So as you validly say "we should try to do better". I would have left out "try". We should do better. Simply because we will profit from it and, even more down-to-earth, because we all are paid for it. And as we both know, it's not that hard. And we are even helped with it. By the Design Patterns project. By the PRS clan. By Design Pattern videos. By Mark Brummel's posts, like this one on Natural Language Programming (which by the way also declares comments as evil).
And it's good to know that these are not voices shouting in the wilderness as people are picking this up. Standard NAV code is improving. A vast number of people are watching the videos and attending related presentations. Etc.
As said, I cannot but support your standpoint ... in principle.
Yes, I want my code to by minimal and clear. It should not do things that is not asked for. It should not have any artifacts that are redundant, unneeded, etc. And yes, a source management system like Team Foundation Server (TFS) indeed supports me (and you) in this. But ...
... I also want to do my work as efficient and effective as possible. And that's why we use comments, i.e. code markers, to our code when modifying existing code objects. Like most of us do, I know. Comparable to what we did for local features in standard NAV.
This allows me, looking at the C/AL code,
... to have a quick insight in what changes have been implemented over time. True, TFS will also help me to get this insight, but not in one glance. So I need to do extra actions to get to the same point of understanding.
..., as a developer, to straight forward pinpoint the faulty code change that underlies the error when I am debugging.
..., as a tester, to determine the scope of my white-box testing. What part of the code do I need to take into account in my (new) tests.
..., as a (feature) code integrator, to perform cherry pick merges. For this we even assured that each added field or page control will have a reference to the related TFS work item in the Description property.
I hear you thinking: "Luc, you can do better."
Maybe you're right and I am to old to change our practice. Or maybe I am just afraid of change, not daring enough. However, using these practices - our best practices, I dare to say - our work has been profiting from it, and still does.
Your fellow in TFS arms, Luc van Vugt
As Soren states he has "... heard all the arguments ..., but it doesn't change my view that COMMENTS ARE EVIL", making my exercise without any chance to change his mind, of course.
Nevertheless I just wanted to give my two cents on this even if that leaves me somewhat evil.