{"issue":{"created_at":"2011-12-04T03:15:40Z","state":"closed","updated_at":"2011-12-07T20:12:50Z","user":{"gravatar_id":"299a3d891ff1920b69c364d061007043","id":4303,"url":"https://api.github.com/users/jdalton","login":"jdalton","avatar_url":"https://secure.gravatar.com/avatar/299a3d891ff1920b69c364d061007043?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"comments":22,"body":"I noticed mixed use of\r\nsingle vs. double quotes,\r\n`undefined` vs. `void 0`,\r\nsingle line IF statements `if (foo) bar();` vs\r\n\r\n~~~\r\nif (foo) {\r\n  bar();\r\n}\r\n~~~\r\n\r\n, and variable declaration lists `var a, b, c = 3;` vs.\r\n\r\n~~~ js\r\nvar a;\r\nvar b;\r\nvar c = 3;\r\n~~~\r\n\r\nThere should be some consistency.\r\nSummoning @rwldrn!\r\n","assignee":null,"id":2440469,"number":392,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"labels":[{"name":"question","color":"a8438d","url":"https://api.github.com/repos/documentcloud/underscore/labels/question"}],"title":"Implement a code style and stick w/ it.","html_url":"https://github.com/documentcloud/underscore/issues/392","closed_at":"2011-12-06T18:34:25Z","url":"https://api.github.com/repos/documentcloud/underscore/issues/392","milestone":null},"action":"created","comment":{"created_at":"2011-12-07T20:12:50Z","updated_at":"2011-12-07T20:12:50Z","user":{"gravatar_id":"299a3d891ff1920b69c364d061007043","id":4303,"url":"https://api.github.com/users/jdalton","login":"jdalton","avatar_url":"https://secure.gravatar.com/avatar/299a3d891ff1920b69c364d061007043?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"@broofa\r\n\r\n> I actually agree that, regardless of rational, this seems like a bad idea. It's either bad statistics or bad UI design.\r\n\r\nThe discussion is about displaying a result so no bad statistics ;D\r\nIt comes down how devs should best be presented *meaningful* information.\r\n\r\n>The problem is that in showing the same value for both tests - which should be independent of one another - you invite the question of, \"how on earth could these two independent pieces of code possibly get exactly the same result???\" \r\n\r\nI hope they do ask. We will add an FAQ note about it.\r\nAs I said before we normalize on one of the actual results *(since they are statistically indistinguishable **it really doesn't matter** which one we show)*. We side on the slowest of the indistinguishable benchmarks because that's the worst case outcome.\r\n\r\n> The results shown for each test should be based solely on the data collected for that specific test. If one result is \"350 +/- 20%\" and another is \"300 +/- 5%\", that's what should be shown. If you want to annotate them both as \"fastest\" that's fine since they are statistically indistinguishable. But you should probably add a footnote explaining why the different results are both considered \"fastest\". If there's confusion, then at least it stems only from JSPerf's interpretation and not the actual data.\r\n\r\nBenchmark.js and jsPerf are big into giving *meaningful* results. We noticed devs drawing inaccurate conclusions about live and charted results with just color coding, so to resolve that we normalized on one of the indistinguishable results. This way it's harder to misinterpret the charted data. If we had done this sooner it might have prevented the propagation of such needless micro-optimizations as the `void 0` vs `undefined` from seeping into so many projects.\r\n\r\nThat said, it couldn't hurt to make it configurable in Benchmark.js for `Benchmark.Suite` to normalize results or not.\r\nIf we did change jsPerf's behavior we could only do so for the live data and not the charted data *(as it lacks the context of margin of error)*.","id":3052698,"url":"https://api.github.com/repos/documentcloud/underscore/issues/comments/3052698"}}