코드의 흐름을 파악하기 힘들게 만드는 요소들

Posted by epicdev Archive : 2012. 6. 15. 21:33


 프로그래밍 구조

상위수준의 프로그램 흐름이 혼란스러워지는 방식 

스레딩 

어느 코드가 언제 실행되는지 불분명하다 

시그널/인터럽트 핸들러 

어떤 코드가 어떤 시점에 실행될지 모른다 

예외

예외처리가 여러 함수 호출을 거치면서 실행될 수 있다 
함수 포인터 & 익명 함수 

실행할 함수가  런타임에 결정되기 때문에 컴파일 과정에서는 어떤 코드가 실행될지 알기 어렵다

가상 메소드 

 object.virtualMethod()는 알려지지 않은 하위 클래스의 코드를 호출할지도 모른다 


위 예시 중 어떤 것은 매우 유용하다. 코드를 더 읽기 편하고 덜 중복되게 한다. 하지만 프로그래머는 나중에 코드를 읽는 사람이 얼마나 어렵게 느낄지 생각하지 않은 채 이러한 구조들을 과도하게 사용하기도 한다. 그리고 이러한 구조는 버그 추적을 매우 어렵게 한다.


결국 핵심은 코드를 작성할 때 이러한 구조가 차지하는 비율이 너무 높지 않아야 한다는 데 있다. 만약 과용하면 코드의 흐름을 파악하는 일이 매우 어려워진다.



읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

쇼트 서킷 논리 (Short-Circuit Logic) 오용 말기  (0) 2012.06.15
설명 변수와 요약 변수  (0) 2012.06.15
코드의 미학  (0) 2012.05.11
Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다  (0) 2012.05.11
first/last와 begin/end  (0) 2012.05.11
  

코드의 미학

Posted by epicdev Archive : 2012. 5. 11. 17:20

미학적으로 보기 좋은 코드가 사용하기 더 편리하다.



읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

설명 변수와 요약 변수  (0) 2012.06.15
코드의 흐름을 파악하기 힘들게 만드는 요소들  (0) 2012.06.15
Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다  (0) 2012.05.11
first/last와 begin/end  (0) 2012.05.11
가독성의 기본 정리 (The Fundamental Theorem of Readability)  (0) 2012.05.11
  

Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다

Posted by epicdev Archive : 2012. 5. 11. 17:13

Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다.


아래와 같은 이름 대신



다음과 같은 이름을 사용하면 더 간결하고 읽기 좋다.



읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

코드의 흐름을 파악하기 힘들게 만드는 요소들  (0) 2012.06.15
코드의 미학  (0) 2012.05.11
first/last와 begin/end  (0) 2012.05.11
가독성의 기본 정리 (The Fundamental Theorem of Readability)  (0) 2012.05.11
Python list의 +=와 append의 성능 분석 (보너스: +=와 extend 성능 분석)  (0) 2012.04.06
  

first/last와 begin/end

Posted by epicdev Archive : 2012. 5. 11. 17:09

경계를 포함하는 범위에는 first와 last를 사용하라.

즉, range(first=2, last=4)라면 2, 3, 4를 모두 포함하는 것이다.


경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라.

즉, range(begin=2, end=4)라면 2, 3을 포함하는 것이다.


10월 16일에 일어난 일을 모두 출력하고 싶을 때


라고 쓰는 것이 아래보다 더 편리하다.




읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교



'Archive' 카테고리의 다른 글

코드의 미학  (0) 2012.05.11
Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다  (0) 2012.05.11
가독성의 기본 정리 (The Fundamental Theorem of Readability)  (0) 2012.05.11
Python list의 +=와 append의 성능 분석 (보너스: +=와 extend 성능 분석)  (0) 2012.04.06
Eclipse의 Runnable JAR File Export의 Library Handling 옵션 설명  (0) 2012.04.05
  

가독성의 기본 정리 (The Fundamental Theorem of Readability)

Posted by epicdev Archive : 2012. 5. 11. 15:50

코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.



읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다  (0) 2012.05.11
first/last와 begin/end  (0) 2012.05.11
Python list의 +=와 append의 성능 분석 (보너스: +=와 extend 성능 분석)  (0) 2012.04.06
Eclipse의 Runnable JAR File Export의 Library Handling 옵션 설명  (0) 2012.04.05
ls -l 명령어로 파일 크기 확인할 때 1M 단위로 보기  (0) 2012.03.29
  

