Kida's World

JavaScript Tips

1 - Unnecessary DOM Manipulation

The DOM is slow. Limiting your interaction with it will greatly increase your code’s performance. Consider the following (bad) code:
This code actually modifies the DOM 100 times, and unnecessarily creates 100 jQuery objects. 100! A more correct approach would be to either use a document fragment, or build up a string that contains the 100 <li/> elements, and then appends that HTML to the containing element. That way, you jump into the DOM a total of once. Here’s an example:
As noted above, with this technique, we touch the DOM only once, which is an improvement, but it also relies on string concatenation to build a large string. There’s a different way that we could approach this, using arrays.
When building large strings, storing each piece of the string as an item within an array element and calling join() is more efficient than string concatenation. This is one of the fastest and easiest ways to build repetitive HTML in JavaScript without using a template library or framework.

2 - Inconsistent Variable & Function Names in JavaScript

This next item isn’t a performance issue, but is extremely important – especially if you are working on code that other people work on, as well. Keep your identifiers (variable and function names) consistent. Consider the following variables as an example:
It wouldn’t make sense to add another variable, called Something. This introduces inconsistency in your variable naming pattern, causing your brain to cognitively flag this variable as being different or special. This is why constants in most languages are traditionally defined with all caps.
You can take this a step further by maintaining similar length, grammatical structure, and explanatory nature when naming functions. For example, consider the following contrived function:
Naming a function that adds five to a given number should follow the same pattern, shown here:
Sometimes, you might name a function to indicate its return value. For instance, you might name a function that returns an HTML string getTweetHTML(). You might also prepend a function’s name with do, if the function simply performs an operation and doesn’t return a value, eg: doFetchTweets().
Constructor functions typically follow the tradition of classes in other languages, capitalizing the first letter:
As a general rule of thumb, you should be descriptive when naming your identifiers. Classify them together with other similar identifiers by maintaining a naming pattern that is readable and offers hints to the nature of a variable or function’s purpose.

3 - Use hasOwnProperty() in for...in Loops

JavaScript’s arrays are not associative; trying to use them as such is frowned upon by the community. Objects, on the other hand, can be treated as hash tables, and you can iterate over an object’s properties by using the for...in loop, like so:
The problem, however, is that the for...in loop iterates over every enumerable property on the object’s prototype chain. This can be problematic if you only want to use the properties that exist on the actual object.
You can solve this issue by using the hasOwnProperty() method. Here’s an example:
This version only alerts the values of the properties that directly reside on someObject.

4 - Comparing Boolean Values

Comparing boolean values in a condition is a waste of computation time. Take a look at the following for an example:
Notice the condition: foo == true. The comparison of foo and true is unnecessary because foo is already a boolean value (or it’s a truthy or falsey one). Instead of comparing foo, simply use it as the condition, like this:
To test for false, use the logical NOT operator, as shown below:

5 - Event Binding

Events are a complicated subject in JavaScript. Gone are the days of inline onclick event handlers (except in some very rare “splash page” cases). Instead, use event bubbling and delegation.
Let’s imagine that you have a grid of pictures that need to launch a modal lightbox window. Here’s what you shouldn’t do. Note: we’re using jQuery here, assuming you are using a similar library. If not, the same bubbling principles also apply to vanilla JavaScript.
The relevant HTML:
The (bad) JavaScript:
This code assumes that calling the lightbox involves passing an anchor element that references the full size image. Instead of binding to each anchor element, bind to the #grid-container element instead.
In this code, both this and event.target refer to the anchor element. You can use this same technique with any parent element. Just make sure to define the element that should be the event’s target.

6 - Avoid Ternary Redundancy

The overuse of ternary statements is quite common both in JavaScript and PHP.
A condition expression always returns a true or false value, meaning you don’t need to explicitly add true/false as ternary values. Instead, you could simply return the condition:

---

PHP Tips

7 - Use Ternary When Appropriate

if...else statements are a central part of most languages. But doing something simple, such as assigning a value to a variable based upon a condition – well, they can junk up your code. Consider the following code:
This code can be reduced to one line, while still maintaining readability by using the ternary operator, like this:
It’s clear, concise, and gives you the functionality you need.

As useful as the ternary operator is, the most important guideline is not to over-use it! The goal of coding is not to cramp your logic into as few lines as possible.

8 - Throw Exceptions Instead of Inception-Style Nesting

Let’s face it: many levels of nesting is ugly and difficult to maintain/read. The following code is a relatively simplified example, but they get much worse over time:
That’s some nasty code, but you can make it drastically cleaner by using exceptions, like so:
It might be the same number of lines, but it allows for considerably more readable and maintainable code. It also avoids those difficult debugging sessions, where you’ve missed a possible path through the if statement. Keep it simple!

9 - False-Happy Methods

Being exception-happy is far more advantageous than being false-happy.

