JavaScript: The Good Parts by Douglas Crockford Publisher: O ...

Recommendations

Info

2 1.1. Why JavaScript? JavaScript is an important language because it is the language of the web browser. Its association with the browser makes it one of the most popular programming languages in the world. At the same time, it is one of the most despised programming languages in the world. The API of the browser, the Document Object Model (DOM) is quite awful, and JavaScript is unfairly blamed. The DOM would be painful to work with in any language. The DOM is poorly specified and inconsistently implemented. This book touches only very lightly on the DOM. I think writing a Good Parts book about the DOM would be extremely challenging. JavaScript is most despised because it isn't SOME OTHER LANGUAGE. If you are good in SOME OTHER LANGUAGE and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don't even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the SOME OTHER LANGUAGE they would rather be using, and that those differences matter. The amazing thing about JavaScript is that it is possible to get work done with it without knowing much about the language, or even knowing much about programming. It is a language with enormous expressive power. It is even better when you know what you're doing. Programming is difficult business. It should never be undertaken in ignorance. 2
Chapter 1. Good Parts ...setting the attractions of my good parts aside I have no other charms. â William Shakespeare, The Merry Wives of Windsor When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off, and I suppose it worked because I was the guy you went to if you wanted to know how to use a particular feature. Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes. Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts? It is rarely possible for standards committees to remove imperfections from a language because doing so would cause the breakage of all of the bad programs that depend on those bad parts. They are usually powerless to do anything except heap more features on top of the existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts. But you have the power to define your own subset. You can write better programs by relying exclusively on the good parts. JavaScript is a language with more than its share of bad parts. It went from non-existence to global adoption in an alarmingly short period of time. It never had an interval in the lab when it could be tried out and polished. It went straight into Netscape Navigator 2 just as it was, and it was very rough. When Javaâ ¢ applets failed, JavaScript became the "Language of the Web" by default. JavaScript's popularity is almost completely independent of its qualities as a programming language. Fortunately, JavaScript has some extraordinarily good parts. In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders. The best nature of JavaScript is so effectively hidden that for many years the prevailing opinion of JavaScript was that it was an unsightly, incompetent toy. My intention here is to expose the goodness in JavaScript, an outstanding, dynamic programming language. JavaScript is a block of marble, and I chip away the features that are not beautiful until the language's true nature reveals itself. I believe that the elegant subset I carved out is vastly superior to the language as a whole, being more reliable, readable, and maintainable. This book will not attempt to fully describe the language. Instead, it will focus on the good parts with occasional warnings to avoid the bad. The subset that will be described here can be used to construct reliable, readable programs small and large. By focusing on just the good parts, we can reduce learning time, increase robustness, and save some trees. Perhaps the greatest benefit of studying the good parts is that you can avoid the need to unlearn the bad parts. Unlearning bad patterns is very difficult. It is a painful task that most of us face with extreme reluctance. Sometimes languages are subsetted to make them work better for students. But in this case, I am subsetting JavaScript to make it work better for professionals. 1 1
Page 1 and 2: JavaScript: The Good Parts by Dougl
Page 5 and 6: Section C.9. Expression Statements
Page 9 and 10: Dedication For the Lads: Clement, P
Page 11 and 12: Preface If we offend, it is with ou
Page 13 and 14: I want to thank the people I worked
Page 15: Chapter 1. Good Parts ...setting th
Page 19 and 20: 1.2. Analyzing JavaScript JavaScrip
Page 21 and 22: 1.3. A Simple Testing Ground If you
Page 23 and 24: Chapter 2. Grammar I know it well:
Page 25 and 26: Chapter 2. Grammar I know it well:
Page 27 and 28: 2.2. Names A name is a letter optio
Page 29 and 30: 2.3. Numbers JavaScript has a singl
Page 31 and 32: 2.4. Strings A string literal can b
Page 33 and 34: 2.5. Statements A compilation unit
Page 35 and 36: The switch statement performs a mul
Page 37 and 38: The try statement executes a block
Page 39 and 40: 2.6. Expressions The simplest expre
Page 41 and 42: Invocation causes the execution of
Page 43 and 44: 2.7. Literals Object literals are a
Page 45 and 46: 2.8. Functions A function literal d
Page 47 and 48: Chapter 3. Objects Upon a homely ob
Page 49 and 50: Chapter 3. Objects Upon a homely ob
Page 51 and 52: 3.2. Retrieval Values can be retrie
Page 53 and 54: 3.3. Update A value in an object ca
Page 55 and 56: 3.4. Reference Objects are passed a
Page 57 and 58: 3.5. Prototype Every object is link
Page 59 and 60: 3.6. Reflection It is easy to inspe
Page 61 and 62: 3.7. Enumeration The for in stateme
Page 63 and 64: 3.8. Delete The delete operator can
Page 65 and 66: 3.9. Global Abatement JavaScript ma
Page 67 and 68:
Chapter 4. Functions Why, every fau
Page 69 and 70:
Chapter 4. Functions Why, every fau
Page 71 and 72:
4.2. Function Literal Function obje
Page 73 and 74:
4.3. Invocation Invoking a function
Page 75 and 76:
document.writeln(myQuo.get_status(
Page 77 and 78:
4.4. Arguments A bonus parameter th
Page 79 and 80:
4.5. Return When a function is invo
Page 81 and 82:
4.6. Exceptions JavaScript provides
Page 83 and 84:
4.7. Augmenting Types JavaScript al
Page 85 and 86:
4.8. Recursion A recursive function
Page 87 and 88:
4.9. Scope Scope in a programming l
Page 89 and 90:
4.10. Closure The good news about s
Page 91 and 92:
}; } } // END BAD EXAMPLE The add_t
Page 93 and 94:
4.11. Callbacks Functions can make
Page 95 and 96:
4.12. Module We can use functions a
Page 97 and 98:
4.13. Cascade Some methods do not h
Page 99 and 100:
4.14. Curry Functions are values, a
Page 101 and 102:
4.15. Memoization Functions can use
Page 103 and 104:
Chapter 5. Inheritance Divides one
Page 105 and 106:
eturn s; }; Cat.prototype.get_name
Page 107 and 108:
Chapter 5. Inheritance Divides one
Page 109 and 110:
eturn s; }; Cat.prototype.get_name
Page 111 and 112:
5.2. Object Specifiers It sometimes
Page 113 and 114:
5.3. Prototypal In a purely prototy
Page 115 and 116:
5.4. Functional One weakness of the
Page 117 and 118:
}; for (i = 0; i < n; i += 1) { if
Page 119 and 120:
5.5. Parts We can compose objects o
Page 121 and 122:
Chapter 6. Arrays Thee I'll chase h
Page 123 and 124:
Chapter 6. Arrays Thee I'll chase h
Page 125 and 126:
6.2. Length Every array has a lengt
Page 127 and 128:
6.3. Delete Since JavaScript's arra
Page 129 and 130:
6.4. Enumeration Since JavaScript's
Page 131 and 132:
6.5. Confusion A common error in Ja
Page 133 and 134:
6.6. Methods JavaScript provides a
Page 135 and 136:
6.7. Dimensions JavaScript arrays u
Page 137 and 138:
Chapter 7. Regular Expressions Wher
Page 139 and 140:
Regular expressions cannot be broke
Page 141 and 142:
The $ represents the end of the str
Page 143 and 144:
Chapter 7. Regular Expressions Wher
Page 145 and 146:
Regular expressions cannot be broke
Page 147 and 148:
The $ represents the end of the str
Page 149 and 150:
7.2. Construction There are two way
Page 151 and 152:
7.3. Elements Let's look more close
Page 153 and 154:
The backslash character indicates e
Page 155 and 156:
Code View: (?:!|"|#|\$|%|&|'|$|$|
Page 157 and 158:
Chapter 8. Methods Though this be m
Page 159 and 160:
array.slice(start, end ) The slice
Page 161 and 162:
is not guaranteed to produce the co
Page 163 and 164:
Function Number var a = ['a', 'b',
Page 165 and 166:
Object RegExp The most common case,
Page 167 and 168:
String // [3] regexp.test(string )
Page 169 and 170:
it produces an array of all the mat
Page 171 and 172:
is 'and' var c = text.slice(-5); //
Page 173 and 174:
Chapter 9. Style Here is a silly st
Page 175 and 176:
i = 0; // Set i to zero. In JavaScr
Page 177 and 178:
Chapter 10. Beautiful Features Thus
Page 179 and 180:
Appendix A. Awful Parts That will p
Page 181 and 182:
Appendix A. Awful Parts That will p
Page 183 and 184:
A.2. Scope JavaScript's syntax come
Page 185 and 186:
A.3. Semicolon Insertion JavaScript
Page 187 and 188:
A.4. Reserved Words The following w
Page 189 and 190:
A.5. Unicode JavaScript was designe
Page 191 and 192:
A.6. typeof The typeof operator ret
Page 193 and 194:
A.7. parseInt parseInt is a functio
Page 195 and 196:
A.8. + The + operator can add or co
Page 197 and 198:
A.9. Floating Point Binary floating
Page 199 and 200:
A.10. NaN The value NaN is a specia
Page 201 and 202:
A.11. Phony Arrays JavaScript does
Page 203 and 204:
A.12. Falsy Values JavaScript has a
Page 205 and 206:
A.13. hasOwnProperty In Chapter 3,
Page 207 and 208:
A.14. Object JavaScript's objects a
Page 209 and 210:
Appendix B. Bad Parts And, I pray t
Page 211 and 212:
Appendix B. Bad Parts And, I pray t
Page 213 and 214:
B.2. with Statement JavaScript has
Page 215 and 216:
B.3. eval The eval function passes
Page 217 and 218:
B.4. continue Statement The continu
Page 219 and 220:
B.5. switch Fall Through The switch
Page 221 and 222:
B.6. Block-less Statements An if or
Page 223 and 224:
B.7. ++ -- The increment and decrem
Page 225 and 226:
B.8. Bitwise Operators JavaScript h
Page 227 and 228:
B.9. The function Statement Versus
Page 229 and 230:
B.10. Typed Wrappers JavaScript has
Page 231 and 232:
B.11. new JavaScript's new operator
Page 233 and 234:
B.12. void In many languages, void
Page 235 and 236:
Appendix C. JSLint What error drive
Page 237 and 238:
Appendix C. JSLint What error drive
Page 239 and 240:
C.2. Members Since JavaScript is a
Page 241 and 242:
C.3. Options The implementation of
Page 243 and 244:
C.4. Semicolon JavaScript uses a C-
Page 245 and 246:
C.5. Line Breaking As a further def
Page 247 and 248:
C.6. Comma The comma operator can l
Page 249 and 250:
C.7. Required Blocks JSLint expects
Page 251 and 252:
C.8. Forbidden Blocks In many langu
Page 253 and 254:
C.9. Expression Statements An expre
Page 255 and 256:
C.10. for in Statement The for in s
Page 257 and 258:
C.11. switch Statement A common err
Page 259 and 260:
C.12. var Statement JavaScript allo
Page 261 and 262:
C.13. with Statement The with state
Page 263 and 264:
C.14. = JSLint does not expect to s
Page 265 and 266:
C.15. == and != The == and != opera
Page 267 and 268:
C.16. Labels JavaScript allows any
Page 269 and 270:
C.17. Unreachable Code JSLint expec
Page 271 and 272:
C.18. Confusing Pluses and Minuses
Page 273 and 274:
C.19. ++ and -- The ++ (increment)
Page 275 and 276:
C.20. Bitwise Operators JavaScript
Page 277 and 278:
C.21. eval Is Evil The eval functio
Page 279 and 280:
C.22. void In most C-like languages
Page 281 and 282:
C.23. Regular Expressions Regular e
Page 283 and 284:
C.24. Constructors and new Construc
Page 285 and 286:
C.25. Not Looked For JSLint does no
Page 287 and 288:
C.26. HTML JSLint is able to handle
Page 289 and 290:
C.27. JSON JSLint can also check th
Page 291 and 292:
C.28. Report If JSLint is able to c
Page 293 and 294:
Appendix D. Syntax Diagrams Thou ma
Page 295 and 296:
3 3
Page 297 and 298:
5 5
Page 299 and 300:
7 7
Page 301 and 302:
9 9
Page 303 and 304:
11 11
Page 305 and 306:
Appendix E. JSON Farewell: the leis
Page 307 and 308:
That's it. That is all of JSON. JSO
Page 309 and 310:
Appendix E. JSON Farewell: the leis
Page 311 and 312:
That's it. That is all of JSON. JSO
Page 313 and 314:
E.2. Using JSON Securely JSON is pa
Page 315 and 316:
E.3. A JSON Parser This is an imple
Page 317 and 318:
}, } } error("Bad string"); white =
Page 319 and 320:
} error("Syntax error"); // If ther
Page 321 and 322:
Appendix. Colophon The animal on th
Page 323 and 324:
Index [SYMBOL] [A] [B] [C] [D] [E]
Page 325 and 326:
Page 327 and 328:
Page 329 and 330:
Page 331 and 332:
Page 333 and 334:
Page 335 and 336:
Page 337 and 338:
Page 339 and 340:
Page 341 and 342:
Page 343 and 344:
Page 345 and 346:
Page 347 and 348:
Page 349 and 350:
Page 351 and 352:
Page 353 and 354:
Page 355 and 356:
Page 357 and 358:
Page 359 and 360:
Page 361 and 362:
Page 363 and 364:
Page 365 and 366:
Page 367 and 368:
Page 369 and 370:
1 1
show all

JavaScript: The Good Parts by Douglas Crockford Publisher: O ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?