Java에서 File IO할 때의 try-catch-finally 스타일

Posted by epicdev Archive : 2012. 3. 27. 19:54

Java에서 File IO를 할 때에 필연적으로 사용해야하는 것이 try와 catch와 finally이다.

그런데 이런 try, catch, finally 들로 코드를 도배하다보면 정말 UGLY한 코드가 나오기가 쉽다.

아래의 코드가 일반적으로 가장 널리 사용되는 스타일이다.


이 코드는 소위 말하면 정말 UGLY하다고 할 수가 있다.

가독성도 떨어지고 뭔가 불필요하게 try와 catch가 들어있는것 처럼 보인다. (실상은 그렇지 않다. 다 필요하다.)

이처럼 불필요하게 "보이는" try와 catch를 없애려고 아래의 코드처럼 할 수도 있다.


이렇게 하고나면 맨 처음 코드에서 catch가 반복되는 것을 해결 할 수 있어 보인다.

물론 이렇게 하면 해결은 되지만, Java에서의 Exception을 처리할 때의 원칙(Exception들을 catch문 하나에서 한꺼번에 처리하지 않는다)에 위배된다.

즉, out.close에서 발생하는 Exception과 new FileOutputStream에서 발생하는 Exception 모두 하나의 catch문에서 처리가 되어버린다.

이를 해결하기 위해서 또한 아래처럼 코드를 짤 수도 있다.


이렇게 코드를 짜게되면 함수가 IOException을 throw하게 된다. 또한, finally 블록에서 out의 null 체크도 없어졌다.

(new FileOutPutStream에서 Exception이 발생하면 곧바로 IOException을 throw하면서 그 다음 line을 실행하지 않으므로 finally 블록에서의 out은 무조건 null이 아니다)

하지만 나같은 경우는 Exception처리를 외부로 유보하는 것을 좋아하지 않으므로 (이런 사람들이 많을것이라 본다), 개인적으로는 비추천이다.


그래서 이제 최종적으로 내가 "알고 있는 한" 가장 BEAUTIFUL한 코드를 살펴보도록 하겠다.


이 코드를 보면 closeQuietly라는 함수를 finally 블록에서 호출하고 있다.

closeQuietly라는 함수는 Closeable의 varargs 타입을 파라미터로 받아서, 받은 closeable들을 모두 닫아버린다.

이렇게 stream들을 닫는 함수를 따로 만듦으로써 코드가 훨씬 깔끔해졌다.


물론 위의 4가지 스타일 모두 사용가능한 스타일이다.

필요한 상황마다 적재적소에 사용 할 수 있다. 네 번째 스타일의 경우에는 때로는 "닭 잡는데 소 잡는 칼을 쓰는 격"이 될 수도 있다.

이 내용에 대한 프로그래머들의 의견은 http://stackoverflow.com/questions/2699209/java-io-ugly-try-finally-block에서 확인 할 수 있다.

위의 링크를 참조하자면, 4번째 스타일이 가장 낫다는 것이 보편적인 생각인 것 같다.



'Archive' 카테고리의 다른 글

리팩토링을 망설이지 말자  (0) 2012.03.29
PriorityQueue를 적재적소에 사용하자  (0) 2012.03.27
Java에 Pair가 없는 이유 (추측)  (0) 2012.03.27
파일로 data를 쓸 때 주의해야 할 점과 그에 대한 오해 (flush and close)  (0) 2012.03.27
최근에 본 명언 중에 가장 기억에 남는 명언  (0) 2012.03.19
  

Java에서 중첩 루프 한번에 탈출 하는법

Posted by epicdev Archive : 2012. 1. 26. 22:22
중첩 루프를 돌면서 어떠한 조건이 만족하면 탈출하는식의 코드를 자주 코딩을 하게 된다.
이런 유형은 대개 아래와 같다.