Ruby or Python developers are used to watching for trivial exceptions. While that sound tedious, it’s actually quite a good thing. If anything goes wrong, an exception is thrown, and you instantly know where the problem is.
In PHP – and especially when using older frameworks, such as CodeIgniter – you get what I refer to as “false-happy code” (as opposed to exception-happy). Instead of having an exception get all up in your face, it just returns a false value and assigns the error string to some other property. This forces you to fish it out of the class using a get_error(); method.
Being exception-happy is far more advantageous than being false-happy. If an error occurs within your code (eg: could not connect to S3 to upload an image, or a value is empty, etc.), then throw an exception. You can also throw specific types of exceptions by extending the Exception class, like so:
Throwing a custom exception makes debugging considerably easier.

Tip 10 - Use Guard Clauses

It’s common to use if statements to control a function or method’s execution path. It’s tempting to test a condition and execute a lot of code when the condition results in true, only to simply return in the else statement. For example:
This kind of solution, however, represents a potential for spaghetti code. You can make this code easier to read by reversing the condition. Here’s the better version:
Isn’t that easier to read? It’s a simple change that makes a drastic difference in the readability of your code.

Tip 11 – Use while for Simple Iterations

The for loop is commonly used when you need, for example, a counter. Here’s a simple for loop:
There are some very good reasons to use a for loop, but a while loop may be better if you just need something simple, like this:
It doesn’t work in every situation, but it is an alternative.

Tip 12 – Keep Methods Maintainable

This is easily one of the most frequent mistakes made by newcomers.

A method is an object’s unit of work, and limiting your methods to a maintainable size makes your code easier to read and maintain. Take a look at the following monster method:
Consider breaking this monster method into smaller, descriptive chunks, each being responsible for performing one well-abstracted action. This is easily one of the most frequent mistakes made by newcomers.
There we go: cleaner, and easier to debug!

Step 13 - Avoid Deep Nesting

Too many levels of nesting makes code difficult to read and maintain. Consider the following:
You can refer to Tip #10 to make this code easier to read by reversing some of the conditions.
This code is considerably cleaner and produces the same results as before.
When you find yourself with nested if statements, closely examine your code; your method may be performing more than one task. Here’s an example:
In these cases, extract the nested methods into their own method:

Tip 14 – Avoid Magic Numbers and Strings

Magic numbers and strings are evil. Define variables or constants with the values you want to use in your code.
Instead of this:
Specify what those numbers and strings mean, and assign them to a variable with a meaningful name, like this:

While some might argue that we’re needlessly creating variables, the performance hit is negligible. Readability always takes priority. Remember: don’t optimize for performance until you can describe why it’s necessary.

Step 15 - Use Built-In Array Functions

Use the built-in array functions instead of foreach().
Not Ideal:
Better:
PHP offers a variety of array methods. They’re confusing at first, but take a day and try to learn as many as possible.

Tip 16 - Don’t Overuse Variables

It’s easy to overuse variables, but remember that variables are stored in memory. For every variable you create, the system needs to allocate memory for that variable. Look at this code:
The $result variable isn’t necessary. The following code omits that variable:
The difference is subtle, but we were able to improve this simple example. We kept the $query variable because it relates to the database, while $result related more to our logic.

---

General Programming Recommendations

Tip 17 - Rely on the Database Engine

Anything less is a code smell.

A database is designed for working with data; use its tools and abilities to make your application more efficient.
For example, you can avoid redundant database queries in many circumstances. Most plug-and-play user management scripts use two queries for user registration: one to check whether the e-mail/username already exists and another to actually add it to the database. A much better approach is to set the username field to UNIQUE. You can then use native MySQL functions to check whether or not the record was added to the database.

Tip 18: Properly Name Your Variables

The days of naming your variables x, y, z are over (unless, of course, you’re dealing with a coordinate system). A variable represents an important part of your logic. Don’t want to type a long name? Get a better IDE. Modern IDEs auto-complete variable names in a blink of an eye.

Always be coding for six months from now. Are you certain that you’ll remember what that $sut variables refers to a year from now? Likely not: be descriptive. Anything less is a code smell.

Tip 19 - Methods Represent Actions

Mistakes happen; the key is to learn from them.

Name your methods with verbs representing the action they perform. The main concept is the exact opposite of the variable naming scheme. Use a short, but descriptive, name in a large scope (ie: public methods), and use a longer and more detailed name in a short scope (ie: private / protected methods). This helps make your code read like well written prose.
Also avoid any language other than English, when naming your methods. It’s annoying to read function names like 做些什麼() or делатьчтото() in your project. It may be impossible for other programmers to understand your intent. While it might seem arrogant, for better or worse, English is the adopted language of code. Try to use it, if we’re working on a large team.

Tip 20: Structure Recommendations

Finally, code structure is just as important to readability and maintainability as anything else we’ve talked about today. Here are two recommendations:

• Indent with four or two space-width tabs. Anything more, such as eight spaces, is too much and will make your code difficult to read.
• Set a reasonable line-width and respect it. Forty characters in a line? We’re not in the ’70s any more; set your limit to 120 characters, put a mark on the screen, and force yourself or your IDE to respect that limit. 120 characters gives you a nice width without making you scroll.

---

Conclusion

“I’ve never made a stupid programming mistake.” — No one, ever.

Mistakes happen; the key is to learn from them. We at Nettuts+ have made, and will continue to make, mistakes. Our hope is that you learn from our mistakes so that you can avoid them in the future. But, to be honest, the best way to learn best practices is to make the mistakes yourself!
Thanks for reading!