DAY 6
πΒ μ€λ μ½μ λ²μ : 3μ₯ ~ Reading code from top to bottom: the stepdown rule
<aside>
π μ±
μμ κΈ°μ΅νκ³ μΆμ λ΄μ©μ μ¨λ³΄μΈμ.
</aside>
- How can we make a function communicate its intent? What attributes can we give our functions that will allow a casual reader to intuit the kind of program they live inside?
- The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
- In the eighties we used to say that a function should be no bigger than a screen full. (VT100 screens)
- Lines should not be 150 characters long. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.
- ...This implies that the blocks within if statements, else statements, while statements, and so on should be one line long.
- This also implies that functions should not be large enough to hold nested structures. Therefore, the indent level of a function should not be greater than one or two.
- Functions should do one thing. They should do it well. They should do it only.
- ...the reason we write functions is to decompose a larger concept (in other words, the name of the function) into a set of steps at the next level of abstraction.
- Functions that do one thing cannot be reasonably divided into sections.
- Making the code read like a top-down set of TO paragraphs is an effective technique for keeping the abstraction level consistent.
<aside>
π€ μ€λ μ½μ μκ°μ? λ μ€λ₯΄λ μκ°μ κ°λ³κ² μ μ΄λ³΄μΈμ
</aside>
I had a pairing session today where we fixed broken tests as well as refactoring the functions I wrote.
Functions should do one thing. They should do it well. They should do it only.
Just look how βnormalβ this sounds, but how not easy it is in real life. π€·π»ββοΈ
Got many highlights today because everything there feels like itβs saying them specifically to me π