CodeAve.com CodeAve.com - ASP - Articles
ASP
·Read/Write
·Script Writers
·Database Display
·Response Objects
·Server Variables
·Random Events
·Articles
·Miscellaneous
·Contents
·What's New?
JavaScript
CSS
HTML
Maps
Links
Mail List
Search
Sitemap


 


Some Words on Naming Conventions
When you're developing applications there are two real dangers in poor naming conventions.

Firstly, you may hit on a reserved term. Take where for example. If you were to write a query that looked something like this 
sql = "select * from cities where" & where &"= 'New York' "

You would get an error because where is a reserved term. There are many combinations that are reserved and depending on a multitude of factors you could be using them directly like the example above or in the course of url encoding the name of a variable like reg could be converted to &reg which will produce the registered trademark symbol ®. 

To avoid this type of problem a list of reserved terms could be posted here with a big DO NOT USE THESE OR ELSE banner blazing at the top and with every new version of this or that it would have to be revised. To completely avoid this kind of problem what is encouraged at CodeAve.com is the following:

Any user inputted value starts with u_
Following this convention the example above would look like this
sql = "select * from cities where" & u_where &"= 'New York' "
and would work without a hitch.

The example of where a variable named reg would not run into the same problems if it were named u_reg. Utilizing u_ as the signifier of any user inputted values aids in more ways than one. During debugging finding variables is made much easier.

But what about variables that are generated off of user inputted values? Simple we encourage the use of g_ as the signifier for any variable that is a created/modified version of the user inputted value. This method will no prevent error if you db has a field on it named after a reserved term, for example where (location might be a better choice)

The second danger is when the varibles names themselves have no real connection to the data they may hold. If you have a list of possible years for a user to input don't name the variable flood or something that has no real meaning. Use year or as discussed above u_year.


 



ASP: What's New? | Articles | Script Writers | Database Display | Read/Write
Server Variables | Response Objects | Random Events | Miscellaneous
HTML: Forms | Hyperlinks | Headers | Tables | Hyperlinks | Headers | Text Display
JavaScript: Document Info | Forms | Images | Navigation | Script Writers
CSS: Basics | Page Display | Text Display | Script Writers | Miscellaneous
  • 2014 michael kors
  • air max women 2013
  • 2014 michael kors
  • air max 2014
  • oakley glasses
  • oakley glasses

  • Maps: Map Script Writers | Bing Maps | Google Maps
  • bottes fr
  • ugg boot
  • Privacy Statement

    CodeAve.com is hosted by MyHosting.com
    Donate Food Online with a Mouse Click at TheHungerSite.com
    Donate Land Online with a Mouse Click at TheRainForestSite.com
    © 1999 - 2017 CodeAve.com
    All Rights Reserved

  • Kids jordan 6 rings
  • Jordan retro 10
  • Jordan retro 3