## 3. Single Letter Prefixes

You've surely, at some point, come across a variable that was proceeded by a single letter, such as "s" or "i".

This is referred to as Hungarian notation, and has fallen out of favor in recent years, though it's still a convention that's used by many companies.

Hungarian notation is a naming convention that reminds the developer about the type of variable that he's working with: string, integer, etc.

Particularly in the JavaScript world, this practice is frowned upon, due to the fact it's a loosely typed language. A loosely typed language is one that doesn't require you to declare the data type of a variable. Why is that significant? What if, using the notation convention above, we declared a string with the "s" prefix, but then later changed the variable to an integer? At that point, this form of notation would in fact work against us, not for us.

### The Dollar Symbol

jQuery users: before you step on your pedestal and praise yourself for not using this form of notation, ask yourself if you prefix variables - wrapped in the jQuery object - with a dollar symbol? If so, that's a form of Hungarian notation. It's a symbol prefixed to a variable name which serves the sole purpose of informing you of the variable's type or qualities.

#### Should You Use It?

That's entirely up to you. Even many jQuery team members use the dollar prefix method. Ultimately, if it works for you, that's all that matters. Personally, as of about a year ago, I don't use the dollar symbol prefix any longer -- but only because I realized that it wasn't necessary for me. Make up your own mind on this one.

## 4. Capital First Letter

What about those "variable" names, which capitalize the first letter of the name?

In the code above, \$SomeClass is capitalized because it is a class and not a variable name. Again, this is a naming convention that most developers use. When returning to the code a year later, it's a small lightbulb that informs them that they're working with a class, which has objects and methods available.

### The JavaScript World

In JavaScript, we don't really have classes; but we do have constructor functions.

The reason why we capitalize the name of the constructor (Person) is because it can prove easy to sometimes forget the new keyword. In these circumstances, JavaScript won't throw any warnings, and it can be a nightmare to track down the glitch. The capitalization is a helpful alert for the developer, when debugging. Douglas Crockford is a big advocate of this convention.

Alternatively, if you want to protect against your future self's forgetfulness, you could first ensure that the constructor is, in fact, correct, before proceeding.

## 5. CamelCase vs under_score

Why is it that some variables use a camelCase pattern,while others use an underscore to separate words? What's the correct method? The answer is there is no correct usage. It entirely depends on the language, and/or your company's coding conventions. Both are perfectly acceptable.

However, with all that said, it's a best practice -- when you have the option -- to follow the common conventions of the language you're using. For example, the large majority of JavaScript developers use the camelCase syntax, while other languages, like PHP, tend to prefer the underscore usage. Though, again, this isn't set in stone. The Zend Framework advocates camelCasing as a best practice.

More important than what you use is ensuring that you stick to it!

## 6. Directory Structure

Particularly when working on a team, it's essential that you adopt the proper directory structure as your fellow developers. But, at the very least, certainly don't drop all of your stylesheets and scripts into the root of your project, without any organization. Many developers prefer to place all of their images, scripts, and stylesheets within a parent Assets directory.

Also, note the convention of also creating a min folder, which contains the dynamically added minified versions of your scripts and stylesheets.

## 7. Semantics

When creating mark-up, hopefully, it's widely understood that the ids and classes you choose should describe the type of content, and not the presentational aspects. As an example:

#### Best

How come? What if, six months down the road, you decide to place your Justin Bieber fan section in the middle-RIGHT-and-then-a-little-lower section? At that point, your id will make little sense.

As we transition into an HTML5 world, you should find yourself using far fewer identifiers in your elements. ids are less flexible, and are many times unnecessary.

## 8. Double Headers and Footers

You know what stinks? When working on a centered website that requires multiple backgrounds that extend for the entire width of the window (usually for the header and footer), you typically have to wrap your content so that the outer element will extend, while the inner element can remain centered.

As this is a common issue, it's important to adopt a common convention for creating the necessary mark-up.

The difficult decision here is that, assuming you're working with the new HTML5 elements, you have to decide whether to place the footer element on the inside or the outside. It's still up for discussion, however, I tend to feel that it's more semantic to place the actual footer element on the inside.

divs should be used only when:

• There's no better element for the job
• When your need of the element is purely to structure a layout

## 9. Shortcuts

Decide now whether or not you're going to allow the use of shortcuts in your code. Writing precise/clean code is always a battle of readability vs. size. This is why it's paramount that development teams follow the same coding guidelines. To provide two quick examples:

#### What About the Logical && For Short-Hand Conditionals?

Many developers will frown upon the use of the logical AND in this case, insisting that it limits readability. This is certainly a valid argument, though, nonetheless, even popular libraries like jQuery make heavy use of this method.

## Conclusion

To reiterate, the specific conventions you choose are far less important than ensuring that you remain consistent with your usage. In fact, many development teams write their own convention guidelines for new dev hires. Thanks for reading!