개발자 99% 커뮤니티에서 수다 떨어요!
TIL (Today I Learned)
2022.02.28
오늘 읽은 범위
Formatting
책에서 기억하고 싶은 내용을 써보세요.
Code formatting is about communication, and communication is the professional developer's first order of business.
The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made.
So what are the formatting issues that help us to communicate best?
How big should a source file be?
Small files are usually easier to understand than large files are.
Think of a well-written newspaper article. You read it vertically.
We would like a source file to be like a newspaper article.
Nearly all code is read left to right and top to bottom.
Each blank line is a visual cue that identifies a new and separate concept.
If openness separates concepts, then vertical density implies close association.
Concepts that are closely related should be kept vertically close to each other.
Closely related concepts should not be separated into different files unless you have a very good reason.
Variable Declarations
Variables should be declared as close to their usage as possible.
Local variables should appear at the top of each function.
Control variables for loops should usually be declared within the loop statement.
Instance variables, on the other hand, should be declared at the top of the class.
Scissors rule.
Dependent Functions
If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible.
Conceptual Affinity
The stronger that affinity, the less vertical distance there should be between them.
A function that is called should be below a function that does the calling.
This creates a nice flow down the source code module from high level to low level.
Programmers clearly prefer short lines.
I used to follow the rule that you should never have to scroll to the right.
We use horizontal white space to associate things that are strongly related and disassociate things that are more weakly related.
A team of developers should agree upon a single formatting style, and then every member of that team should use that style.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
본인은 코드를 작성할 때 오와 열을 항상 중요하게 생각해왔었는데, 그 생각이 그렇게 나쁘지는 않았다는 생각이 든다. 결국 이번 챕터의 요지는 보기 좋고 읽기 좋은 코드가 좋은 코드 아닌가. 코드도 결국 글인데, 신문 읽듯이 잘 읽히는 코드가 좋은 코드라는 저자의 생각에 깊은 공감을 한다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
What is Scissors rule?
Should I learn Java?
What are instance variables?