So, there are loads of tips on this forum, which would you reccomend somone to do. Mine is "Always use Option Explicit on all your forms, modules, etc."
Please try not to repeat the same tip twice. Say what works for you.
Printable View
So, there are loads of tips on this forum, which would you reccomend somone to do. Mine is "Always use Option Explicit on all your forms, modules, etc."
Please try not to repeat the same tip twice. Say what works for you.
I would tell people to use variable names that make sence to the variables purpose in life, and indent their work to make it easy to read and understand. sorry thats 2 :o
I would tell people to stop using an obsolete language, and to use VB.NET instead, where you don't have to set Option Explicit and your work is automatically indented. :p
Quote:
Originally Posted by stettybet0
VB Code:
always comment your code... especially if it is a large project.
The extra little effort now will save you a lot of time later on.
Use Watches to debug Objects, learn to find and use VB Native Constants, Use TAB Key to Indent (It's much easier to write/read!)
Moved
Try to keep it simple - doesn't matter the language.
Don't write the functions or even classes when all you need to do is A = B + C.
Always have Option strict on
Don't re-invent the wheel.
Use the right tool for the job.
Always know what you are going to do before you do it.
Know your 'audience'.
Developers often forget their users and their needs and come up with bells and whistles that feed their ego but don't do their users much good. For example, one POS system I saw in operation had a cutesy cash register opening sound, kind of a "Thank You for shopping at QuickieMart" with a jingle in the background. It was very annoying and it could not be turned off. I think if the programmer had been there the clerks would have strangled him. :mad: :eek:
Of course, it may have been a marketing or operations manager who came up with that bit of nonsense. Which leads to the second part of my tip, make sure your project sponsor knows the audience and be brave enough to challenge questionable ideas.
Spend 70% of your time researching and planning and 30% programming so you don't end up spending twice as much time fixing bugs and coding yourself into corners.
Can you brief ?Quote:
Originally Posted by penagate
I always code a couple of lines or a small sub/func and then step through it to see how it functions - examining variables and such.
So basically - code and debug at the same time, test small portions - don't write a whole program and debug it at the end!
Just because a lot of people are doing things incorrectly doesn't make it right. It just makes a lot of people wrong.
The old classic... Do a regular back up of your files.
I agree with Rhino.Quote:
Originally Posted by RhinoBull
But for complex/large projects if you feel a piece of code can be used in some other parts of your program or moving a few line into a function will icrease readability....do so.
I prefer to break my code into as many functions as I can. But those functions must be 'logically independent' or they must be reusable.
Place correct error handeling code in all those functions and debugging will be a lot easier.
Search the forums first or read the FAQ threads before posting on "How to ....." something :D
Don't use floating point variable for storing money related data.
:lol: Bad experience?Quote:
Originally Posted by Merrion
Why not? :confused: I don't suppose you suggest to use Strings...Quote:
Originally Posted by Merrion
Floating point for money tracking systems is evil - I know that from first hand experience myself.
The inherent inaccuracies when doing math on float's leads to loss of precision.
How do you feel about decimal types?
... and the solution is ... Perhaps you tell us.Quote:
Originally Posted by szlamany
In VB6 we used currency data type - which as you know is really an integer type with an implied decimal point.
Never had to use decimal types - but I believe they supercede currency in .Net - right?
On mainframes we used STRING arithmetic - with 60 places of precision.
Isn't floating point imprecision well known to programmers?? Stuff like you divide 16 by 4 and get 3.9999 (a silly example - might not be one that actually happens).
From a link I just found:
http://worsethanfailure.com/Comments...and_Round.aspxQuote:
I love how people keep going on about various types of rounding, even though they make no sense to the actual problem here.
Here's what his roundTo function does:
-Inputs are a number to round and the number of digits to round it to.
-First, it figures out a multiplier. This will be 10 ^ digits. It calls this 'factor'.
-It multiplies the number by factor in order to move the digits to the left of the decimal point.
-Adding .5 at this point is supposed to do the round operation. If it already had .5 or more in the fractional part, this would cause the integer to round up. This is where the failure happens, of course.
-Finally, it truncates off the fractional part (that's what Int() does), and divides by the factor to move the decimal back up.
The failure is that it's doing this not to actual decimal numbers, but to floating point numbers. As has been pointed out already, 39.995 cannot be represented exactly in that limited space, and you actually get 39.994998931884766. When you do the math on that, you get:
39.9949989 * 100 = 3999.49989
3999.49989 + 0.5 = 3999.99989
Int(3999.999) = 3999
3999 / 100 = 39.99
So your rounding fails for certain cases. This can't actually be completely fixed using floating point numbers. Limited size floating point numbers simply cannot represent some parts of the number line in the same way that limited size decimals can't either (0.333... = 1/3). Yes, adding more than .5 (like .501) would work, but it would make the answers wrong for some other chunk of the numbers.
If you're doing your math in base 10, use a different representation. Visual Basic has a Decimal data type for this very reason (which I think uses a BCD format internally). Most other languages have something similar.
and more...
http://docs.sun.com/source/806-3568/ncg_goldberg.html
and more...
http://blogs.msdn.com/oldnewthing/ar...16/634078.aspx
Quote:
did you tell your friend that he should be using the Decimal type? It would allow him to add .01 about 10^28 times before losing precision. Anybody doing arithmetic with monetary figures should be using it.
It has nothing to do with "floating point imprecision" but rather VB's using Banker's rounding algorithm which was always a problem.Quote:
Originally Posted by szlamany
I don't agree - but I see no point in discussing this further - the links I posted can be reviewed by those interested in how floating point differs from decimal and currency.Quote:
Originally Posted by RhinoBull
IEEE floats are approximations at best, due to the way they are stored (mantissa/exponent); decimal/currency types are simply integers with a few bits to denote the decimal place. Floating-point maths is thus inherently imprecise in any language.
The one tip I would give is not to ask programmers the difference between floating point, decimal and currency types :lol:
I like it. :)Quote:
Originally Posted by RobDog888
But keeping it serious for a moment - here's a simple example of the difference between DOUBLE and CURRENCY as far as precision.
I cut out some of the output - as it only turns to garbage at the 52nd iteration.
Issues like this are real - from years of interest and pension and payroll calculations - I've got battle scars from debugging and fixing other peoples code.
in the immediate window you get...Code:Private Sub Form_Load()
Dim SomeValue As Double
Dim OtherValue As Currency
SomeValue = 1
OtherValue = 1
For x = 1 To 60
SomeValue = SomeValue + 0.1
OtherValue = OtherValue + 0.1
Debug.Print x
Debug.Print SomeValue / 10
Debug.Print OtherValue / 10
Next x
End Sub
Code:1
0.11
0.11
2
0.12
0.12
3
0.13
0.13
4
0.14
0.14
5
0.15
0.15
.
.
.
50
0.6
0.6
51
0.61
0.61
52
0.619999999999999
0.62
53
0.629999999999999
0.63
54
0.639999999999999
0.64
55
0.649999999999999
0.65
56
0.659999999999999
0.66
57
0.669999999999999
0.67
58
0.679999999999999
0.68
59
0.689999999999999
0.69
60
0.699999999999999
0.7
So what are you trying to say? I really don't understand.
The fact that double is more presize number than currency which is nothing else but rounded double using Bankers rounding algorithm?
Handle properly your double precision point and you'll be just fine.
But saying that it's "imprecise" isn't quite "presize" definition I'm afraid.
Your decimals and currency could give you incorrect results if not proprly handled.
The bottom line is "learn to handle with the precision you need" rather than complaining about the incorrect output.
I really don't understand the point behind these arguments.
Sorry.
rb - I showed a double value being divided by 10 that produced this value
0.619999999999999
and that's the problem.
No rounding involved in my example.
No bankers rounding.
Floating point simply cannot represent all values - since it's a binary representation as opposed to a decimal representation.
This isn't a VB6 issue - I've encountered it in all programming languages and platforms.
Excel also does not handle precise calculations well at all either. But when you really need precision its still the same, use the best tool (data types) for the situation whether its currency, double, integer etc. Just dont try to use String :lol:
I agree.Quote:
Originally Posted by RobDog888
Yes, I saw that. The "problem" is that "0.1" is already rounded number so is Currency. Double returns "presize" floating number so it needs to be handled.Quote:
Originally Posted by szlamany
If Currency works for you then use it - I don't ever as it has a lot more problems (in VB at least) than any other numeric data type. Nor I ever use decimal type.
Never had a problem with decimal.Quote:
Originally Posted by RhinoBull
The best programs you'll ever write are the ones you never thought you'd be able to do.