The Seven Deadly Sins of JavaScript Implementation

The Seven Deadly Sins of JavaScript Implementation

Summary:

[list=1][]Not Playing Nice With Other Scripts
[
]Believing Instead Of Testing
[]Using The Wrong Technology For The Job
[
]Depending On JavaScript And Certain Input Devices
[]Making Maintenance Unnecessarily Hard
[
]Not Documenting Your Code
[*]Optimizing For Machines, Not People[/list]

The full article makes for a surprisingly good read.

I was wary as it was Smashing, but when I saw it was Chris Heilmann, I thought “bookmark”.

What about Smashing makes you wary?

I don’t agree with the documentation aspect, I maintain my own code and additional comments would just add to unnecessary bloat making it less agile.

PS: I love Smashing Magazine, I don’t know why people are so “iffy” about it. :slight_smile:

And that’s the nature of the beast. You maintain your own code. I suspect that Chris may his advice at situations where multiple people will be working with the code.

Even despite that though, I’ve come across code that I wrote a few years ago and thought WTF? Comments from back then would have been helpful now.

in my opinion, smashing can be TOOOOO MUCH for me to handle.

Code can be self documenting if written properly using appropriate names.

Documenting code does not necessarily mean adding comments to it.

Is there any other book that covers this topic better than Clean Code?

And that’s the nature of the beast. You maintain your own code. I suspect that Chris may his advice at situations where multiple people will be working with the code.

As someone (Gary?) likes to say, even if your code is crystal clear (to you), write it (and any comments) as if the maintainer who comes after you is a psychopathic serial killer who knows where you live. Even if it’s you.