If you could give 1 tip, what would it be?

[csKanna]

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.

[PMad]

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

[stettybet0]

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.

[jcis]

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.

Option Explicit On 'VB.NET!

[TBeck]

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.

[jcis]

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!)

[Hack]

Moved

[RhinoBull]

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.

[Atheist]

Always have Option strict on

[Slaine]

Don't re-invent the wheel.

[penagate]

Use the right tool for the job.

[Hack]

Always know what you are going to do before you do it.

[bgmacaw]

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.

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.

[MasterBlaster]

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.

[csKanna]

Use the right tool for the job.

Can you brief ?

[szlamany]

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!

[mendhak]

Just because a lot of people are doing things incorrectly doesn't make it right. It just makes a lot of people wrong.

[Arty2000]

The old classic... Do a regular back up of your files.

[iPrank]

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.

I agree with Rhino.

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.

[RobDog888]

Search the forums first or read the FAQ threads before posting on "How to ....." something

[Merrion]

Don't use floating point variable for storing money related data.

[penagate]

Don't use floating point variable for storing money related data.

Bad experience?

[RhinoBull]

Don't use floating point variable for storing money related data.

Why not? I don't suppose you suggest to use Strings...

[szlamany]

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.

[Shaggy Hiker]

How do you feel about decimal types?

[RhinoBull]

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.

... and the solution is ... Perhaps you tell us.

[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:

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.

http://worsethanfailure.com/Comments...and_Round.aspx

and more...

http://docs.sun.com/source/806-3568/ncg_goldberg.html

and more...

http://blogs.msdn.com/oldnewthing/ar...16/634078.aspx

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.

[RhinoBull]

Isn't floating point imprecision well known to programmers?? Stuff like you divide 16 by 4 and get 3.9999[/url]

It has nothing to do with "floating point imprecision" but rather VB's using Banker's rounding algorithm which was always a problem.

[szlamany]

It has nothing to do with "floating point imprecision" but rather VB's using Banker's rounding algorithm which was always a problem.

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.

[penagate]

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.

[RobDog888]

The one tip I would give is not to ask programmers the difference between floating point, decimal and currency types

[RhinoBull]

The one tip I would give is not to ask programmers the difference between floating point, decimal and currency types

I like it.

[szlamany]

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.

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

in the immediate window you get...

 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

[RhinoBull]

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.

[szlamany]

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.

[RobDog888]

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

[RhinoBull]

.... Just dont try to use String

I agree.

[RhinoBull]

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.

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.
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.

[Shaggy Hiker]

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.
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.

[sevenhalo]

The best programs you'll ever write are the ones you never thought you'd be able to do.