DAY 7

🔖 오늘 읽은 범위 : Switch statements ~ cp3 end

<aside> 😃 책에서 기억하고 싶은 내용을 써보세요.

</aside>

• “You know you are working on clean code when each routine turns out to be pretty much what you expected.” Half the battle to achieving that principle is choosing good names for small functions that do one thing.
• Don’t be afraid to make a name long.
• Don’t be afraid to spend time choosing a name. Indeed, you should try several different names and read the code with each in place.
• The ideal number of arguments for a function is zero(niladic). Next comes one(monadic), followed closely by two(dyadic). Three arguments(triadic) should be avoided where possible.
• Passing a boolean into a function is a truly terrible practice.
• Temporal couplings are confusing, especially when hidden as a side effect. If you must have a temporal coupling, you should make it clear in the name of the function.
• Anything that forces you to check the function signature is equivalent to a double-take. It’s a cognitive break and should be avoided.
• ...it is better to extract the bodies of the try and catch blocks out into functions of their own.
• When you use exceptions rather than error codes, then new exceptions are derivatives of the exception class. They can be added without forcing any recompilation or redeployment.
• Writing software is like any other kind of writing. When you write a paper or an article, you get your thoughts, down first, then you massage it until it reads well. The first draft might be clumsy and disorganized. so you wordsmith it and restructure it and refine it until it reads the way you want it to read.
• Master programmers think of systems as stories to be told rather than programs to be written. They use the facilities of their chosen programming language to construct a much richer and more expressive language that can be used to tell that story. Part of that domain-specific language is the hierarchy of functions that describe all the actions that take place within that system. In an artful act of recursion those actions are written to use the very domain-specific language they define to tell their own small part of the story.
• If you follow the rules herein, your functions will be short, well named, and nicely organized. But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.

<aside> 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

</aside>

Sometimes I find what’s in the book is not applicable if you’re a React developer.