Navision naming conventions

Shenpen · 2005-06-16

"Huh ? Ever looked at CU80?"

Can't even count the times I hacked it, so often it happened

Yes, IMHO it is short. Shorter than Linux kernel code

Just kidding

Because it is well divided into parts. If I am interested into creating a Posted Sales Invoice, I search for it and then have to look at not too much code.

But what does CU80 relate to us? We NSC may customize it, but never create a new CU 80, unless we are really stupid.

The important thing is: MBS writes code to the whole world, we write code to a company. So is really short. Unless we want to create an add-on - pity the poor guys who tried it. Maybe in Western Europe it works. In Eastern Europe you cannot sell an add-on on, because f.e. the customer wants to have a background color of black and foreground color of white becaue their old DOS software had it this way - you can do it in Navision but you cannot do it in an add-on because the add-on object range you cannot customize, because it is owned by another NSC. And then the project fails.

kine · 2005-06-17

But it does not mean, that your job is good job, it is only job which was done. May be that if someone with 3 and more years experiences look at your code, it will say "holly s..t, what did you done with the posting rutines?" etc. But may be it say "hmmm, very nice solution. And you did it in 3 months?" I know many customized Navisions which was customized in 3 months by begginers, and it was terrible... it ends with new implementation for the customer, because the state is not possible to maintain and support...

There are differences between NSC which are working on Navision more than xx years and the NSC which are beginning with Navision... in many situations it will take few dissatisfied customers to be able to do the work in a good way... everyone is learning from mistakes... And it is why there is the forum - because only fool is learning from own mistakes... ;-)

eromein · 2005-06-17

I’m done…

To bad so many people think post and pre fixes are a good idea. I really hope I’ll never need to convert a database from you guys…

Oooh wait… I did ones. Convert a database from 2.00 to 3.60 from a developer that uses pre and post fixes… I had two options re-program everything or kill myself. I choose the first one. Should have been the other one.

Maybe I need to change my quote to something like:

"Standard Navision is our believe, the guidelines out bible! Please don’t develop on Sunday!".

kine · 2005-06-17

Eromain, I do not like the prefixes and postfixes too :-)

But I know that other people like them, there are PRO and CONS and it is on the company which rules they are using. For me (I am "programming" since my 8 - it is something about 19 years ago... basic, pascal, asm, C, C++, Navision etc.) it is something I never needed, I can read code fast without it and I am too lazy to use prefixes (because I do not need them) - I am trying to write the code in the way that others which will modify my code do not need the prefixes to understand the code.

But in case, when the code create someone which need them (there are more reason why) it is better to use them than write unreadable code...

From my aesthetical point of view I think that w/o prefixes the C/AL code look better... but I think that there are other opinions and I say:

both ways ("standard Navision" and "pre/postfixes") are GOOD if they are used properly, clearly described, easy to learn and easy to use.

There is no way how to use uniform form on whole world, because each person developing in Navision is unique and each need another tools to do his job... it is on him to choose the form, because each have PRO and CONS...

jesam · 2005-06-17

I'm done too ...
As usual, most of you stepped around the hot potatoe.

In fact, I'll give it a last shot.

Shenpen (about CU80) :

Yes, IMHO it is short.

The OnRun trigger of my CU80 counts 2472 lines. If you call that short, well I don't know what you call long. It could have been divided into many little sub prcedures.
It contains 133 Global Variables, now, that is some mess. One of the reasons there are so many Global Variables is plain lazyness (or incompetence) of the original coders. Most of the variables could have been locals to the OnRun trigger, and if that OnRun trigger had been split in lots of small sub procedures, I guess we could have transformed at least 100 of the 133 Global Variables into Local Variables, thus eliminating a lot of maintenance problems. If all those sub procedures would use the actual/formal parameter mechanism to indicate which piece of code changes which variables, we would go up again a few percentages on the quality scale.
Given the code as it is, if they had used pre- and or postfixes, at least it would be clear what the scope and the type of those 133 variables was. I'll state it one last time, if you're dealing with this kind of code, you're better of having pre- and postfixes. Nobody can look at code and remember 133 variable definitions, so if you see some variable, you'll never know how it was defined without looking at the definition.

