Question Why Navision’s source code does not have any comments ??? Ans:- Navision want to keep only those programmers who can understand the codes without any comments.!!! Regards Joseph Mathew Edited by - joseph_mathew on 2001 Jul 31 16:40:04
No comments means that fin.exe can read through the lines much quicker!! You do have to understand the code to program Navision, once you have been reading the code for a while it is very easy to understand, because of the consistancy of the code. How much code does your end user licence allow you access to. David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Edited by - David Cox on 2001 Jul 31 22:55:05
Hi From the 9 years of experience in IT field I come to knew that it is good practice to give comments to the codes so that it will help the programmers those maintaining the code further. From navision also I expect this as it gives an item ‘Documentation’ in all objects code window. End user licence allow to view and change the codes of all reports and dataports. It can be seen that some reports having more than 1300 lines of codes.I don’t know how many are agree with me that more than 1300 lines of codes without any comments is not a good practice at all. Regards Joseph Mathew
Hi, even if a report has 1300 lines, if you do not understand the code, you do not understand what Navision (the software) is doing and you SHOULD not modify it then. You have thousands relations within the code and between the tables. And as a Navision developer you should know what the product is doing at that stage. Navision is NOT an access database where everyone can try his/hers basic knowledge in programming. Navision is a high tech product. In my opinion, there are still too much possibilities right now with a report designer to change the functionallity of Navision. The code is, beleive me, very easy to understand. So we do not need any (more) comments in the code. Best regards Walter
As a general comment to the standard code in Navision, then I agree fully. “So we do not need any (more) comments in the code.” But when it comes to add-ons and especially modifications, then it comments are appriciated. Best regards, Erik P. Ernst, webmaster Navision Online User Group
Hi My comments on the ‘Navision commnets’ is only general. I agree fully with Erik. It is not necessary to give comments in the standard navision. But as stated by him comments should be there for modifications and Add-ons. That is the thing we are lacking here. In our case there are lot of modifications are done by 2 NSC’s on different times. But these codes are not commented well. Another thing that I have noticed is that the naming convensions of both these NSC’s are not same in all the case. Walter Kreutzner says
quote:
even if a report has 1300 lines, if you do not understand the code, you do not understand what Navision (the software) is doing and you SHOULD not modify it then.
even if it has thousands of lines code, we can understand it well . However, if we put some comments it increase the readbility of the code. Regards Joseph Mathew
I’m so happy that there are some many genius programmers on this forum. I for one have trouble understanding the STANDARD Navision code and have spent hours pouring over the core posting functions trying to figure out what is going on. Comments would have been very helpful and if well written would have saved me many hours of unnecessary work. It is fine to say that if you know what you are doing you don’t need comments, but I find that I am constantly learning and that WELL WRITTEN (not necessarily verbose) comments are very helpful to speed that process. Navision code tends to be rather MONOLITHIC in that there are not short functions that are well partitioned. Sometimes it seems that you need to understand EVERYHING in order to understand ANYTHING. If Navision was truly written so that everything was obvious, it would probably not be able to handle the complex business requirements that it does. The more self documenting the code, the better, but that is not always possible. Complex business requirements often require complex code. And comments help. Perhaps the problem is that need to translate all the comments into other languages? Jim Hollcraft NCSD, NCSP, MCSE, CNE, MCP, MST aka Skater http://drilldot.com Unauthorized Navision News
quote:
Originally posted by Jim Hollcraft: I for one have trouble understanding the STANDARD Navision code and have spent hours pouring over the core posting functions trying to figure out what is going on.
Hi Jim, That’s why you’re a manager and we are developers/programmers . I actually think that most of the standard code in Financials is pretty obvious and if you know one area (i.e. Customer), then you can learn the other areas (i.e. Vendor, Item). Where it starts to get difficult is when Attain is out everywhere. Then suddenly, even when you sell a standard version, you have to learn and think about the Distribution and Manufacturing code as well. On top of that add the advanced features of the Payroll and Fixed Assets. Then you actually have a pretty complex system, where even I sometimes would like to see more comments. The “problem” also that all these advanced systems (Distribution, Manufacturing, Payroll, Fixed Assets) are not made by Navision A/S, but by NDP’s. Everything done by Navision A/S is more or less simply. I still love their old slogan: The beauty of simplicity. Best regards, Erik P. Ernst, webmaster Navision Online User Group
Atleast with Attain the Manufacturing and Distribution code has been rewritten so it all merged together and removed a lot of the mess (esp with Disitribution). Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
As a programmer for almost 40 years, Navision for 5 years, I agree with Jim Hollcraft. More comments would be good. This is especially appropriate when you consider that part of Navison’s basic philosophy is that the product will generally be modified in the field. That means there are hundreds (thousands?) of us that must learn the code. Any time that could be saved in that process will be multiplied by how many of us are affected. As an alternative, it would be very helpful there were technical documentation available describing various “standard” code structures and sharing the specifications to which various applications were developed. Without these, we can sometimes only guess what the intention was or whether the particular feature we are looking at may apply only in some other country or accounting environment than the one in which we, as an individual, are working. I would find more documentation, well written in a concise form, very welcome. - One man’s opinion. Dave Studebaker das@libertyforever
There is actually one very good reason for omitting comments from the code. When Navision is to make 25 or more different language versions, the comments will have to be translated as well. This takes time, and in addition the translation is not made by programmers. However, maybe when be switch to english codebase in Attain this will be different. Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
I guess Jim Hollcraft is a lucky man if he only (quote): spent hours pouring over the core posting functions trying to figure out what is going on I quess I have already spent weeks overt the last 5 years. And I definitely would wish more documentation in cu21, 80 etc. When I started with NF, my biggest mistake was that I invented functions and procedures which had already existed in the standard. I simply couldn’t find them (or didn’t search long enough). Talking about the standard code I would wish for the following documentation
- Purpose of the object. Especially for Reports: What does this report tell me?
- List of functions and what they do (this documentation could also be in a external file)
- Within the Code, short description explaining complicated code sequences.
- Description of usage of variables, especially if flags are being used in Reports: What is the meaning of this flag, when is it initialized and when is it being used.
The language is not the problem. I’ve never met a programmer who doesn’t understand english. But nevertheless the time saved by developers understanding the code would be much higher than the time needed by the NTR to translate the documentation. ------- With best regards from Switzerland Marcus Fabian (wonder: Will I get another star with then next post?) Edited by - fabian on 2001 Aug 10 03:33:50
my 2 cents/pennies/pence… Commenting in Navision has always been a long running battle. Navision code it self, is self-documenting, so there is no need for specifically documenting the code. The issue in fact is not the code, but the functionality. As Erik pointed out, in the days when “Navision was written by Navision” there were strict standards, and it was easy to follow what the purpose of the code was. Unfortunately as the functionality got more complex, so came the need for proper comments. To compound this is the debugger ("…what debugger I hear you cry…") well in the days when Navision had a debugger, (who remembers that), it was very easy to find what the code was doing, if you got an error in running Navision (e.g. You do not have sugfficient Qty. on Stock …" etc) the debugger would jump to the line of code. Now the product is vastly more complex, and there is no debugger. So maybe it is time for Navision to have more comments so that we can see what the code is actually doing. The other option would be a map of the functionality and procedure calls in Navision, but I can not see that happening. We talk a lot of the necessity of comments in Add-Ons, and I think everyone agrees on this, it is difficult to do upgrades and maintainence otherwise, but I tend to be in agreement with the direction of more clear comments, at least to let us know where the code is heading (eg, why is this procedure about to be called), or at least an external document, outlining the key issues relevant to that particular version. My last point, is that those of us that survived the DOS/Windows transition, we learnt so much before we even startd, that it is all obvious. I still remember those days, and do not see that this current generation need the same problem.
Just today I had a small private discussion about this topic with Dave Studebaker and came to the conclusion that rather than having the code itselfes documented it might be helpful for new developers to have some guidelines on standard problems. Example: If you have a new field inserted in T37 which you want to be migrated to T32, and the posted lines T111, T113, T115: Which tables and codeunits do you have to touch and which routines have to be modified to have the new field being migrated to all these tables? It takes a hell lot of time for a new developer to find out that he has to add this field also to T83 in order to be migrated. It would therefore be helpful to have a description how the posting of sold items has been implemented etc. ------- With best regards from Switzerland Marcus Fabian
Hi Marcus, I agree that this is a good aproach to this problem. My solution to this has been to create a transfer fields function. (Those that remember 3.53 will remember this). What I do is create a number of transfer functions in Table 81 and 83. E.g. in 83 I create a function to transfer fields from tables 36, 37 etc. then functions to transfer to tables 32 and others as required. Then new developers are able to make modifications, transfer fields, etc, and a more senior developer is easily able to check that the logic works. It also makes it very easy when you later add more fields. If anyone is interested, I can forward the code.
Even if this topic seems rather “closed” a short comment on Marcus post. I appreciated a lot while learning Navision and programming the first customizations the "flow charts" that describe the relation between the tables and the respective codeunits for each module. In the beginning, I got them on paper during my C/Side course, later on I managed to find them in a pdf file. I dont know where you can get them, I guess every NTR should have them, otherwise I can send you the version I have (quite old though). Nils
It would be great to have this pdf in the download area!! ------- With best regards from Switzerland Marcus Fabian
Good point, I will put it in the upload area the next days. CHeers Nils
Sorry to ask the obvious but : Why on earth this kind of documentation is not given by Navision to all the Solution Developer licence holders ???
quote:
Originally posted by nilsm: I appreciated a lot while learning Navision and programming the first customizations the “flow charts” that describe the relation between the tables and the respective codeunits for each module. In the beginning, I got them on paper during my C/Side course, later on I managed to find them in a pdf file. I don`t know where you can get them, I guess every NTR should have them, otherwise I can send you the version I have (quite old though). Nils
_________________________________ Tarek Demiati Freelance Navision Developer Email : tarek_demiati@ureach.com Telephone : +65 - 906 787 16 _________________________________Edited by - Tarek Demiati on 2001 Sep 06 11:02:17
quote:
Why on earth this kind of documentation is not given by Navision to all the Solution Developer licence holders ???
Reminds me my very first call to my NTR on day 1 after having received the Navision CD and Documentation: “I can’t find the flow chart and Entity Relationship Diagrams. Where are they?” ------- With best regards from Switzerland Marcus Fabian