4장. 미학 이번 장에서 이야기하는 말 그대로 커드 편집기에서 볼 수 있는 코드의 미적인 부분이다. 미학적이지 않은 코드의 대표적인 예가 들여쓰기가 제대로 되어있지 않은 코드이다. 관련 있는 코드끼리 구분지어져 있는 것도 미학적인 부분에 포함된다. 미학적인 코드는 들여쓰기는 기본이고 비슷한 코드는 비슷하게 보이는 코드이다. 추가적으로 줄 바꿈을 사용해서가독성을 높일 수 있다. 동일한 기능을 하는 부분을 메서드로 분리해 미학성을 높일 수도 있다. 추가적으로 얻을 수 있는 이점은 코드의 길이가 짧아진 다는 것과, 메서드에 이름을 붙여서 이해하기 더 쉬운 코드로 만들 수 있다는 점이다. 가장 중요한 점은 코드가 일관적이어야 한다는 것이다. 어느 때는 중괄호를 이름 옆에 두고, 어느 때는 아래에 두는 것과 이름..
읽기좋은코드가좋은코드다
3장. 오해할 수 없는 이름들 변수, 함수, 클래스의 이름을 지을 때 이 이름이 다른 의미로 해석될 수 있을까? 라는 고민을 해보아야 한다. 당연한 것은 없다. 누군가는 처음부터 시작한다고 생각할 수 있고, 누군가는 마지막부터 시작한다고 생각할 수 있다. 또한 일반적으로 사람들이 어떤 의미로 사용하는지도 고려해야 한다. 예를 들어, get 메서드는 일반적으로 내부 멤버를 반환한다고 생각한다. 만약 클래스 내에서 getMean 이라는 메서드를 만들었는데, 이 메서드가 내부 멤버 배열의 전체를 돌고, 중앙 값을 반환하는 메서드라면 get 대신 compute 라는 이름을 사용하는 것이 더 좋다. 오해를 발생시키지 않는 이름이 좋은 이름이다. 우리의 코드를 다른 사람이 읽을 때, 우리가 의도한 대로 이해할 수 ..
2장. 이름에 정보 담기 프로그래밍하면서 가장 고민 되는 부분 중 하나가 이름을 짓는 것이다. 언제나 창작의 고통은 큰 것 같다. 하지만 잘 지은 이름은 이후에 뿌듯함만 주는 것이 아니라 코드를 쉽게 이해할 수 있도록 도움을 준다. 기존에 코드 컴플리트에서는 tmp, result 와 같은 변수를 사용하지 말라고 추천했었는데, 이 책에서는 조금 관대한 모습을 보여준다. 좁은 범위의 코드 내에서는 위처럼 보편적인 변수명을 사용해도 문제되지 않고, 오히려 좋을 것이라고 말해준다. 하지만 범위가 커지고, 개인의 귀차니즘(?) 때문에 지은 보편적인 이름들은 에러를 발생했을 때, 문제를 발견하기 더 어렵게 만든다고 말한다. 반복문에 사용하는 i, j, k 와 같은 변수명들도 누구나 이 것이 반복문에서 사용되는 인덱..
1장. 코드는 이해하기 쉬워야 한다. 이번은 처음 시작하는 장으로 챕터가 1장 으로 표시된다. 다음 내용부터는 Part 1 의 형태로 파트 내부에 몇 개의 장으로 이루어진 형태로 표시될 예정이다. 가독성이 높은 코드가 소프트웨어의 효율성과 디자인 패턴에 주는 영향은 거의 없다. 이 책의 목표는 가독성이 높은 코드를 작성하는 것이다. return age >= 40 ? price * (1