일반적으로 이런 경우에는 아래와 같은 방법으로 코딩을 하게 된다.
혹은 중첩 루프를 함수로 만들어서 if 절 안의 break를 return으로 바꿔서 한번에 루프를 탈출하는 방법을 쓰기도 한다.
C++의 경우 goto를 사용하면 더 간단하게 이 문제를 해결할 수 있다.
물론 goto는 무조건 사용하지말라고 배웠다면 이러한 방법이 꺼려지겠지만,
거의 유일하게 goto를 써도 욕을 먹지 않는 경우가 바로 아래의 경우이다.
flag에 대한 설명을 주저리 주저리 할 필요도 없고, 코드의 가독성 또한 훨씬 높아진다.
하지만 Java에서는 goto문이 없다. 즉, C++에서처럼 goto를 사용해서 중첩 루프를 탈출 할 수 없다는 것이다.
하지만 Java에서는 이와 비슷한 다른 문법적 장치가 있다.
Java에서는 위와 같이 코딩을 하면 중첩 루프를 한번에 탈출할 수 있다.
왜 이런지 이해가 되지 않는다면 아래처럼 named block을 사용했다고 생각하면 된다.
혹은

'Archive' 카테고리의 다른 글

Python(파이썬)으로 httplib과 urllib을 사용해서 GET하기  (0) 2012.02.05
HeadFirst Javascript (헤드퍼스트 자바스크립트) AJAX 예제 Youcube 변형한 것  (0) 2012.01.31
Encapsulate Downcast (다운캐스트의 캡슐화)  (0) 2012.01.25
Encapsulate Collection (컬렉션의 캡슐화)  (0) 2012.01.25
Introduce Explaining Variable (설명용 변수의 도입)  (0) 2012.01.25
  

시니어 프로그래머, 행복한 프로그래밍 (3)

Posted by epicdev Archive : 2011. 12. 3. 13:09
한 프로그래머가 작성한 코드를 다른 프로그래머가 함께 검토하는 것을 의미하는 코드리뷰는 결코 형식적인 절차가 아니다. 버그를 미리 잡아내기 위한 것도 아니고, 코딩스타일이나 편집스타일을 강제하기 위한 것도 아니다. 코드리뷰를 수행하면 누구든지 자신이 작성한 코드의 내용을 다른 누군가에게 설명해야 한다. 그러한 설명은 일차적으로 코드를 작성한 사람이 스스로 작성한 코드의 내용을 정확히 이해하게 만들고, 이차적으로 코드를 검토하는 사람이 다른 사람이 작성한 코드의 내용에 친숙해지게 만든다. 그것이 핵심이다. 믿기 어렵겠지만 자기가 작성한 코드의 내용을 충분히 이해하지 못하는 프로그래머가 세상에는 생각보다 많다. 표창던지기 초식이나 베끼기 초식을 구사하는 프로그래머는 물론이고, 정상적인 방법으로 코드를 작성하는 사람조차도 유닛테스트를 작성하지 않거나 코드리뷰를 수행하지 않으면 자기가 작성한 코드의 내용을 순식간에 잊어버린다. 그런 사람들은 코드리뷰를 통해서 누군가에게 자기 코드의 내용을 상세히 설명하는 기회를 갖는다면 도움이 될 것이다. 바둑에서도 방금 두었던 바둑의 내용을 다시 검토하는 복기가 바둑실력을 향상하는 데 큰 도움을 주는 것처럼 프로그래밍에서도 코드리뷰는 많은 도움을 준다.


프로그래머그다음이야기프로그래머의길을생각한다
카테고리 컴퓨터/IT > 컴퓨터공학
지은이 임백준 (로드북, 2011년)
상세보기
 

'Archive' 카테고리의 다른 글

정말로 Date를 쓰지않고 Calendar를 써야하는가?  (0) 2011.12.22
파이썬의 Indentation에 관한 미신들  (0) 2011.12.03
시니어 프로그래머, 행복한 프로그래밍 (2)  (0) 2011.12.03
시니어 프로그래머, 행복한 프로그래밍 (1)  (0) 2011.12.03
Java에서 디렉토리내의 가장 최근에 수정된 파일 찾기  (0) 2011.11.20
  

시니어 프로그래머, 행복한 프로그래밍 (2)