I just wish that all you guys who don't see the problem with this would do me a favor. The next time you meet somebody that has an IT degree, present them the code of CU80 and ask them what they think of it. If you would happen to know someone who teaches IT, let them see CU80 and ask them what grade a student would get if he/she writes code like that. Maybe that will open your eyes.

Naming conventions are not a goal by themselves, they are a means to give better quality to the code in absence of a tool that can give you the missing information easily. With the current quality of the Navision code, and the current quality of the editor, we would be better of having pre- and postfixes.

kine · 2005-06-17

About the CU80 (90, 12 etc...):

This all is the hystorical thing... it is the CORE of the Navision, and nobody want to rewrite it from scratch because "it is working" (somehow)...

Navision is for me big Dino... the Dino is working well, but the skelleton, size etc. are not good... but it is still working...

It is the reason why project Green was started and the solution is some new product based on the Navision good properties, with new technology etc...

If you try to rewrite the CU80 you will have speed and memory problems, because you will still pass many parameters between small functions. Yes, it will be clear code, bud slow (many transfers between stack etc.)... and do not forget that you can pass only 20 parameters to function (and you have limited stack)... I assume that you will need more in the CU 80 - it is why the global variables are used in Navision everywhere... do not forget that the global variables are something like Attributes in OOP... You do not have all variables in methods in OOP...

And do not forget - the editor is better than in 3.10... debugger too... you have info about variable type now fast accessible... there is only Local/Global flag missing yet but it can be changed... Did you ever post some Suggestion to the Microsoft? No? Than keep quiet - because how you want to make something better if you only complain? Be constructive, write what you need to be Navision better, but do not forget the limits of Navision technology and do not write that you want same editor as in Visual Studio... it is not possible made it in this technology... Think about small help tools, which can helpp much better than super cool IDE...

HOWGH...
(I thing that there are my logest answers I ever wrote in english...)

jesam · 2005-06-17

If you try to rewrite the CU80 you will have speed and memory problems, because you will still pass many parameters between small functions.

Come on, first of all we are workign with Pentium 4 processors nowadays. Second, my other rmajor project is written in VB.NET, but that enironment doesn't seem to have memory and performance problems. I don't know how things are internally in Naviosn, but in .NET everything except integers, decimals and structs are reference types (not 100% correct, but it will do) and thus passign them around is no more than handing of a pointer. Formal/Actual parameters are in fact just coding structures that make it possible for the compiler to check things on code level. How it is compiled to machine languages (or P code or IL or ...) doesn't have to have anything to do with it.

Yes, it will be clear code, bud slow (many transfers between stack etc.)...

This shows that you may be a good Navision coder/consultant, but that you really don't know much about modern systems design.

and do not forget that you can pass only 20 parameters to function (and you have limited stack)...

If you need to pass 20 parameters to a function it shows that you have a design problem. Off course, in Navision you can't really defined classes, so again we have a coding style that is forced upon us because of the omisions in the native Navision Development Language.

I assume that you will need more in the CU 80 - it is why the global variables are used in Navision everywhere... do not forget that the global variables are something like Attributes in OOP... You do not have all variables in methods in OOP...

Attibutes to me are the little things you use to decorate your methods, like [WebMethod].
If you mean to say classes, than still I would'nt need them to be global. There is only one reason to make something global and that is if inside an object you need to keep state between method calls. And then it is only global with respect to the class/object.

And do not forget - the editor is better than in 3.10... debugger too...

Way to go. The only problem is that because our NSC was so skilled they changed code all over the place without documentation, so an upgrade would cost us maybe like a year to get it all right (we would be better of starting from scratch if you ask me).
We could do an upgrade of Navision itself and stay with the code we have now, but none of us dares to take responsibility to go ahead and do that.
Plus, that would cost us money and the only reason we could give to the managment for doing that would be so that we can debug better. I don't really think they would understand that.

Did you ever post some Suggestion to the Microsoft?

No, they are not going to bring out another 3.1 with a better debugger, so we ware stuck with this mess forever. I don't see them rewritign stuff too, because as you say, they are busy with project Green. Unfortunately, that is still several years away.
Anyway, I think the aquisition of Navision by MS was a mistake, they bought a real mess that they cannot sort out, but anytime somebody complains about that mess, they get blamed for it.

