Development Guidelines / Resources

[Richard Conyard]

This is a bit of a cross post from another forum - but might be of use...

A lot of question on here seem to be from beginners, and some keep on re-appearing. So below some hints to help out:

Use Option Explicit
Place this in the first file that gets called in your ASP page. It will force you to declare any variables that you use and stop typo's


Make use of include files for site wide functionality
This will allow you to specify common site variables (database connection strings), and common functions ( sendMail?) in one place on your site. This can also be used for templating a site (top.asp / bottom.asp).

Use Functions and Subs to encapsulate code
This puts a level of scope on your variables and stops different things interfering with each other.

Use some kind of hungarian style notation ( str, int, lng, obj), for variables
This will help you figure out what each variable is as you use it. For example there was the merit table posting on here, what is merittable? rsMeritTable would have given everyone a much better clue.

Use Friendly variable names - Stevusuk
There isn't any reason why you would want to name a variable "x" when it could be "intPage"

Comment code, you might not remember why you did it that way in a couple of months time

Where possible try and split your code into the appropriate layer
The standard three tiers of development are data, business and presentation. Try to keep these apart in your code and everything will work much better.

Avoid arrays etc. like the plague
The RecordSet object is perfectly nice to work with, stop trying to pull data into nameless arrays. What reads better:

 arrFood(3)

or

 rsFood("Flavour")

Rules of Thumb
1. If is seems impossible it's likely you're doing it wrong.
2. S/He who googles first is unlikely to be shot down in flames
3. Those error numbers really do mean something, try searching
4. If you're having to debug more than 30 lines of code you've not encapsulated enough
5. If you have to jump through more than 3 functions/subs to debug a problem you've encapsulated too much.


Websites:
http://www.w3schools.com
http:/www.devguru.com
http://www.asp101.com

Useful Functions

SendMailHTML

	Function SendMailHTML( str_sendMailTo, str_sendMailFrom, str_sendMailSubject, str_sendMailBody, str_sendMailFileAttach )
		Dim objConfiguration
		Set objConfiguration = CreateObject( "CDO.Configuration" )
		With objConfiguration
			.Fields("cdoSMTPServer") = "127.0.0.1"
			.Fields("cdoSMTPServerPort") = 25
			.Fields("cdoSMTPAuthenticate") = 0
			.Fields("cdoSendUsingMethod") = 2
			.Fields.Update
		End With
		
		Dim iMsg
		Set iMsg = CreateObject( "CDO.Message" )
		With iMsg
			Set	.Configuration = objConfiguration
			.To = str_sendMailTo
			.From = str_sendMailFrom
			.Sender = str_sendMailFrom
			.Subject = str_sendMailSubject
			.HTMLBody = str_sendMailBody
			If ( str_sendMailFileAttach <> "" ) Then Call .AddAttachment( str_sendMailFileAttach )
			On Error Resume Next
			.Send
			If ( Err <> 0 ) Then SendMailHTML = "Unable to send a mail due to a server error"
			On Error Goto 0
		End With
		Set iMsg = Nothing
	End Function

Any more for any more?

[stevusuk]

This is good advice - especially when someone else might be picking up your code.

Also - another guideline I tend to use is to use names for variables and functions that explicitly describe what they are used for so in effect your code becomes self-documenting.

There isn't any reason why you would want to name a variable "x" when it could be "intPage". And if it needs to be more explicit, do it, it makes it easier to understand what "intCurrentSearchPageNumber" is for than "strPage". It may seem a lot of effort at first, but it does pay off in less brain usage each time you visit the code.

[buntine]

Nice post. I will make it sticky for a while.

[<Eddie>]

Avoid arrays etc. like the plague
The RecordSet object is perfectly nice to work with, stop trying to pull data into nameless arrays. What reads better:

 arrFood(3)

or

 rsFood("Flavour")

I have to disagree with this. The initial statement is ambiguous. Arrays are a very powerful and flexible way of handling data and must be used appropriately. Nameless arrays I can understand are fustrating for anyone trying to understand the code but that's a naming convention issue, not a programmatical one.

