Douglas Crockford - Programming Style and Your Brain

3,480 views

Published on

Computer programs are the most complicated things that humans make. They must be perfect, which is hard for us because humans are not perfect. Programming is thought to be a “head” activity, but there is a lot of “gut” involved. Indeed, it may be the gut that gives us the insight necessary for solving hard problems. But gut messes us up when it come to matters of style. The systems in our brains that make us vulnerable to advertising and propaganda also influence our programming styles. This talk looks systematically at the development of a programming style that specifically improves the reliability of programs. The examples are given in JavaScript, a language with an uncommonly large number of bad parts, but the principles are applicable to all programming languages.

Published in: Technology
0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,480
On SlideShare
0
From Embeds
0
Number of Embeds
385
Actions
Shares
0
Downloads
0
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Douglas Crockford - Programming Style and Your Brain

    1. 1. Programming Style &Your Brain Douglas Crockford
    2. 2. Head. Gut.Two Systems.
    3. 3. Visual Processing. An analogy.
    4. 4. Advertising.
    5. 5. Tobacco.
    6. 6. Computer Programs.The most complicated things people make.
    7. 7. Artificial Intelligence.
    8. 8. Programming Language.
    9. 9. Perfection.
    10. 10. Hunters and Gatherers.
    11. 11. Programming uses Head and Gut. Tradeoffs.
    12. 12. JavaScript. Good Parts. Bad Parts.
    13. 13. JSLint.JSLint defines a professional subset of JavaScript. http://www.JSLint.com/
    14. 14. WARNING!JSLint will hurt your feelings.
    15. 15. Left or Right?block block {{ .... .... }}
    16. 16. Left or Right?block block {{ .... .... }}• Be consistent. • Everyone should do
    17. 17. Left or Right?return return {{ ok: true ok: false };};• SILENT ERROR! • Works well in JavaScript.
    18. 18. Prefer forms that are error resistant.
    19. 19. switch statement.The fallthrough hazard.
    20. 20. “That hardly ever happens” is another way of saying “It happens”.
    21. 21. A good style can helpproduce better programs. Style is should not be about personal preference and self- expression.
    22. 22. THEROMANSWROTELATIN
    23. 23. Medieval copyistsintroduced lowercase, word These innovations helped reduce the error rate.
    24. 24. Good use of style can help reduce the occurrence of
    25. 25. The Elements of Stylehttp://www.crockford.com/wrrrld/style.html
    26. 26. Programs mustcommunicate clearly to
    27. 27. Use elements of good composition whereFor example, use a space after a comma, not before.
    28. 28. Use spaces to disambiguate• No space between function name and (.• One space between all other names and (.• Wrong: foo (bar); return(a+b); if(a=== 0) {…} function foo (b) {…} function(x) {…}
    29. 29. Immediately Invocablefunction () { ...}(); // Syntax error!
    30. 30. Immediately Invocable(function () { ...})();
    31. 31. Immediately Invocable(function () { ... Dog balls})();
    32. 32. Immediately Invocable(function () { ...}()); // Neatness counts.
    33. 33. The Heartbreak of Automaticx = y // <-- Missing semicolon(function () { ...}());
    34. 34. with statement.with (o) {  o.foo = koda; foo = koda;  o.foo = o.koda;}  foo = koda;  foo = o.koda;
    35. 35. with statement.with (o) {  o.foo = koda; foo = koda;  o.foo = o.koda;}  foo = koda;  foo = o.koda; I am not saying that it isn’t useful.I am saying that there is never a case where it isn’t confusing.
    36. 36. Confusion must be avoided.
    37. 37. Transitivity? Whats That?0 == // true0 == 0 // true == 0 // falsefalse == false // falsefalse == 0 // true" trn " == 0 // true Always use ===, never ==.
    38. 38. If there is a feature of a language that is sometimes problematic, and if it can bereplaced with another feature that is more reliable, then always use the more reliable feature.
    39. 39. Multiline string literals var long_line_1 = "This is a long line"; // ok var long_line_2 = "This is a long line"; // syntax error
    40. 40. Avoid forms that aredifficult to distinguish from common errors.
    41. 41. if (a = b) {…}a = b;if (a) {…}if (a === b) {…}
    42. 42. Make your programs look like what they do.
    43. 43. Scope.Block scope v function scope.
    44. 44. var statement.• It gets split into two parts: The declaration part gets hoisted to the top of the function, initializing with undefined. The initialization part turns into an ordinary assignment. So function foo() { ... var myVar = 0, myOtherVar;• Expands into function foo() { var myVar = undefined, myOtherVar = undefined; ... myVar = 0;
    45. 45. Declare all variables at the top of the function.
    46. 46. for (var i …) {…}Variable i is not scoped to the loop.
    47. 47. Write in the language you are writing in.
    48. 48. Let there be let.
    49. 49. Global variables.• Global variables are evil.• Avoid global variables.• When using global variables, be explicit. UPPER_CASE• Global variables should be as rare as hens teeth and stick out like a sore thumb.
    50. 50. new prefix Forgetting new causes aconstructor to clobber global variables without warning. Fixed in ES5/strict.
    51. 51. Constructor functionsshould be named with InitialCaps.Nothing else should be named with InitialCaps.
    52. 52. var a = b = 0;var a = 0, b = 0; b = 0; var a = b;
    53. 53. Write in a way that clearlycommunicates your intent.
    54. 54. ++
    55. 55. ++x += 1
    56. 56. ++x += 1 x++
    57. 57. ++x += 1 x++ ++x
    58. 58. ++x;++x;x += 2;
    59. 59. For no cost, by adopting amore rigorous style, many classes of errors can be automatically avoided.
    60. 60. if (a) b(); c();
    61. 61. if (a) b(); c();if (a) {b(); c();}if (a) {b();} c();
    62. 62. As our processes become more agile, our coding must be more resilient.
    63. 63. Bad stylists• Under educated.• Old school.• Thrill seeker.• Exhibitionist.
    64. 64. “That was intentional.” “I know what I’m doing.”
    65. 65. Programming is the most complicated thing that humans do.Computer programs must be perfect. Humans are not good at perfect.
    66. 66. Designing a programmingstyle demands discipline. It is not selecting features because they are liked, or pretty, or familiar.
    67. 67. The Abyss
    68. 68. The JSLint style was drivenby the need to automatically detect defects. Forms that can hide defects are considered defective.
    69. 69. Language Subsetting.Only a madman would use all of C++.
    70. 70. There will be bugs.Do what you can to move the odds to your favor.
    71. 71. Good style is good for your gut.
    72. 72. The Analytical Language of John Wilkins Jorge Luis BorgesThese ambiguities, redundancies and deficiencies remind us of those which doctorFranz Kuhn attributes to a certain Chinese encyclopedia entitled The CelestialEmporium of Benevolent Knowledge. In its remote pages it is written that the animalsare divided into a. belonging to the Emperor b. embalmed c. trained d. piglets e. sirens f. fabulous g. stray dogs h. included in this classification i. trembling like crazy j. innumerables k. drawn with a very fine camelhair brush l. et cetera m.just broke the vase n. from a distance look like flies

    ×