Managing JavaScript Complexity
Upcoming SlideShare
Loading in...5
×
 

Managing JavaScript Complexity

on

  • 10,366 views

These are the slides for the talk "Managing and Visualizing JavaScript Complexity" given at QCon SF 2013 by Jarrod Overson

These are the slides for the talk "Managing and Visualizing JavaScript Complexity" given at QCon SF 2013 by Jarrod Overson

Statistics

Views

Total Views
10,366
Views on SlideShare
8,352
Embed Views
2,014

Actions

Likes
27
Downloads
40
Comments
0

9 Embeds 2,014

http://www.scoop.it 1837
https://twitter.com 112
http://wiki.vertafore.com 56
https://remote.vertafore.com 3
https://hootsuite.scoop.it 2
http://moderation.local 1
http://tweetedtimes.com 1
http://www.instacurate.com 1
http://www.twylah.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Managing JavaScript Complexity Managing JavaScript Complexity Presentation Transcript

  • Managing and Visualizing JavaScript Complexity Jarrod Overson Consultant @ Gossamer.io jarrodoverson.com
  • Yes, we’ll talk about “Code Complexity” and “Code Quality”
  • Check your bias at the door We’ll deal with it later
  • 1. Why is this important now 2. Static Analysis & Linting 3. Visualizing Complexity
  • The obvious…
  • JavaScript is Dynamic all the obvious pitfalls compounded by Immature tooling and IDEs Wildly variable module styles Best practices vary as language evolves Server & Client similar yet so different
  • The Talent Pool is ridic Web Platform Engineers jQuery experts Closures?
  • The less obvious…
  • Progress is staggering It’s hard to keep up The next tech might not be usable yet When it is, you want to actually be able to use it
  • Refactoring isn’t easy Callback hell is more than just deep nesting ! IDEs can’t help much, yet ! But flexibility is more important on the web than anywhere else
  • And the hard to admit…
  • The Web is hard Web Applications are not solved Even the giants pivot and backtrack So many solutions still don’t exist
  • So why are we here? Why bother?
  • JS coasted to the lead on neutral
  • And this isn’t even its final form
  • We can see where it’s headed and we’re betting on JS
  • 1. Why is this important now 2. Static Analysis & Linting 3. Visualizing Complexity
  • Respect your JavaScript and codify that respect.
  • All code should look the same. Style Naming Punctuation Indentation Comments Case
  • Get everyone together 1. Agree 2. Document 3. Enforce https://github.com/rwaldron/idiomatic.js/ https://github.com/Seravo/js-winning-style https://github.com/airbnb/javascript
  • Coding conventions based on Github analysis 1. >90% use last comma 2. >80% use space indents 3. >55% use single quotes http://sideeffect.kr/popularconvention/#javascript
  • Lax enforcement begets violations. Warnings need to fail builds. These is as important as failed tests.
  • Know your options JSLint Crockford-style linter, low configuration Closure Linter Google-style linter, low configuration JSHint ✔ Community driven JSLint fork, moderately configurable ESLint ✔ Pluggable styles, highly configurable
  • Know your options’ options { } "maxerr" "bitwise" "camelcase" "curly" "eqeqeq" "forin" "immed" "indent" "latedef" "newcap" "noarg" "noempty" "nonew" "plusplus" "quotmark" //... : : : : : : : : : : : : : : : 50, true, false, true, true, true, false, 4, false, false, true, true, false, false, false
  • Be aggressive. Default to overly strict.
  • Smart deviation is OK and expected. ! ! function fn(param) { /*jshint eqeqeq:false*/ ! if (param == 42) return; ! }
  • Set complexity limits "maxparams" "maxdepth" "maxstatements" "maxcomplexity" "maxlen" : : : : : 4, 4, 20, 7, 100
  • What is Cyclomatic Complexity a.k.a. Conditional Complexity ?
  • Cyclomatic Complexity is not magic nerd hokum something you should ignore
  • Cyclomatic Complexity is the number of paths through a block of code (technically)
  • Cyclomatic Complexity is how hard your code is to test. (practically)
  • Complexity : 1 ! function main(a) { ! }
  • Complexity : 2 function main(a) { if (a > 5) { } }
  • Complexity : ? still 2 function main(a) { if (a > 5) { ! } else { ! } }
  • Complexity : ? now 3 function main(a) { if (a > 10) { ! } else if(a > 5) { ! } }
  • Complexity : ? still 3 function main(a) { if (a > 10) { ! } else if(a > 5) { ! } else { ! } }
  • Complexity : ? also 3 function main(a) { if (a > 5) { if (a > 10) { ! } } }
  • Complexity : 7 function main(a) { if (a) { } else if (a) { } ! if (other) { } ! } for (var i = 0; i < a; i++) { if (i % 2) { } else if (i % 3) { } }
  • Don’t get hung up on numbers ! function main() { /*jshint maxcomplexity:12*/ ! } //... ! * note : jshint calculates complexity differently than complexity-report (plato, grunt-complexity)
  • Cyclomatic Complexity is an early warning but isn’t everything.
  • OMG! I’m going to make the best .jshintrc
  • It’s ok. Have an ideal set of options, and a current set that passes now. Visualize your goal.
  • 1. Why is this important now 2. Static Analysis & Linting 3. Visualizing Complexity
  • Plato. One cool guy. github.com/es-analysis/plato
  • Visualize your progress. Target hot spots and track progress. Promote files when ready. When a file clears, promote it to your ideal jshintrc.
  • Files passing “ideal” settings
  • Files to target next
  • Someday…
  • Challenge Accepted. You
  • But wait! There’s MORE!
  • Code is a liability. Your job is to provide value with as little code as possible.
  • How many lines of code does your main project have right now? If you don’t know, within 10%, then you’re ignoring it. Treat SLOC like credit card debt.
 Don’t add to it without knowing the balance.
  • Maintainability Index? Awesome, JavaScript is a real platform now! You’re drunk You’re both right.
  • Maintainability : 100 // empty file Well we can buy that.
  • Maintainability : 95 var foo = 42; Seems harsh, but ok.
  • Maintainability : 83 var foo = 42; ! var bar = Math.log(foo++); Holy crap, we’re dropping fast…
  • Maintainability : 92 var foo = 42; ! function calc(x) { return Math.log(x++); } ! var bar = calc(foo); Ok, that does seem better…
  • Toolable via grunt-complexity https://github.com/vigetlabs/grunt-complexity
  • What are we really working with here?
  • var vocabulary = unqOperators + unqOperands; var length = totOperators + totOperands; var difficulty = (unqOperators / 2) * (totOperands / unqOperands); var volume = length * Math.log2(vocabulary); var effort = difficulty * volume; ! But don’t look at var maintainabilityIndex = Math.max( 0, ( 171 + -3.42 * Math.log(aveEffort) + ! -0.23 * (aveComplexity) + -16.2 * Math.log(aveLOC) Smarter people are responsible ) * 100 / 171 ); me for questions
  • 1976 Thomas McCabe - Cyclomatic Complexity 1977 Maurice Halstead - Halstead Metrics 1991 Oman/Hagemeister - Maintainability Index Phil Booth JavaScript Implementation Ariya Hidayat Source Analysis (Esprima)
  • Oh, come on.
  • These numbers are for introspection and exploration These calculations have been praised and criticised, promoted and shot down. (and Halstead died before being able to defend them)
  • The point is
  • “ The unexamined code is not worth releasing ” - Socrates
  • Code is not just logic
  • Code is the api between imagination and reality
  • Inconsistent, complex Code is an inconsistent, complex API
  • Tool how you code
  • Hack how you code
  • Visualize how you code
  • Visualize Everything
  • Jarrod Overson @jsoverson jarrod@jsoverson.com jsoverson.com jsoverson.com/google+ jsoverson.com/linkedin jsoverson.com/github jsoverson.com/twitter