Good Practices in Stable Coding???

Working towards the nubile wenches on the yacht, but so far all I own is my own company...

We are writing newspaper production software - basically layout software for newspapers, and booking software as well. Actually quite a lot of fun, cos the layout stuff isn't database stuff - striaght graphics work and AI, which is nice for a change. The booking package is DB though...

- gaffa

I to have found planning out my software before I even start coding allows me to be more efficient with my time, and produce better, more manageable code. I thought I was handycapped because I did this (need to do this for big projects), and I know a lot of programmers don't do it. It's nice to hear that this is something that others do.

Another point on the 'using msgbox's' idea for debugging, don't do it unless absolutly neccessary. Because it stops your code, you could be missing something that is really causing the problem. This happens a lot when doing async process calls to objects.

Always indent your code, it makes it readable.

Always name your variables to something readable. Don't name them obscure things unless you want your code unreadable.

Use OO development as much as possible.

That's all I got, thanks for reading.

Look up Hungarian Notation if you need help naming vars - consistent naming makes a huge difference....

- gaffa

Quote:

---

Originally posted by GlenW
I know this is pretty basic, but I've seen people not do it.

After typing;

VB Code:

If(CONDITION)then

You should type:

VB Code:

End If

Then put the body of the If statement in.
Same for Whiles and Fors

After opening a Connection and Recordset, Close them, then add the code to use them.

---

I totally do this.

It makes sure I close the statments.

I also use comments in the body of a statement if nothing is supposed to happen (ie. planning to add stuff there later) rather than leaving it completely devoid.

if condition then
'ToDo: Add a bail out here
end if

Quote:

---

Originally posted by Lord_Rat



I totally do this.

It makes sure I close the statments.

I also use comments in the body of a statement if nothing is supposed to happen (ie. planning to add stuff there later) rather than leaving it completely devoid.

if condition then
'ToDo: Add a bail out here
end if

---

same here. makes things so much easier.

also:

VB Code:

set object = [i]whatever[/i]
 
set object = nothing

then put code between etc

A language-neutral set of guidelines

1. Code for human consumption

It is one of the most pervasive misunderstandings in computing that the source code is for the computer's consumption. Computers work with low-level binary code, a series of impenetrable 1's and 0's or hexadecimal numbers, not the structured high level languages we code in. The reason that these languages were developed was to help the programmer.

In practice, coding for human consumption means coding for clarity first, over execution speed second.

2. Comment often and comment well

The comment is the extreme example of a language element for human consumption. Most compilers will strip the comments from the executable program. The purpose of the comment is to tell you (and any future developer) what the program is intended to do. Write comments with this in mind - and avoid simply restating the code.

Good comment: "Disable button to prevent its activation". Bad comment: "Set cmd = False"

A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?

3. Layout code to increase legibility

Just as it is important for an author to split a book into chapters and paragraphs that aid reading so it is important for the developer to consider the layout of the code and how that can aid readability of the code. In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end.

4. Expect the unexpected and deal with it

Before you open a file, make sure that the file is present. Before you set focus to a control, make sure that the control is visible and enabled. Try to work out what conditions could cause your code to fail and test for them before they cause the program to fall over.

5. Name your variables to aid readability

There are a number of strategies to variable naming. The key is to be consistent and to be as informative as possible. If you name a variable nMonth, you give the programmer extra information as to what that variable is expected to contain. I personally prefer the Hungarian notation style - but whichever style you use, consistency is the key.

6. Keep your functions and subroutines simple

A function or subroutine should ideally only do one thing. One of the greatest sources of misunderstandings, in my experience, is a subroutine that does a number of different operations. This should be split into separate functions for each different thing it is doing so that these in turn are easy to reuse, and the scope of a code change is easy to understand.

7. Scope functions and variables appropriately

Functions and variables that are only used in one module should not be visible outside that module. Variables that are only used in a function or subroutine should not be visible outside that function or subroutine. This prevents any use of a variable or function outside of where it makes sense to use it.

Speaking of which, one thing I was told a long time ago and I really find useful is that you should attempt to keep all subroutines and most functions to fit on the screen without scrolling.

If you get more detailed, make more subroutines. This helps when reading your code because whole proceedures are consolidated and if you are sure a section of code is working properly, you skip one line, and not a whole section.

This might be a little bit off topic, but I think it is related to good programming habits (at least for larger projects):

How do you make realistic time-estimates for your projects?

As good programming practice goes, I find that thinking in black-boxes helps alot. Even if you're not ready for OO-programming yet.

Quote:

---

Originally posted by biw
As good programming practice goes, I find that thinking in black-boxes helps alot. Even if you're not ready for OO-programming yet.

---

ummm... could someone help me out here? what does OO-programming mean? :rolleyes:

I was thinking of Object-oriented programming in all it's glory (using classes,inheritance, polymorphism etc)

Objectoriented programming, usually involves using a specific feature of a programming language.

What I am saying, is that getting used to think in "black-boxes" helps your design, even if you only use standard vb-commands to implement your program.

I got a newer; more updated version of the speed tester.

It does find IF's faster than Select, now.

Please, test it out, see what you think.

Also, if you are curious, try putting in 40 million in the top box (40000000) and run it both in the IDE and as an EXE.

See the difference in speed.

Is the new program acceptable?

Is there anything else I should have done / not done?

You would have done differently?

I use this information to see if I have bad practices that I need to weed out of my style.

Thanks.

Here's one.

In visual Basic, I usually always give each new controls a unique and descriptive name.

Instead of using the defaults "command1", "command2" etc..
I would have renamed the buttonnames to "cmdRun_IF", "cmdRun_Select" and "cmdAverageBoth"

I have made a habit of that, so that I don't start off with default names, having to rename them later.

When you have many events on the same control, that makes the code just that much easier to read.

Very good feedback.

I actually normally do name Commmand Buttons as bnSomething, but I didn't here.

Thanks for pointing that out :)

Just a few tips...
- use cmdWhatever -- the "cmd" is the easiest to understand, "bn" might be misunderstood as something else
- sString instead of strString -- easier to type, cleaner names
- iInteger, lLong, etc. shorter is better
- make sure that double quotes (") are handled correctly and won't crash your program
- provide wrapper functions for most API's you use, especially when dealing with strings.
- denote functions as "clean" or "dirty" -- determines whether you need to validate data or not.
- comment functions by explaining what they should do -- what their purposes are.
- never use the End statement.

I'm too tired to think of any more...

Here's one for those of us, that have english as a 2nd language.

Name your variables in english, don't use your native language.
Native language is ok for comments though. :)

That way the code "reads" much better

Surprisingly many of the people I know, mix english and Norwegian (my lang) when writing code.

Whoops, I forgot about magic numbers. The only actual numbers in your code should be 1's. Rarely will you have a good reason to use other numbers, like a random 9 <-- that's called a magic number. Using constants instead. That way, you don't have to do search and replaces, which risk missing things or changing things that should not be changed. Not to mention that using named constants makes your code more readable.

Hmmm.. didn't quite catch that. Care to elaborate? Example maybe?

I think this topic deserves a good bump :D