Last of all, this is not personal against any of you. It is just that I feel there are a lot of things wrong with Navision, and most of you don't see it or don't want to see it. I understand that, the current state of the affairs guarantees prety much that NSCs are needed, and most of you work for one, but to me as a developer that works for an end consumer that doesn't want to use an NSC again because teh relly messed up, this is a daily struggle with a sub-par product that we know almost nothing about, that has virtually no documentation, but that we nevertheless need to keep running.
In the meantime, my other project (in VB.NET) shows me every day what is missing in Navision. It gets kind of frustrating.
Pre- and Postfixes and a good naming convention are just something that could compensate for missing functionality in Navision, nothing more, nothing less. Are they ugly ? Yes. Do they make code harder to read ? Yes. Do they help in making correcter code ? In the case of Navision, yes.

kine · 2005-06-17

jesam wrote:

Come on, first of all we are workign with Pentium 4 processors nowadays.

Ok, but NOW I am working on optimalization project for our customer, because it is SLOW (the server is OK...) and we are hunting each millisecond, because if you call something 500x in loop, and you gain 0.03s, you have gain 15seconds... and if you call this loop in another loop (500 lines of document, 100 documents in one batch)...

Second, my other rmajor project is written in VB.NET, but that enironment doesn't seem to have memory and performance problems. I don't know how things are internally in Naviosn, but in .NET everything except integers, decimals and structs are reference types (not 100% correct, but it will do) and thus passign them around is no more than handing of a pointer. Formal/Actual parameters are in fact just coding structures that make it possible for the compiler to check things on code level. How it is compiled to machine languages (or P code or IL or ...) doesn't have to have anything to do with it.

Yes, but please, do not compare VB.NET with Navision C/SIDE... C/SIDE is something what was created a long time ago (that is why it is Dino for me). There are not pointers, values are passed as values, there are buffers into which are values inserted... only in parameters passed as referrence the referrence is passed...

This shows that you may be a good Navision coder/consultant, but that you really don't know much about modern systems design.

I know many things, but I know, that Navision is not modern system... please, do not forget this...

If you need to pass 20 parameters to a function it shows that you have a design problem. Off course, in Navision you can't really defined classes, so again we have a coding style that is forced upon us because of the omisions in the native Navision Development Language.

it is not omissions, it is just Navision - is is not Object Pascal, it is C/SIDE...

Attibutes to me are the little things you use to decorate your methods, like [WebMethod].
If you mean to say classes, than still I would'nt need them to be global. There is only one reason to make something global and that is if inside an object you need to keep state between method calls. And then it is only global with respect to the class/object.

Each class have:
Attributes (properties)
Methods
and inheritance

Type of attribute is another class... (if you take integer etc. as classes too)
Attributes describe the state of the created object...

The Codeunit is Class (if you make variable of type codeunit you get object), this class have Attributes (global variables - all are privat, no public atributes are possible in C/AL). If the state of the object is complex, you need many attributes to describe it - it is why there are many global variables in C/AL...

You can split only code, which is possible to run independantly of the rest of code and have simple interface... it is why you cannot split the big code of posting, because it is too complex to say - this can be splitted, there is simple interface and it is independent on the rest...

Do not forget, that Navision has some history, it means that at the beginning was the posting rutine simple... but there are many functionality added and it wrap around the code and got bigger and bigger... And it is not easy to keep one code readable through years of developing... there is point, when you must take the rutines and rewrite them from scratch... and we are nearly this point...

Way to go. The only problem is that because our NSC was so skilled they changed code all over the place without documentation, so an upgrade would cost us maybe like a year to get it all right (we would be better of starting from scratch if you ask me).
We could do an upgrade of Navision itself and stay with the code we have now, but none of us dares to take responsibility to go ahead and do that.
Plus, that would cost us money and the only reason we could give to the managment for doing that would be so that we can debug better. I don't really think they would understand that.
No, they are not going to bring out another 3.1 with a better debugger, so we ware stuck with this mess forever. I don't see them rewritign stuff too, because as you say, they are busy with project Green. Unfortunately, that is still several years away.

