First, know how the technology behind it works.
You need to know this because the knowledge behind how it works, because you're going to run into networking issues, or, as I've seen countless times, people entirely faily at understanding what server-side and client-side actually is. One of the most common newb questions I see is "How can I make JS change a variable in my ASP code?!"
- Do you understand ethernet/wifi and TCP/IP to have a general idea of what's going on?
- How much HTTP do you actually know?
- Do you actually get HTML? Sure, you might know how tags work and nest stuff, but do you actually understand doctype and quirks mode? Do you understand that you shouldn't put paragraph tags around a list element?
- Learn the Window API, learn the DOM API, and learn the XHR API. If you don't know these three things you have no business writing code for the browser.
Understand your code is bigger than you, or your specific situation
- Sure, you wrote something, but everyone can see it. It's all "open" source. Sure, you can obfuscate it, minifiy it, whatever... at the end of the day, if I want to see you code, it's trivial for me to defeat any methods you put in place.
- You need to understand multiple browsers differences. Target the most popular ones, or the ones your market demographic has. For instance, ie6 won't render DOM table-cell elements if you appendChild rather than the DOM API methods specifically for tables. More examples exist, you need to learn them.
- You need to understand how to write code around all of these issues in browsers, not your specific browser. You'll quickly learn things that work well in one browser are slow in another. You'll have to figure out how browsers work and why they're different.
- For the love of Odin's beard, don't write code that permits me to do cross-site-scripting attacks on your code. If you make an ajax call to a cell and do something like
cell.innerHTML = "<script>alert("xss")</script>", and an alert box shows up, you've done it wrong.
- When you come for guidance, or want to share that really cool thing you made... please, pretty please. Please, make sure you documented it, make sure your variable names make sense, make sure it's not all one-lined. You need to write clean code. If you have a pile of garbage, not only have you failed, nobody who knows how to help you will want to. Help us help you.
<noscript> tags to alert them as to such.
- The western world of English speaking white kids isn't who uses the internet. Code accordingly. This means you need to understand internationalization, and writing code that deals with higher demand. 10 years ago there were less than 500 Million people on-line, today it's roughly 2 billion, and in another 10 years? Probably close to every person on the planet will have internet access, that means you need to support names that don't fit the regex of
/[a-z ']/i, but include Hindi, Arabic, accents (this is an existing problem from short-sighted developers), Chinese, and others. Understand character sets, Unicode and UTF-8.
You're a programmer, not a pasta factory. Stop writing spaghetti.
- Name your variables after things that make sense.
- Document your code. I don't care if you're using JSDoc powered by rhino or you have a bunch of scribbles. Write documentation that helps the person who is going to use your code. Write documentation for someone who wants to improve or maintain your code. Include useful comments. Comments like
"This fizzes the bizz" or ones half-English half-french aren't helpful. Describe what a function does. Describe complex sections of code.
- Figure out how to limit repetition of code. Look for modular design or functional patterns. See what you can abstract. You should never end up cutting+pasting+tweaking large segments of code to do the same thing.
Figure out how to write code in such a way it does't break all the time.
- Use static code analysis tools. These will alert you right-away to all the little "oops" you made when writing your code. Forgot a semicolon somewhere? Oh, there it is. Have a global somewhere? Oh, there it is. Code that might throw a bunch of mystery errors when you try to run it? OH! There they are! No more screwing around and staring into a pile of code for hours trying to figure out something that's just a syntax error. (Well, hardly any, you might have done something it can't catch, but it's generally awesome).
- Unit test. There's no reason not to be. There's tons of unit testing tools out there. Basically, unit testing is "Here's my function" and "I want it to output Y" "Here's some test inputs" And the test is "Did they all work?" There's many JS testing frameworks, like the popular QUnit. Take a tour through your favorite search engine and see what tickles your fancy. But use them.
- Source control management, also known as version control. Git's popular, and with good reason. So is SVN and a few others. What you need to stop doing this very instant is editing production code. You need to stop renaming files
main_backup_20110911.js.bak.1 You lose stuff, your directory gets messy, you can't easily "rewind" to a previous point in time. You can't see what's going on, you can't make code patches. So, just start learning GIT, it should take you an hour and you'll never go back.
- Peer review. You're not that good, neither am I. I get better by asking for feedback as much as I can. That's how you should do it too.
- Figure out why your code is slow. Use jspref and create tests.
- STOP using innerHTML to edit the DOM. This goes back to learning what HTML is, and learning what the DOM is. HTML is data sent from the server that your browser rendering engine uses to create a bunch of programming objects that end up being a Document Object. When you use innerHTML you're asking your browser to re-render the whole thing. Thankfully, like way over 10 years ago, we created the DOM API, and it lets you "append child" or "create text node," without having to update the whole thing. innHTML is a disgrace that Microsoft invented -- if you use it, you also lose all privileges to whine about IE6 being awful because you're helping it's garbage stick around forever. Learn the DOM.
- It needs to work everywhere it can. If something isn't supported, it needs to degrade gracefully so the experience doesn't suck-- you can't just slap your users in the face and crash.
- Copyright and licence are important. Don't rip-off other people's hard work. If someone says "not for resale," you can't sell it. Don't be a jerk, or we'll hate your code for ripping off hard-working-people.
Focus on the basics, always.
- You're wrong, and that's awesome, because you know something now. Nothing is worse than someone who won't admit to being wrong and keeps slamming bad code out the door like they're some renegade rock-star superhero ninja. They're just fools. Admit you can be wrong, admit you might be wrong, ask for help.
- You don't need cut+paste+tweak, make DRY code. I've mentioned this before, but it's important here as well. You can't write quality code if your code base is a disgrace.
- Don't abuse arrays/object differences, learn how to loop. Learn why you use a
for (;;) and why you use a
for( in ) loop. When to use a while loop. Stop nesting IFs when you can just use a switch case. Objects do not preserve order, so don't use them as an array; old Opera/FF, old MISE, sometimes Flash won't respect the order of your objects. Use an array if you want to keep an order of things, use an object if you want an object (something that doesn't have order of elements).
- How decision structures can be used to your advantage, not add complexity to your code. Stop nesting IFs, figure out how Boolean logical operators work. Figure out how switch-case works.
- RTFM. The best place to learn about better code is by reading the actual spec. Read the RFC specs on that part of code you're trying to use. Read the ECMAScript document. Read the W3C DOM spec. Read the W3C XHTML/HTML/HTML5 spec. Read the specs, they're good.
Focus on the long game, not a quick flash and die.
- You should help the community, you should write code that will be around for a long time. Have some passion about your code and community. If you left bad knowledge somewhere, go the hell back and fix it. Bad information is really hard to purge and sticks around for ever. Do your part. Don't help w3schools make the web worse.
- Don't jump in from nowhere and say "Hey I got a great idea for how to use
which" drop a bunch of code that nobody can use and disappear. You contributed nothing. Don't use variables like
- Learn to spot the bad code and the good code, find it in your own code, make your bad code into good code.
- Create something, learn something, teach something.
- You're still wrong, even when you do know everything. Use a proof to be correct, not your status/authority. You can never be right, but your proof is always correct. Don't get into pissing matches, as hard as it is to avoid sometimes. Either there's proof or there isn't. Flames help nobody.
For anyone interested, I've actually taken most of this from personal notes on a tutorial I'm nowhere done writing.