A rule of thumb with code is to keep the scope as small as possible. That way if the code changes or breaks, then it affects a smaller scope. That said, I confess that over the years I have written code at a larger scope than I have needed to. Shame on me! In my defense, the temptation to code a larger scope is high because programmers are "intelligently" lazy and we don't like to repeat work. However, even worse than repeating work is broken code.
- Library used on multiple-sites.
If the code does the same thing whether it's client-side or server-side, then name it the same thing. In mixed environments, it is hard to debug code that has prototyped on global objects like String or Date, hence I prefer to make stand alone functions or prototype onto my own objects.
The first line of these files is usually something like this depending on the development environment:
The first line of these file is usually something like this depending on the development environment:
<% %><% //To temporarily view this ASP page as pure JavaScrpt in UltraEdit, comment out this line. Similarly for VisualStudio, temporarily add the ASP Processing Directive.. The last line of these files is usually something like this:
I used to include the ASP processing directive and lines like the following in my server-side include, but then I lost the option to vary those things depending on the page.
Response.Buffer = true; Response.CacheControl = "no-cache"; Response.Expires = -1; Response.AddHeader("Pragma", "no-cache");
- SS_00010101.js. gen.
- SS_20080319_1046.js. gh.
- SS_20080608_1356.js. c. With gob (global object).
- SS_20080608_1624.js. ic.