Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 326 Dynamics CRM
- 110 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 994 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Navision naming conventions
DenSter
Member Posts: 8,307
I am really interested in this topic, and it started to pop up as an off-topic discussion in another thread. It's been discussed before and it wil be discussed again, but I felt like putting in my 2 cents :whistle:
I personally think that any naming convention is ok, as long as they are clear and as long as they are consistently used. That is the heart of the problem, every developer has their own little 'standard' and they all believe passionately in it. Personally I really don't care if a variable is called grecSalesLn or SalesLine, I get the jist of it by looking at the name, plus I check the scope anyway, I just think 'SalesLine' is a LOT more clear than 'grecSalesLn'.
At some point we had a developer conference and came up with a beautiful naming convention, for variables as well as function names and ways in which to comment code. We even created a form that would name variables for you with selectors for scope and type and everything. The problem was however, that after a short period of 'this is cool' nobody used them anymore, because it took away brainpower from solving the problem to thinking up a correct variable name, so it was nothing more than a brain excercise. It should probably be enforced by some sort of Q&A process, but who has the time for that nowadays if the program works right.
I don't think it is necessary to prefix a SalesLine variable with 'rec' because everybody knows it's a record type variable, but it also does not bother me when somebody does the prefix. Regardless of what anybody calls it, I STILL check the variable declaration when I am troubleshooting other people's code, to make sure I understand the scope of the variable.
You wouldn't believe the kind of crap I've seen, where a sales line variable was called SL3 or something, or where someone had copied some code for invoicing to apply to a shipping process, and forgot to rename the variable. You HAVE to check variable scope, no matter what you call it, so why clutter variable names for 'most used' cases.
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.
I personally think that any naming convention is ok, as long as they are clear and as long as they are consistently used. That is the heart of the problem, every developer has their own little 'standard' and they all believe passionately in it. Personally I really don't care if a variable is called grecSalesLn or SalesLine, I get the jist of it by looking at the name, plus I check the scope anyway, I just think 'SalesLine' is a LOT more clear than 'grecSalesLn'.
At some point we had a developer conference and came up with a beautiful naming convention, for variables as well as function names and ways in which to comment code. We even created a form that would name variables for you with selectors for scope and type and everything. The problem was however, that after a short period of 'this is cool' nobody used them anymore, because it took away brainpower from solving the problem to thinking up a correct variable name, so it was nothing more than a brain excercise. It should probably be enforced by some sort of Q&A process, but who has the time for that nowadays if the program works right.
I don't think it is necessary to prefix a SalesLine variable with 'rec' because everybody knows it's a record type variable, but it also does not bother me when somebody does the prefix. Regardless of what anybody calls it, I STILL check the variable declaration when I am troubleshooting other people's code, to make sure I understand the scope of the variable.
You wouldn't believe the kind of crap I've seen, where a sales line variable was called SL3 or something, or where someone had copied some code for invoicing to apply to a shipping process, and forgot to rename the variable. You HAVE to check variable scope, no matter what you call it, so why clutter variable names for 'most used' cases.
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.
0
Comments
It would also be nice if this property were visible in the symbol menu.
Some years ago I overlooked an "Item.deleteall" which was non-temporary...
It takes a little time to get use to but if you know the convention i think it does not take your mind of the problem and i think of it as a bad excuse. When i apply conventions (it took time too learn for me as well) this is an automatich thing just as giving direction when you change the lawn you are driving in on the high way (which is hard for people as well but only because they think it is not necesarry).
The biggest problem is that developers are not keen to learn them and i think this is a drawback in delivering professional coding where every developer uses his/her own style. (still not mad at me?)
Also i do think that local, global (and public for 4Gl languages) need a prefix, why are these conventions applied in other languages but not in Navision !?! Because - when you are used to them - they make code more readable. And prefix a variable with the type name i think of the same. So i definitly think that the prefix rec for a record var makes the code more readable. Only exception for me is fieldnames of a table they should be used according to navision standards.
Oh and using abbreviations for names is a big "NONO".
How do you convince people? Fire them if they don't apply to company policy :twisted: (just kiddin) (ough you must be mad at me now)
Oh and why not use navision standards? because - try reading navision code -.
Yep fuly aggreed with that and the rest of your post...
In my NSC, we have clearly define some rules that everybody SHOULD respect . Like you, prefix code to separate local, global, fields and parameters. Our experience demonstrates that this is the best solution. With that, we could also directly identify our customization ( + with Tags, of course).
We know that is not STD Navision. But Navision is the first who not respect the rules (cf local variables).
I think one of the most important things in live is speaking the same language. Not only reading and writing English but in other things as well. Like a traffic light, the blue, brown and yellow cables in electrical installations and much more other rules that are the same over the world.
I think it’s absolutely necessary for all Navision programmers in the world to use the same guide lines. Without this the end of the world is near, the apocalypse is coming, Mad Max flashes…
Now, we could make a new guide line right here, right now… But this is already done by people how really know this stuff. And they called it Navision. I refer to this before, maybe you remember.
I’m really astonished so many developers are using own, house made, rules. Impossible to believe… I’m sure I wasn’t the only one doing the Navision exam. How can it be I’m the only one actually applying the learned knowledge in practice?
Click this link to download the Navision Bible!
Btw, Navision code is perfecty readable. Perfect!
If it was hard to write, it should be hard to understand."
I agree, but as long as Navision has this stupid limit to the length of variablenames of fieldnames, there is no other solution.
And on the other subject of why people in Navision refuse to apply a uniform codeing convention, I think there are two main reasons :
1. The Standard Navision code (as said before) has no uniform coding convention (nor does it scope it's variables correctly). And the localized code for the various countries also has no uniform coding convention and doesn't scope it's avriables correctly either.
2. Most of the people coding in Navison are not informatician's but business people, and don't see the point in applying coding conventions.
If I install electricity in my own house, I could get it to work correctly without following all the conventions that an official craftsman would follow (off course my electricity would never pass the mandatory inspection, but that's another point, there is no mandatory inspection for NSC code). As long as the house is mine, I could maintain it and there would be no need for following the conventions. But when I sell the house, the owner after me would either have to find out how everything worked (and that would cost a lot of time if it were possible at all) or rewire the place, and all that just because I didn't see the point in following conventions.
Along with major technical shortcomings, this is one of my major gripes with Navision.
I think the fault is that Navision does not use conventions like 4GL tools. I think these conventions have been giving more thought then Navision conventions (just speaking about variable naming here).
I think everyone agrees we should use common conventions but most people also believe that this is not the way navision does it.
Oh yes, and please all UK people reading this ... could you please start driving on the right (the opposite of left) side of the road starting ... today ... so you comply with our world standard
In fact, I thought there was nothing wrong with Navision standard code until I started using C# myself, and saw how you are basically forced into scoping your variables correctly, because it simply won't work otherwise. It's because of the 'flexibility' of the Navision IDE that you can do whatever you want.
Also a very good point is that there is no inspection. Without some kind of Q&A process that also looks at the coding standards, I don't think it will happen any time soon that coding standards will appear in Navision. Personally, the fact that now that Microsoft is in charge of Navision, and there STILL are no true coding standards in 4.0, speaks volumes about their intentions with the product.
RIS Plus, LLC
Yes i passed the navision exam and it was hard because i had to start to think different then i was used to. Doesn't mean i have to agree with it.
Yes i think too many functional educated people are developers. Has advantages but with this topic the disadvantage of this is explained.
Just cant wait until Green is there and how it will be \:D/
This is not really correct. There are official MS coding conventions for .NET languages (http://msdn.microsoft.com/library/defau ... elines.asp - there even is a tool called FXCop that can check your own code for compliance), and they specifically state (among other things) that no prefixes should be used. In fact, given the fact that VS.NET is a real and workable editor which has all these handy things that all modern editors have, there is no need for the use of prefixes. Need to know which is the type of your variable ? Just hover the mousepointer above it and you see a tooltip with this information. Need to find where or hwo the variabke is defined ? Select 'Go to definition' form the context menu.
Off course, given the fact that what Navision dares to call an editor is as much worthy of the name editor as a butchers knife is worthy of the name scalpel, using prefixes to cover for the lack of a real editor is currently the only workable solution.
You can't understand a product of this complexity in a few days, and having one standard applied to all code would still not make it easier to understand.
It's because you have to open a friggin globals list to see the scope of a variable that makes it cumbersome. It would be a lot easier if there would be a simple declaration within the function. I doubt that there would be half the complaints about naming conventions.
I don't believe for a second that ALL C++ code has clear naming conventions, it's the fact that you can see the scope of a variable right where it is created that makes it more readable.
Navision code: and you go 'hmm... what the heck is SalesLine... a rec variable? is it local? is it global?'. You'd have to open the globals window and hope that you can find it, or else open the locals window, even though the variable name is very clear for an experienced Navision developer.
C# code: or something like that, and you immediately see what it is and what the scope is, even though the name SL is an absolutely horrid variable name.
RIS Plus, LLC
1.) In the Netherlands, if you do your own electricity it MUST be checked by a professional. This means you handle as the rules are… Navision has rules, you should handle to them.
2.) Navision reads very good. Good code, the same though out whole Navision. Not always perfect code, but… the same though out Navision. In fact, I can estimate the working of Navision code or functionality without ever seeing it before. THAT THE POWER OF GUIDELINES! If you can’t read Navision, own guide lines are not the answer! Just learn to read Navision and apply it.
3.) If you use Navision guidelines I guarantee your code will be better in the end. I’m sure!
I’m programming as much as standard Navision as possible. I even copy and past variable names. And in many, many, many times Navision standard forced me to think about my solution and maybe change the solution I was building. This means, if using the guidelines your application will be better. I’m sure! That alone is reason enough to use nothing but standard.
Off course I have a couple of additional guidelines, but no way!!! I’m using pre and post fixes. And I’ll never will!
If it was hard to write, it should be hard to understand."
I will take a programmer about 3 years to actually program without any big boundaries. 5 years to really go at it and program really big applications. No much time compared to the total time spend on Navision. Sum all Navision developers hours
And still after that you will learn new stuff every day.
I'm a developer since 1997, and I can read Navision code like a book. As many others, I’m sure. And in these years I’ve obtained knowledge about the product Navision. I know what to code where but most important, what not to code where.
I’ve seen the worst code. And all these code had one thing in common. No guidelines.
If it was hard to write, it should be hard to understand."
I think tooltips are helpfull but i dont think of it as the sollution of finding variable types. Some of the most basic things ... i feel ... should be visible directly. And really if you apply it consequent and are used to it, then you will love it.
:arrow: The strange thing in our company:
* all (ex)-4GL code writers vote for using prefixes.
* all non 4GL code writers vote against prefixes.
I think this statistic tells us something ...
compare these code snippets (really stupid coding i know but just as example:
SalesLine.GET('1'); SalesLines.SETRECORD(SalesLine); SalesLines.RUN();lrecSalesLine.GET('1'); lfrmSalesLines.SETRECORD(lrecSalesLine); lfrmSalesLines.RUN();Yes as experience Navision developer you know in the first snippet that SalesLines probably has to be a form because a form has the SETRECORD function and a report does not. Because navision does not have a lot of complex variable types experienced people would understand the code.
But i still think that the 2nd snippet is more readable.
In C-sharp with all different class library types this problem only gets worse.
If you don't understand Navision code, no naming convention will change the readability (sheesh is that a word? :-k ) of the code, unless you start using funky abbreviations, or simply misnaming them (like calling a Sales Line variable PurchHdr, which I have actually seen [-X ). By seeing the statement SalesLines.RUN, you immediately know that it is something that you can RUN, so it's not a table.
I agree that you need some kind of convention, but I agree with Emiel that the Navision standards are perfectly readable. It took a while to learn, but I am really comfortable with it now.
RIS Plus, LLC
The point for me is hats any convention has its positive point and its drawbacks. And any convention is good but only when you use it strictly.
I dont see the symbols menu as a disadvantage. Its just another way of searching. When i press l i almost surely am at the local variable section which is almost never more then 10 variable and i can easally pick the right one out. I can assure you that it is fast searching.
Its just a matter of what system you are used to, and if you are used to a system it is hard to do get used to other system.
And you're right, the SalesLineForm name is not Navision standard. I guess I use the standard unless it looks confusing. Like if I have a global Sales Line, and I have a Sales Line as a parameter, I call the global SalesLine, and the parameter parSalesLine, and if I had a local I'd call that one locSalesLine, since both parameters and locals are always at the top of the list that's easy to find for me.
Other than that, if I have more than one Sales Line, I put the purpose of the variable in the name, so I guess I dont use Navision standard there either. So if I need to check a value of one sales line for some process with another one, I would have my main global SalesLine, and another global called SalesLineToCheck or something to do the check. I have found that using Navision standard SalesLine2 is very easy to make mistakes with.
I don't believe in having types like integer or decimal or boolean as part of the variable names. In Navision you know that Quantity is a decimal, so I don't need it to be called decQuantity. Other than that, I kind of cheat in giving the variable a name that gives it away, like a boolean called 'CheckIsOK'.
RIS Plus, LLC
I myself call General Ledger Entry GLE, Sales Header SH, "Quantity (Phys. Inv.)" PhysQty. etc. I think no reason to be verbous, I expect the ones who go after me and modify it to be professionals.
A much more important thing is documentation. It is very impotrant to
write the documentation trigger like "2005.05.26 HM added new field Bar Cod, with OnValidate Code (copy-paste)". (HM is my monogram.)
Then I have a Perl script that extracts documentation from objects saved as txt.
Another important thing is to do modifications like:
//HM+ 2005.05.25 changed line
//GeneralLedgerEntry.INSERT;
GeneralLedgerEntry.INSERT(TRUE);
//HM-
The reason is to easily merge it when installing a service pack.
Do It Yourself is they key. Standard code might work - your code surely works.
I must agree with eromain that Navision code is well readable (but sometime I am missing some memo or simple info about the code for FASTER reading...:-)
ad. what type is the variable etc:
Did you ever look to the status bar when you have cursor on some variable? (why than use some prefix for var type?) :-)
For myself the code with prefixes (lre etc.) is worse readable than without it with good names. Why? Because there is too much informations in the code, which I do not need. Why I must see them everywhere, when I do not need them all the time?
But of course, there are pros:
If you use prefixes, you will have no conflict for example with some field from rec. which have same name (somewhere in standard app. is problem that there is var. Currency and within WITH xxx construction is field called Currency and application does not know if it is variable or field...) and you can say - yes, this is added code, because there is used our variable...
It is better to teach your programmers (which are not "profi" programmers) some naming policy than let them create horrible names...
Cons (only my opinion):
for me the code is not fast readable because too many informations in the code (which are not needed) which I do not need all the time (when I need them, I can find them out very quickly)
The points, where my code is connecting to standard code look terrible if part of the code use prefixes and the standard not...
I am compactible with the rest of the application - it will have unified visage
When I sent the code to someone, I do not need to describe the convention for him...
Of course, I am using pre or postfixes for some variable too, but I am trying to be as near as possible to the Navision standard...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
I beg to differ. *Every* pragramminf 101 class tells tou that you should not make funtions too long. Navison contains functions that are like 20 A4 pages long. You wouldn't pass in any school/university with such code. And even if variables were defined and scoped in the source (which I would welcome very much, and maybe we could also get rid of having to define procedures through the symbol menu, if you want to code you should at least know how to declare variables and functions, if you want to install electricity you should at least know how to connect wires) instead of through some retarted symbol menu, it wouldn't help. You would have to search for the definition of the variable through 20 pages of code.
Another thing that is a real nono is the way that in Navision code there is screen interaction littered through the code modules. What genius thought of that ? If I want to use some procedure in a code unit, I have to make sure that I change the code so that it doesn't throw op messageboxes.
If only Navision themselves and the NSCs did that...
I'm not af an of prefixes either, but given the state of things, they are the only workable solution to make clear how the code works.
This is the part no NSC tells you when you start with a Navision project. It takes you this long because a) the code is a mess, b) the code editor is a mess, c) the debugger is a mess, d) there is hardly any documentation to be found on how things work and which module does what, and e) Navison is riddled with bugs.
And on the other hand, NSCs hardly ever can keep their people for that long, so if it takes this long to master Navision, 80% of the people working at an NSC are amateurs.
I would never ever choose some product that takes this long to master and that I don't even control myself.
There are lots of documents on the MS site that talk about coding conventions, this is only one of them (but as any large software project (except for Navison of course) is made out of classes, this applies to most projects), but they all tell you the same ; don't use Hungarian Notation, don't use prefixes., don't use underscores.
I also feel tha things should be visible directly, but if you have class (or module) scoped variables you really can't see their declaration when your in prcoedure X halfway through the code. Tooltips are just one off the many helpfull tools found in modern editors like VS.Net, or Eclipse, tools sadly not found in the Navision editor.
Huh ? Ever looked at CU80 ?
I was full of hope so I tested this immediately, but alas, no luck in 3.10.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Take for example:
SalesLine.GET('1'); SalesLines.SETRECORD(SalesLine); SalesLines.RUN();The second I read the code I knew what was going on. SalesLine is a Table, SalesLines can ONLY be a form! Besides the correct naming of the variables you can see from the SETRECORD statement that it’s a form. And don’t tell the .RUN commands makes it confusing.
I couldn’t even read the second piece of code.
lrecSalesLine.GET('1'); lfrmSalesLines.SETRECORD(lrecSalesLine); lfrmSalesLines.RUN();I really needed to read this code line for line to see what is happening. This takes me 10 maybe 15 seconds. The first piece took me like 3 seconds. So, you could see it takes up to 5 times as much time to read non-Navision code.
The first piece of code I read based on recognition, the second I need to compare variable names.
And if that’s not reason enough… Why learn two guidelines if you can do all with just one?
And one big important question. (I’ve asked it before.) What do you do when you want top use a standard Navision variable (SalesLine) in your code?
1.) Use it as it is, so use two guidelines in your programming. (BAD SOLUTION)
2.) Rename the standard variable name. (EVEN WORSE)
3.) Create a new Variable name and copy it from the standard variable. (THE MOST BAD SOLUTION POSSIBLE, in most of the cases.)
Maybe I should make a survey with this question…
If it was hard to write, it should be hard to understand."
You have some verry good points there. Hungarian convention, yes thanks now i remember the name of the convention. It isn't microsoft though but that is maybe why MS doesn't like it
I find it hard to believe that MS is saying not to use pre and post fixes. I do think you shouldnt use them in class properties but surely you would like to scope variable. There are 3 types of scopes (navision only has 2) and that is local, private and public. Surely the last 2 you want to know :?:
@Emil
That is only because you are not used to these conventions. Everything takes time to learn.
As a matter of fact, Hungarian was invented at Microsoft :
http://msdn.microsoft.com/library/defau ... aNotat.asp
And yes, Microsoft is saying that you shouldn't use it anymore in .NET.
It is hard to explain why there is absolutely no need for that anymore if you have never used VS.Net od a similar development environment. It's like trying to explain what the internet is to people somehwere in a jungle where they are happy if they get to read a newspaper from time to time. If you never ever develop in something else than Navision, you really don't know whatr you are missing.
I stil feel that Hungarian Notation (or any other pre- and postfix notation) is ugly to read, but if you are working in an environment that is really crippled and does not give you a convenient way of getting to know all kinds of information about your variables (scope, type, value, ...) it is better to use it. It's like choosing between the Plague and the Cholera.
@Emil
In a good environment I would go for option 2 (why would that be bad ? After all it is me who is maintaining the code), but in Navison that's a recepy for disaster since there's no refactoring support. This would then force me to go for option 1 (which in fact we do here where I work). At least all code that I wrote would be easier to maintain and debug than the code I did not write.
And if you say that you couldn't even read the second piece of code, you're not being consequent. You say that you know something is a form because of the SETRECORD function. This means that you read your codelines from the back to the front, so right before the SETRECORD you find lfrmSalesLines. How hard is it then to know that we are talking about the form( you already know that) SalesLines ?
It is also very striking to see how you ignore all the other remarks I've made. I hate Hungarian just like you do, I don't like pre and postfixes, but given the development environment in Navision we would be better of if everybody just used them, that would make the code at least a bit comprehensible and maintainable.
It would also help if Navision followed all the good practices any programming course teaches you.
In many ways i agree with you Jesam, prefixes may look ugly its not that what counts for me. It really helps me in Navision but also in other development tools. All other means of helping (and i did know that clicking on variables in navision displays variable info in the bottom) i think are insufficient for quick code reading.
Also a point i forgot to mention is when writing code i will detect possible type conflicts early.
So lets take 2 snippets again:
(ok it sais quantity = local integer and amount = local decimal)
Is Quantity always an integer? Often it is in Navision but it doesn't have to be. In the 2nd snippet i can see a possible type conflict inmediatly in the first snippet i may think Quantity is a decimal. When reviewing code you do not easally look up type information for every variable you see.
For the same i use them in 4GL development tools.
Just because someone called a variable liQuantity, does not mean that it actually IS a local integer. Like I said before, I've seen a Purchase Header variable called SalesLine (in a report written by one of our customers), which only compiled because the code used fields that are present in both tables. I ALWAYS check types, and therefore I don't need prefixes.
I agree with Emiel that the code snippet with the prefixes takes longer to read than the code without it. Besides, once you know what the type and scope is, you don't need the prefix anymore.
The only reason that I put postfixes in my variable names is to prevent double names. Most of the time if I need a local Sales Line for instance, or a parameter, there already is a global variable of that type.
RIS Plus, LLC
When you set Option Strict On, the compiler would indicate an error if you tried to assign a decimal value to an integer.
When you have an editor that does background compilation (like VB6 or VB.NET) the compiler will warn you the moment you type that illegal line of code, which in turn removes the need to use these type prefixes. Alas, Navision doesn't have any of that, so we better use prefixes if we want to be able to read the code and understand it without have to look up a definition of some variable that might be declared 20 pages ahead (when reading the code on paper), or having to hunt through the anoying Symbol Menu for the variable and then still having to write it down to be able to remember it.
Holy Jingo!
I means the developer you met is either a) stupid a**hole b) not forced to do REAL work by a REAL client.
I always envy you comfortable Western European and American consultants. You always seem to have so nice clients, so nice projects, so easy work... Didn't you really have a client saying " Navision s**ks, you cheated me selling me this s**t, so I want to change everything the way I work or I won't pay the licence, nor the service, and even will charge a lawsuit!!!!" 90% of my client said this.
It seems the life is really different in Eastern and Western Euope.
3 years for developer? Are your customers are really so nice, so forgiving? Really so?
I started at my previous job as a Navision Sales. I learned the basics of Manufacturing to be able to demo it as a salesman. Later on it became evident that I am a horrible salesman, I became a Manufacturing consultant. I started my first project. Every other consultant was an accountant, learned only in Navison finance. I had to implement WMS. An I had to do many, many changes. And then I had to do changes everywhere else because no one was there who dared to change Navision code, but the client needed something really, really different thant Navision. It was back the time of 3.6 And this was not an industry add-on they needed, but a country add-on, or a regional add-on: Navision For The East. It meant a total, radical change: to turn a liberal "nordic" software into a totally strict and inflexible "eastern" software.
I learned more on Navision development in those 3 months that any comfortable western consutlant learns in 3 years. I worked 16 hours a day, neck-deep in code. I did not want to do it, but had no other choice - it was impossible for the customer to use standard Navision.
Yes, it was a bad sale - but the only sale we got in our first 9 months. We had no choice.
If there would a kind of "Navision developmen competition" I would beat of my 2.5 years of experience any western consultant of 10 years of experience. It is not boasting and I don't want to be rude, please forgive me if I seem to be rude. I am not a genius, I simply had to learn it in 3 months because had no other choice - there were customers, there were Navision and there was a gap a of 100 miles between them.
So, learning time is not static. It depends on your country, and your customers.
In Eastern Europe, it must be around 3 months - or less.
.
Do It Yourself is they key. Standard code might work - your code surely works.
Yes, if you are rich enough to buy Visual Studio .NET.
The rest of the world uses #develop (SharpDevelop).
Please, don't forget the rest of the world!
Do It Yourself is they key. Standard code might work - your code surely works.