오늘 읽은 범위

• Ch 3. Functions

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

• Functions that take variable arguments can be monads, dyads, or even triads. But it would be a mistake to give them more arguments than that.
• In the case of a monad, the function and argument should form a very nice verb/noun pair. … An even better name might be writeField(name), which tells us that the “name” thing is a field
• In general output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object
  • ex) use class report.appendFooter(), not a function appendFooter(report)

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

• This chapter shares practical and examples on what meets clean code standard. It’s one of the chapters I’ll be revisiting multiple times
• I got lots of good ideas to apply this to the script that I’ve written recently at work and reminds me to apply to it before sharing the code with the team

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• I don’t fully understand what are good dyadic and Triads functions. How do I know when the two/three arguments are “natural” to be acceptable?

  For example, the author uses example assertEquals(expected,actual) to be a bad dyadic function.

  Let’s say we want to compare expected value returned by a function that calculates some formula to actual value returned by a function that retrieves the actual value in the db.

  This usage to me seems fine, and I want to learn why this isn’t a good code

  ...
  def doesExpectedEqualActual(expected,actual):
  	if expected == actual:
  		return True
  	else:
  		return False