Never build large apps
The secret to building large apps is NEVER build large apps. Break up your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.
Admit what you don’t know
The only thing that’s guaranteed not to change is change. Therefore, never act like you know how your app will grow and change. Nicholas Zakas said it well:
The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don’t know everything, you begin to design the system defensively.
- Names of directories and files should be all lowercase. Add hyphens between words.
- Variable names should be camelCase.
- Objects (functions) meant to be instantiated should start with a capital letter.
Strongly-typed languages (e.g., Java, C#, ActionScript 3) specify the type of each variable throughout the application. This means the compiler can raise red flags when you try to use an object in a manner that wasn’t intended by its type. In essence, strong typing can be considered to be a bunch of built-in, simple unit tests that are run each time the app is compiled.
There are many JS libraries available to help you test your code. QUnit seems to work well and is popular. If you don’t already have a favorite, I suggest to start there and research outward.
JsTestDriver can also be very useful (and happens to have a QUnit adapter). JsTestDriver allows you to run your tests within a variety of browsers. This can be very helpful since browsers aren’t consistent in their implementation. For example, I might write code using
myArray.indexOf() which will work on most browsers but not older Internet Explorers. By running your tests within actual browsers these issues will crop up and you’ll find out about them before your users do.
- Strict mode prohibits some syntax likely to be defined in future versions of ECMAScript.
I highly recommend invoking strict mode to keep your code squeaky clean.
Code Analysis Tools
A couple popular code analysis tools exist to likewise help decrapify your code. They scan your code and raise flags when they see you’ve done something dangerous or undesirable. They mainly focus on syntax, style, and structure. They do not verify that your logic is correct.
JSHint is a fork of JSLint, the tool written and maintained by Douglas Crockford.
The project originally started as an effort to make a more configurable version of JSLint—the one that doesn’t enforce one particular coding style on its users—but then transformed into a separate static analysis tool with its own goals and ideals.
Both tools have online versions where you can copy-paste a snippet into a textarea and have the code analysis do its thing. This works okay for bits of code here and there, but even better is setting up the analysis code to run on your full app. Both tools have integrations to you allow you to analyze your app’s code from your IDE or command line. On our team, we run the tool from an Ant script that we can then run from the command line, our IDE, or our deployment servers. I highly recommend you run these tools often right off the bat. Note that each have flags you can set to be more or less strict in its analysis.