Sorry, but if you pay your maintenance fees, you can use NA 4.00 C/SIDE now, without any intensive upgrade - it is called C/SIDE upgrade (or technical upgrade) - you only change the client and server (if you are using Native DB) and it is done... and you have all new functionality of the newest C/SIDE version (not application)...

Anyway, I think the aquisition of Navision by MS was a mistake, they bought a real mess that they cannot sort out, but anytime somebody complains about that mess, they get blamed for it.

With one thing I must agree - after the aquisition some things go worse. But it is now better and better... but it is normal, when You overtake someone work, you need time to get into it and do it on same level as the creator...

And I must disagree - I am in contact with MS near every week. I never was blamed if I report some bug or error. And sometimes I wrote very displeased mails etc. Every time the people was trying to help me. Many times I must correct the error myself. But it is normal if you are working on such a big project as Navision itself. It is not possible to send every change to all users... or rewrite some process without long testing etc.

Last of all, this is not personal against any of you. It is just that I feel there are a lot of things wrong with Navision, and most of you don't see it or don't want to see it. I understand that, the current state of the affairs guarantees prety much that NSCs are needed, and most of you work for one, but to me as a developer that works for an end consumer that doesn't want to use an NSC again because teh relly messed up, this is a daily struggle with a sub-par product that we know almost nothing about, that has virtually no documentation, but that we nevertheless need to keep running.

I take it as another opinion and challenge to discuss... 8)

Yes, I know many project which the NSC messed up. In many cases it leads to new implementation... I am sad that you go into such a NSC. But there are still plenty of NSC which know their job very well. Do not blame NSC because they are trying to earn money on needs of others - it is business...

In the meantime, my other project (in VB.NET) shows me every day what is missing in Navision. It gets kind of frustrating.
Pre- and Postfixes and a good naming convention are just something that could compensate for missing functionality in Navision, nothing more, nothing less. Are they ugly ? Yes. Do they make code harder to read ? Yes. Do they help in making correcter code ? In the case of Navision, yes.

As I wrote before... you can use what you consider to be useful. Whole discussion to be about PRO and CONS of the conventions...

janpieter · 2005-06-17

Oops atributes are not properties ... don't confuse these.

Attributes are properties you can give to a propertie ... ehm what am i saying ? :roll:

kine · 2005-06-17

janpieter wrote:

Oops atributes are not properties ... don't confuse these.

Attributes are properties you can give to a propertie ... ehm what am i saying ? :roll:

Ok, sorry, I am not sure if I know exact english terminology... (it is "something like"...)... let it be only Attributes... :-#

jesam · 2005-06-17

If you need to pass 20 parameters to a function it shows that you have a design problem. Off course, in Navision you can't really defined classes, so again we have a coding style that is forced upon us because of the omisions in the native Navision Development Language.

it is not omissions, it is just Navision - is is not Object Pascal, it is C/SIDE...

Yes, and it's hopelessly inadequate in the year 2005 ...

The Codeunit is Class (if you make variable of type codeunit you get object), this class have Attributes (global variables - all are privat, no public atributes are possible in C/AL). If the state of the object is complex, you need many attributes to describe it - it is why there are many global variables in C/AL...

I've too tried to view a codeunit as a class, and indeed if you do that you need global variables to hold the state of the object, but not 133 of them. Even 33 would be a lot.
The highest cost of software is the maintenance cost. CU80 (among others) is virtually unmaintainable.

We do pay our maintenance fees, but as I said, none of us dares to take responsibility for a technical upgrade. I can't really believe that that is not going to cause problems.
Plus, we need to take the server down for that, and reinstall all the clients.

About the aquisition by MS I was nto very clear. I meant to say that MS constantly gets blamed here in these forums, not the one reporting a problem.

I also did not mean to say that all NSCs are bad, but its the same things as with the quality of Navision code. Nobody checks that code so as a customer you can not know teh quality. Nobody checks if NSCs do thier job like they should, so as a customer, you are at the mercy of faith. Our NSC promised to put our complete compnay (we produced knitted fabric) from Sales through production and accountancy to Delivery on Navision with an upload fo data from the old file-based UNIX system for 125 000 € and in a period of three months. MS should simply revoke the license of such NSCs.

