Database Reference
In-Depth Information
Table 13.3.1: Questions and Answers About Why You Need Naming Conventions.
Question
Answer
Who
All data systems should have naming conventions.
What
These are written definitions of where data, code, and output files are stored.
When
Naming conventions should be defined before any code or data is prepared.
Where
These should apply to all source data providers, programmers, and users of the system.
Why
So you can find what you need when you need it.
Of course, Table 13.3.1 is just a little light-hearted humor about naming conventions. But, those simple
phrases speak volumes. The proper naming conventions can make or break a software system. When you
walk into a programming job where the system has no naming conventions, it may be hard to find two
people who think the data is in the same place. Some guidelines that I use when setting up a system of
naming conventions is to look at how and when the data is processed. I look for the following.
●
How often is the data processed? Is it updated hourly, daily, weekly, monthly, quarterly, semi-
annually, annually, or even every
x
number of years?
●
How is the data grouped? Is it by task, file, report, company, department, individual, state, county,
zip code, country, or not at all?
●
Are project data and code files stored in development directories, source directories, work
directories, data directories, production directories, archive directories, or any other directories?
•
Has the project team created either a project task flow or a written definition of the project? Sorry,
I know I am just dreaming.
When working on a team to define naming conventions, I tend to place parts of the naming convention that
are most stable in the first directory position and work from there. Common code source libraries should be
separate, but project- or report-level source code should be near the project. It is hard to build a naming
convention that is wrong if first you think about how your data inputs, master data files, and project output
flow. But, remember that some operating systems have limits on the number of characters that can be in a
file path and name.
13.3.2 Set Up Workstation Options
Why is there a section in this topic about setting up workstation options? The reason is simple; the code is
not simple. The Macro Library Tool reaches beyond where most programmers ever venture in their
programming experience. Occasionally, you may see a job posting asking for someone who knows
something about the “Internal Workings” of system
x
or software
y
. What they are really asking for is
someone who can make the system do what they want, not someone who knows how to use a system to get
output. I know that sounds almost the same, but let me explain. Getting SAS to write a *.csv file, and then
manually opening Excel to read the file and create a graph is getting output from a set of programs. But,
writing a SAS program that will pass data to Excel and maintain control while Excel creates a graph that is
ready to print is making a system do what you want.
The features described here were accessible to me both on my own system and at locations where tools
similar to these were installed for departmental use. That does not mean that your system will allow all of
these changes. Digital signatures can be added to programs you write for use on your own computer. This
section is designed to prepare you for some of the actions you may need to perform to make these tools
work properly.
Other messages that may appear could be something like the ones in Figure 13.3.2. This message talks
about trusting the Visual Basic Project code. If you see a similar message, it may be slightly different
depending upon the version of Excel and the operating system you are using. Figure 13.3.2 is a message
displayed when Excel was called from a *.VBS script. Figures 13.3.3, and 13.3.4 show you what actions
you need to take to correct this issue. Once you get this fixed, you should not see it again on the same
computer.
Search WWH ::
Custom Search