Posted by epicdev Archive : 2011. 12. 3. 13:04
그렇지만 개발현장에서 유닛테스트 코드를 습관적으로 작성하는 프로그래머를 만나는 일은 쉽지 않다. 대부분의 프로그래머는 유닛테스트를 작성하는 데 거의 시간을 들이지 않는다. 그들은 요구사항의 윤곽이 대충 드러나면 곧바로 코딩을 시작한다. 코딩을 하다가 길이 막혀서 길이 보이지 않으면 처음으로 돌아가서 설계 자체를 검토하거나 리팩토링을 통해서 근본적인 문제를 해결하려고 노력하지 않는다. 대신 불리언 타입의 글로벌 변수를 선언한 다음, 꽈배기처럼 비비 꼬인 if-else 문장을 표창처럼 흩뿌린다. 그렇게 임시변통을 하고 길을 걷다가 길이 막히면 더 많은 불리언 변수와 더 많은 if-else 표창을 뿌리며 길을 헤쳐나간다. 그러다가 마침내 코드가 동작하는 방식이 요구사항이 설명하는 것과 대충 비슷한 것으로 보이면 손을 털고 일어선다. 프로그래밍이 끝난 것이다. 이렇게 작성된 코드는 당연히 수많은 논리적 오류와 버그를 내포하고 있을 수 밖에 없다. 하지만 걱정 없다. 버그가 보고되면 더 많은 if-else의 표창으로 버그를 잡아 버리면 되기 때문이다. 그리하여 코드는 버그가 하나씩 보고될 때마다 더욱 복잡해지고 난해해진다. 그러다가 마침내 프로그램은 코드를 작성한 프로그래머 자신조차 이해할 수 없는 누더기가 되어 버린다.

 
프로그래머그다음이야기프로그래머의길을생각한다
카테고리 컴퓨터/IT > 컴퓨터공학
지은이 임백준 (로드북, 2011년)
상세보기

'Archive' 카테고리의 다른 글

파이썬의 Indentation에 관한 미신들  (0) 2011.12.03
시니어 프로그래머, 행복한 프로그래밍 (3)  (0) 2011.12.03
시니어 프로그래머, 행복한 프로그래밍 (1)  (0) 2011.12.03
Java에서 디렉토리내의 가장 최근에 수정된 파일 찾기  (0) 2011.11.20
Reflection을 사용한 String Destroyer  (0) 2011.11.16
  

시니어 프로그래머, 행복한 프로그래밍 (1)

Posted by epicdev Archive : 2011. 12. 3. 12:58
프로그래밍은 바둑과 닮은 구석이 많다. 고수와 하수의 관계는 그런 닮은 부분 중의 하나다. 고수인 바둑 1급이 하수인 바둑 5급의 수를 보면 너무 속내가 뻔히 들여다 보여서 웃음이 나온다. 그런데 바둑 5급은 1급의 수를 보면 숨이 막힐 뿐 상대방의 속내를 짐작하기 어렵다. 그렇지만 초절정고수인 프로기사가 바둑 1급이 놓은 수를 보면 어이가 없어서 한숨이 나오는 수가 한둘이 아닐 것이다.

이와 같은 실력의 상대성이 프로그래밍 세계에도 그대로 적용된다. 실력이 뛰어난 프로그래머가 실력이 부족한 사람이 작성한 코드를 보면 답답하고 안타까워서 한숨이 나온다. 리팩토링을 수행하고 싶은 욕구가 절로 일어난다. 실력이 떨어지는 사람은 자기보다 실력이 뛰어난 사람이 신묘한 방법을 동원해서 어려운 문제를 척척 해결하고 깔끔하게 코드를 작성하는 것을 보면 숨이 막히고 탄성이 나온다. 그렇지만 실력이 훨씬 더 뛰어난 사람이 보기에는 그런 뛰어난 프로그래머가 작성한 코드에서조차 마음에 들지 않는 부분이 많을 것이다.

 
프로그래머그다음이야기프로그래머의길을생각한다
카테고리 컴퓨터/IT > 컴퓨터공학
지은이 임백준 (로드북, 2011년)
상세보기

'Archive' 카테고리의 다른 글

시니어 프로그래머, 행복한 프로그래밍 (3)  (0) 2011.12.03
시니어 프로그래머, 행복한 프로그래밍 (2)  (0) 2011.12.03
Java에서 디렉토리내의 가장 최근에 수정된 파일 찾기  (0) 2011.11.20
Reflection을 사용한 String Destroyer  (0) 2011.11.16
Java에서 메소드명(String)으로 메소드 호출하기 예제 (Reflection API)  (0) 2011.11.16
  
 «이전 1 2 3 4 5 6  다음»

티스토리툴바