DenSter · 2005-06-17

Alright I think we've discussed all we can about naming conventions, and sidestepping into another discussion about the (lack of) merits of C/SIDE. Is anybody interested in a new thread about that?

Shenpen · 2005-06-17

2 kine:

Yes, I myself also botched up the first project and then I realized then reason was I was not proctive enough - I tried to solve everything with standard functionality and customize only when I turned out not working. What I learned: to radically change functionality or even drop a standard granule and develop a better one is much shorter and easier, than trying to make users work with a software that has a very different way of thinking than they think.

Later on I helped other NSC on their first jobs and saw that they did the sames mistake: I call it "blind trust" - a blind trust in that if Navision has a functionality that is called a similar way to a customer request, it will work fine. So the basic beginner mistake is thinkig Navision is a solution and not a solution development environment. Everybody who has some experience with business applications, has a kind of healthy cynism: never, never belive any promise of a standard software, never think anything would work.

For example, this kind of Navision experience helped me in our internal MS CRM implementation - based on this healthy cynism, I made people accept things like

- we have to hire a .NET programmer to make a data import program, because I don't trust in migration tools like CDF

- we have to learn how to write reports in SQL because I do not trust in Crystal

And both was right. We ended up with a 400 lines import program, so it turned really impossible to migrate data otherwise, and have so bloody complicated SQL queries that also would have been impossible otherwise.

Actually 90% of my usual developments and 100% of the aforementioned ones would be unnecessary if users would be more flexible on accepting solutions. But why would they? For their money, the expect the software to serve them, not the other way around.

sqaguru · 2005-09-12

Hi Guys
I am doing testing for coding conventions and best practices in navision. So now era is closed when there was no inspection / testing for conformance to naming / commenting / best practices of coding.

I will appreciate if you people can help me to make it better.

philippegirod · 2006-09-13

Hello,

DenSter wrote:

I always declare most variables as globals, because that is the way that most standard Navision code is written. I only put 'loc' or 'par' prefixes in there if they are not global.

There is somewhere an advantage to have local variables : when you copy the function to antoher object or another database object, you copy in the same time all local elements (like variables and text variables). This is really easier.

But for all other things, i'm completely agree with you.

ara3n · 2006-09-13

In addition to that philippegirod, If you have your variable as local, is that youd don't have to worry about other functions or code using your variable to set filters that would cause problems with your code. Having them local gives me peace of mind.

Phenno · 2006-09-13

ara3n wrote:

In addition to that philippegirod, If you have your variable as local, is that youd don't have to worry about other functions or code using your variable to set filters that would cause problems with your code. Having them local gives me peace of mind.

yepp but, that is not standard programmer's thinking. You cannot presume that you var should not receive some value in any way. You have to asure that that doesn't happens in any situation.

janpieter · 2006-09-14

* hey my favorite topic alive again 8) *

ara3n wrote:

yepp but, that is not standard programmer's thinking. You cannot presume that you var should not receive some value in any way. You have to asure that that doesn't happens in any situation.

Not standard programmers thinking? You mean not the standard navision way? Many times i have seen the mistakes being made by programmers (moi including) using global variables. Many times the only reason this was done because it is faster to program. For me using globals is just not done unless you really need to store values between procedures and this cannot be solved by using parameters or performance related.

Phenno · 2006-09-14

janpieter wrote:

* hey my favorite topic alive again 8) *

ara3n wrote:

yepp but, that is not standard programmer's thinking. You cannot presume that you var should not receive some value in any way. You have to asure that that doesn't happens in any situation.

Not standard programmers thinking? You mean not the standard navision way? Many times i have seen the mistakes being made by programmers (moi including) using global variables. Many times the only reason this was done because it is faster to program. For me using globals is just not done unless you really need to store values between procedures and this cannot be solved by using parameters or performance related.

Maybe missunderstandig, I said a same thing

Programmers should not expect values of var. Instead of that, he/she should assure that var receives only valid values or, at least, assure good error catching if something tries to assing illegal value. Whether you are working in Navision or you're making something in .NET, principles are same.

DenSter · 2006-09-14

