Rephrase default value advice #34
Conversation
- The original document asserted that "Short-circuiting is cleaner than conditionals"
- ...only to override this assertion later with "Use default arguments instead of short circuiting."
- This is a poor design-choice for an advisory document.
- If you are going to say x > y,
- then later say z > x,
- you should just say z > x > y upfront.
- Otherwise, many people might not see the z > x later on,
- because many people will probably use this as a referential document. They probably won't read the entire work.
| } | ||
| ``` | ||
|
|
||
| **Good**: | ||
| **Better:** |
There was a problem hiding this comment.
Thanks for more contributions!
I agree with you in principle. It does seem to me that people are going to read this non-linearly. I do give advice in a linear way of increasing cleanliness -- see the Concurrency section. If we set the precedent here, that would need to be fixed.
As for your solution, this is looking almost perfect. I don't want to change the format of this project though, so let's avoid having a Better clause. Can we just have Good/Bad?
- This commit concerns the document's comparison of 3 approaches to default values. - Conditionals - Short-Circuiting - Default Arguments - In my original pull request, I ordered these from bad to best: - Conditionals (Bad) - Short-Circuiting (Better) - Default Arguments (Best) - In this commit, I am rephrasing the **Bad/Better/Best** ordering scheme to **Bad/Bad/Good** because: - The rest of the document uses the **Bad/Good** format. - We should use *consistent language* throughout the document.
|
I addressed your request. How does that look now? Oh, and a big thanks for adapting Clean Code to JavaScript + being considerate to all the pull requests! |
|
That's almost there! I'm sorry I wasn't very clear with my thoughts. Can you have just one Bad example and one Good example? Thanks! |
-The section, "Use default arguments instead of short circuiting or conditionals"
originally had 2 "bad examples" and 1 "good example."
- This commit lowers the "bad examples" count from 2 -> 1.
- The 1st "bad example" demonstrated the "conditionals" approach to default values.
- The 2nd "bad example" demonstrated the "short-circuit" approach to default values.
- I decided to only show the "short-circuit" approach as the 1 bad example, since that's
what most people would use traditionally in ES5.
- Few people actually use the "conditionals" approach, so I felt that warning
against the "conditionals" approach was unnecessary.
|
I changed it to one Bad example and one Good example. How's that look now? |
|
That's great, thank you for your hard work! |
The original document asserted that "Short-circuiting is cleaner than conditionals"
...only to override this assertion later with "Use default arguments instead of short circuiting."
This is a poor design-choice for an advisory document.