Scripting Patterns - SQL Server Integration Services Design Patterns - page 122

Figure 3-10 . Script task variables must be cast
Naming Patterns
If you have worked as a software developer in the past, the following section will be
nothing more than a review. If you haven't, I'll share an important tidbit of informa-
tion: naming conventions are important.
I've known many a developer in my time, and I've never found one who wasn't
loyal to some type of naming convention. Why? It's familiar. It's predicListing. When
patterns emerge in the way you develop software, it becomes easier to maintain—by
others as well as yourself. Technically, there's no difference between code written in
camel case, Hungarian notation, mnemonic notation, or Pascal style. This is purely a
matter of clarity, readability, and maintainability. By finding and sticking with a style
(even if it's a hybrid of other styles), you'll have more navigable code and will likely
find that your fellow developers appreciate the approach.
Here are a few suggestions regarding naming conventions:
Be consistent: This is the number-one rule and should be followed
above all others. Whatever style you develop, stick with it. You can
change or modify your naming convention style later, but at least be
consistent within each project.
Be clear: I can't tell you how many times I've had to debug code
(and yes, sometimes it was my own) littered with single-character ob-
ject names, ambiguous function names, and other pull-your-hair-out
kinds of practices. Now, don't go overboard here. Most object names
don't need to read like data-
base_write_failed_and_could_not_display_interactive_error ,