From 1b5451426f77b4ff630fb6ffbbb07de964032f43 Mon Sep 17 00:00:00 2001 From: Kyle Simpson Date: Fri, 9 Jan 2015 22:24:47 -0600 Subject: [PATCH] types+grammar: ch1, ch2, ch5, tweaking formatting and minor details --- types & grammar/ch1.md | 2 +- types & grammar/ch2.md | 4 ++-- types & grammar/ch5.md | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/types & grammar/ch1.md b/types & grammar/ch1.md index 337707423..9ec77d5b2 100644 --- a/types & grammar/ch1.md +++ b/types & grammar/ch1.md @@ -1,7 +1,7 @@ # You Don't Know JS: Types & Grammar # Chapter 1: Types -Most developers would say that a dynamic language (like JS) does not have *types*. Let's see what the ES5.1 specification has to say on the topic: +Most developers would say that a dynamic language (like JS) does not have *types*. Let's see what the ES5.1 specification (http://www.ecma-international.org/ecma-262/5.1/) has to say on the topic: > Algorithms within this specification manipulate values each of which has an associated type. The possible value types are exactly those defined in this clause. Types are further sub classified into ECMAScript language types and specification types. > diff --git a/types & grammar/ch2.md b/types & grammar/ch2.md index ea2eab799..e8286eb6c 100644 --- a/types & grammar/ch2.md +++ b/types & grammar/ch2.md @@ -216,7 +216,7 @@ JavaScript has just one numeric type: `number`. This type includes both "integer So, in JS, an "integer" is just a value that has no fractional decimal value. That is, `42.0` is as much an "integer" as `42`. -Like most modern languages, including practically all scripting languages, the implementation of JavaScript's `number`s is based on the "IEEE 754" standard, often called "floating point." JavaScript specifically uses the "double precision" format (aka "64-bit binary") of the standard. +Like most modern languages, including practically all scripting languages, the implementation of JavaScript's `number`s is based on the "IEEE 754" standard, often called "floating-point." JavaScript specifically uses the "double precision" format (aka "64-bit binary") of the standard. There are many great write-ups on the Web about the nitty-gritty details of how binary floating-point numbers are stored in memory, and the implications of those choices. Because understanding bit patterns in memory is not strictly necessary to understand how to correctly use `number`s in JS, we'll leave it as an excercise for the interested reader if you'd like to dig further into IEEE 754 details. @@ -364,7 +364,7 @@ The most (in)famous side effect of using binary floating-point numbers (which, r Mathematically, we know that statement should be `true`. Why is it `false`? -Simply put, the representations for `0.1` and `0.2` in binary floating point are not exact, so when they are added, the result is not exactly `0.3`. It's **really** close: `0.30000000000000004`, but if your comparison fails, "close" is irrelevant. +Simply put, the representations for `0.1` and `0.2` in binary floating-point are not exact, so when they are added, the result is not exactly `0.3`. It's **really** close: `0.30000000000000004`, but if your comparison fails, "close" is irrelevant. **Note:** Should JavaScript switch to a different `number` implementation that has exact representations for all values? Some think so. There have been many alternatives presented over the years. None of them have been accepted yet, and perhaps never will. As easy as it may seem to just wave a hand and say, "fix that bug already!", it's not nearly that easy. If it were, it most definitely would have been changed a long time ago. diff --git a/types & grammar/ch5.md b/types & grammar/ch5.md index 6f91e86d1..daa62306b 100644 --- a/types & grammar/ch5.md +++ b/types & grammar/ch5.md @@ -822,15 +822,15 @@ But an important question remains: should we all write code understanding and pe Or, on the other hand, should we recognize that even though such rules *are in fact* learnable, there's enough gotchas to warrant ignoring automatic precedence/associativity? If so, should we thus always use `( )` manual grouping and remove all reliance on these automatic behaviors? -This debate is highly subjective, and heavily related to the debate in Chapter 4 over *implicit coercion*. Most developers feel the same way about both debates: either they accept both behaviors and code expecting them, or they discard both behaviors and stick to manual/explicit idioms. +This debate is highly subjective, and heavily related to the debate in Chapter 4 over *implicit* coercion. Most developers feel the same way about both debates: either they accept both behaviors and code expecting them, or they discard both behaviors and stick to manual/explicit idioms. Of course, I cannot answer this question definitively for the reader here anymore than I could in Chapter 4. But we've presented you the pros and cons, and hopefully forced enough deeper understanding that you can make informed rather than hype-driven decisions. -In my opinion, there's an important middle ground. We should mix both operator precedence/associativity *and* `( )` manual grouping into our programs (in the same way that I argue in Chapter 4 for healthy/safe usage of *implicit coercion*, but certainly don't endorse it exclusively without bounds). +In my opinion, there's an important middle ground. We should mix both operator precedence/associativity *and* `( )` manual grouping into our programs (in the same way that I argue in Chapter 4 for healthy/safe usage of *implicit* coercion, but certainly don't endorse it exclusively without bounds). For example, this is perfectly OK to me: `if (a && b && c) ..` I wouldn't do `if ((a && b) && c) ..` just to explicitly reflect the associativity, because I think it's overly verbose. -On the other hand, if I needed to chain two `? :` conditional operators together, I'd probably use `( )` manual grouping to make it absolutely clear what my intended logic is. +On the other hand, if I needed to chain two `? :` conditional operators together, I'd certainly use `( )` manual grouping to make it absolutely clear what my intended logic is. Thus, my advice here is similar to that of Chapter 4: **use operator precedence/associativity where it leads to shorter and cleaner code, but use `( )` manual grouping in places where it helps create clarity and reduce confusion.**