It's mostly a matter of personal style. I really do not agree that it would be a mistake to use global variables. If I'd write a codeunit that processes a Purchase Order, I will use a global variable for the header and one for the line. For all the setup variables, I use global variables. Only if I need to do something locally, like looking up the latest entry number, do I use local variables.

There really is no sense to me to nly use local variables. That way you'd have to add local header/line variables, PLUS the same type rec variables as parameters, and then you'd be retrieving all the setup information in each function. That just gets too complicated, and causes massive code redundancy, it has nothing to do with being a lazy programmer.

kine · 2006-09-14

It depend on the scale of modularity you want to have in your code. For example for me the limit of parameters for one function to max. 20 parameters is sometime too low and I have problems to create code which I will like. When you are using parameters and you define them as Var (passed by reference, not value), you do not need to get them again. For example as global variable is good to have the setup records (Inventory setup etc.), some global settings etc.

Phenno · 2006-09-14

Global vars should be used for global purposes.
Local vars should be used for local purposes.

That makes code to be more cleaner, more modular and easy adjustable, isn't it right?

But, ofcourse, everybody has their own habits and use-schemas for coding and algorithms and if application works ok, every kind of coding is acceptable

.

janpieter · 2006-09-14

Phenno wrote:

Global vars should be used for global purposes.
Local vars should be used for local purposes.

That makes code to be more cleaner, more modular and easy adjustable, isn't it right?

Ok i think we are on te same line but ...

Phenno wrote:

if application works ok, every kind of coding is acceptable .

... do you really think so? Isn't maintainability important?

Phenno · 2006-09-14

janpieter wrote:

Phenno wrote:

Global vars should be used for global purposes.
Local vars should be used for local purposes.

That makes code to be more cleaner, more modular and easy adjustable, isn't it right?

Ok i think we are on te same line but ...

Phenno wrote:

if application works ok, every kind of coding is acceptable .

... do you really think so? Isn't maintainability important?

Ofcourse it is but, there is no law that says "You must be carefull about maintainability". Everyone say "You should be carefull about maintainability" unless you want trouble later.

Which means, you can always sell not so well coded application but that workes well, and leave maintainance to somebody else

I'm not a fan of this options (We are on the same line) but lot of people works like this and from their point of view, it is ok.

DenSter · 2006-09-15

And again, that is personal style. How do you determine whether something is 'maintainable'?

Personally, I don't mind checking the Global variables when I upgrade an add-on version, I consider that part of the task. Other people hate that, they just want to be able to simply copy functions and be done with it. And even then... if a new version of an add-on has added locals, maintaining that can be really annoying, and having all variables as globals can save a lot of time.

What I think is more important than whether a variable is global or local is that code is well documented, and tagged, so you can identify it as part of an add-on or modification. I've started to group variables for the stuff that I do, and add dummy variables before it, like this:

StandardVariables
-- vars for My Mod --        integer
MySalesHeader     record    Sales Header
etcetera

So that if I need to move the code I can copy all vars at the same time, without having to worry if I got them all.

Phenno · 2006-09-15

I, simply, think that global vars are track-hard things. You have to add a code (that checks validity of values of that var) in each function that uses that var, and they consume memory unnessecarry. Ofcourse, I talk about situations where global var is not mandatory as global.

DenSter is right when he talk about Documentation but not everyone is disciplined enough to write every possible needed documentation and, cause of navision's not-so-standard development enviroment, I think there is a great possibility to find not so well documented code, even in your add-ons and modifications.

He is right in another thing => Indeed, every developer has its own approach/view to coding etics.

janpieter · 2006-09-15

Well, agreed, at least one thing is true whatever way of programming you use you will need discipline.

Use of prefixes, local vars, etc. also requires discipline to do this in a consitance way.

But for people working together it is important to use a generally accepted way of programming. And, whether you agree with this standard or not; not using it, i consider to be wrong.

I think in the end you will get to be used to any way of programming if you work with it long enough (hey i come from visual basic and learned c/al!) but i also believe that there is a generally best practice and i believe this best practice certainly applies for the local / global issue (unlike what standard navision code does).

Howdy, Stranger!

Quick Links

Categories

Navision naming conventions

Comments