As for the example shown, the recordset is itself an array and can be manipulated as such. Shifting datasets into named arrays can also be valid when having to process large amounts of information repeatedly. The recordset object may not be the most efficient way of doing this so destroying the object and closing the connection is valid.

It's all about using the right tools for the job but do not avoid arrays, they're an essential part of any programming language and without them the world as we know it wouldn't exist.

[russell]

Have to agree with Eddie. In fact, arrays should almost always be used in place of an open recordset -- particularly in an OLTP system. If using ADO to get the data, a GetRows should be used to put the data into an array, thus allowing you to close the recordset and db connection as soon as possible. In high throughput systems, you want to close the rs right away, freeing the resource for the next transaction. Also, accessing the data via array is significantly faster than using a recordset object -- another important performance gain in OLTP systems. If you don't use arrays because arr(3) is unreadable, then you are throwing away one of the most powerful tools at your disposal. Also, you can certainly use constants to make em more readable if you prefer (and I do this from time to time in my own code) -- for example something like this

Const CUST_ID = 0
Const CUST_NAME = 1
Const CUST_ADDR = 2
...
'' populate arr via GetRows ADO method
...
''
Response.Write arr(CUST_ID, i)
Response.Write arr(CUST_NAME, i)
Response.Write arr(CUST_ADDR, i)

[Ubik]

I love using arrays as recordsets and I do it in all my code.

function aGetRecords (strSQL)
    dim conn, rs
    Set conn = Server.CreateObject("ADODB.Connection")
    conn.open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=mydata.mdb;"
    Set rs = Server.CreateObject("ADODB.Recordset")
    rs.open strSQL, conn
    if not rs.BOF and not rs.EOF then
        aGetRecords = rs.GetRows
    else
        aGetRecords=""
    end if
    rs.close
    conn.close
    Set rs = Nothing
    Set conn = Nothing
end function

function aChangeRecord (strSQL)
    dim dbaseConn
    Set dbaseConn = Server.CreateObject("ADODB.Connection")
    dbaseConn.Open("Driver={Microsoft Access Driver (*.mdb)}; DBQ=mydata.mdb;")
    dbaseConn.Execute(strSQL)
    dbaseConn.Close
    Set dbaseConn = Nothing
end function 

[dua]

hi there, i'm Z from Malaysia. Sorry for bugging all of you but could you guys lend me a help?

right now i was in third year of my computer science studies, and are undergo practical training in order to complete my diploma. What is bugging me is that, in my college, i was taught how to use some basic software and hardware. I am well if it comes to visual basic 6.0. But right now, i was given a task of upgrading a window-based system (completely using microsoft access) to a web-based system.

i've done most of the interface of all the form. the original system has 21 form to begin with.. right now, i'm having trouble in:
1) producing the script/code program for the system.
2) Connecting the web-site with the database
3) generate the log-in scheme..

I've been given until 31st January 2008 to finish the project since it will be launched on 3rd Feb.. Please help me, i need all the help i can have right now.. it's really bugging me since i was REALLY a newbie.. If you agree i would gladly sent you the project for your reference... thanks for the time..

[Kuriyama]

Design First, Code Later
Spend more time in the design phase than the coding phase. The more you think out your problem and research it the better off you will be in the long run.

Use Classes
They are great for encapsulation and you can move a lot of your business logic into these classes. Try to separate your business logic layer and your presentation layer.

Make Code Flexible
Do not code to make something work, code things with changes in mind so that if your boss asks you to change a piece of functionality you don't suffer by "reinventing the wheel"

Make A Custom 500_100 Error Page
Without some sort of error tracking system you will not be able to tell if code is failing.

Hope this helps.

[cheochi]

Fantastic information.....Thanks for tips

[TheTechguys]

VBScript is the default programming language that is encoded in ASP, so if you want to specify a different programming language which should clarify any programming language that will be used at the very beginning of the code. Less than one line of code that should be your first line of the ASP code or your last page will break and you will get an error message...