Web Development Tips

Don't clutter your page

In attempt to cram as much information possible into a 15" screen, many websites become way too busy and distracting. Remember the main 2 purposes of a website - users want to find information, you want them to find information. Therefore, you want the website to be easy to navigate, easy to find what they are looking for, and pleasing to the eye. 50 advertizements, with blinking flashing marquees, bold red text, links thrown all over the place, will not meet this goal, it will just make things confusing. Have a navigation bar somewhere that from page to page remains consistent and familiar, and hopefully in the same place for each page, have each page give the information it's intended to give, and nothing more (provide links to other pages obviously), make use of whitespace to separate paragraphs, advertisements, images, and use colors correctly: in another tip I will tell you about primary, secondary, tertiary and the use of complementary colors in websites.

Using cookies

You can use cookies (local files) to store information instead of having to post variables back and forth between pages. It's easy - just use the request.cookies and response.cookies objects and methods. To save a value to a cookie, simply create a value, such as oranges: response.cookies("oranges") = 13 -- now you have a cookie on your computer with a key name of "oranges" which has a value 13. To retrieve the information, use the request.cookies method as: myVar = request.cookies("oranges") which will retrieve the value 13. You can also use the cookies as collections, such as response.cookies("oranges")("navels")=13. Now you have 13 Navel Oranges stored. To retrieve, use the same format: myVar = request.cookies("oranges")("navels").

Close those objects!

When you instantiate an obbect, such as a connection, recordset, filesystemobject, etc., remember to .close them, and to also set them to "nothing". Each time an object is created, memory is used up. Yes, when you exit a function the object instantiated within them go out of scope and supposedly are close, but it's a good programming practice to close and free up anyway.
For example:
dim rs
set rs = getUsersRS()
if not rs.eof then
do while not rs.eof

'do something here
rs.movenext
loop
end if
rs.close
if not rs is nothing then set rs = nothing

this effectively kills off the recordset object rs.

Standards

When starting a new project (or jumping into an existing project) define a set of standards for function and variable names. This may sounds simple and maybe even irrelevant, but creating a document defining these standards will go a long way towards code management and maintenence. For example, if you prefix every variable or function/sub call with the type of call and the return value (or variable type), use case-consistency, and name functions/variables properly, you only need to glance at a function name or variable name to know what the return value is, whether it's a function, sub or variable, and what it does. Here's an example of a FUNCTION that returns a STRING value of a person's username: fnStrGetUserName(). Here's an example of a global variable, that is a long number, and holds a value of a calculation of a circle: gvLngCircleValue. Pretty self-explanatory. AND somewhat self-documenting. The more readable your code, the less comments you need, the less chance someone might misuse the variable or function (and throw an error), and the better chance someone ELSE will be able to read your code.

Stored Procedures

If you are using a database, try to use stored procedures instead of inline asp database code.

Stored Procedures are scripts that are run on, owned by, and specific to your database. They generally reside IN your database files. If you have ever looked at a very large asp file (I have seen rediculously large 2000+ line asp files - complete with functions, html, database calls, sql text, style information, etc.), and I will tell you it is not pretty, nor is it easy to change, maintain, edit, or even follow. If at all possible, don't have inline sql. If you can access the database, and use stored procedures, not only will it make the code easier to follow, but you'll never have to dig into the code again to make data changes - simply edit the stored procedure on the database, or the function call you create that calls the stored procedure. For a better example, see www.meridiandevelopmentsystems.com/lifetips/05.htm.