제가 맞게 이해한 것인지는 모르겠지만, if else if 대신 nested 구조를 줄이기 위해 if - if 구조를 사용하게되면 참거짓을 계산하는 과정이 중복되지 않나요? 간단한 계산이면 모르겠지만 복잡해지면 그에 따른 시간 손실이 있지 않을까 싶습니다.
그리고 다른 프로그래머가 봤을때는, if - elseif가 서로 배타적인 case임을 읽어보지않고도 알 수 있지만, if - if 가 이어져있다면 직접 평가되는 boolean 값을 해석하고나서야 아 서로 연관이 있구나내지는 동시에 실행되지는 않겠구나라는 것을 알게되는 불편함이 있을 것 같습니다.(물론 코딩스타일에 대한 우선적인 합의가 되었다면 이 쪽이 가독성은 더 좋을수도 있겠습니다)
말씀하면 대로 if elseif가 추할정도로 이어지는 상황이면 개별적인 if보다는 switch문(없는 언어도 있지만..)을 사용하는 것은 어떨까 싶네요.
indioindio님
그러게요..
단순히 괄호 중첩을 줄이는것만 생각하다가 예시를 이상하게 든 듯 합니다.
실제로 저도 [3]의 방식으론 쓰는일이 거의 없구요.
지적 감사합니다!
[1]
if ( a ) {
a가 true일경우 처리;
} else {
if ( b ) {
a가 false이고 b가 true일경우 처리;
} ...
} ...
[2]
if ( a ) {
a가 true일 경우 처리;
} else if ( b ) {
a가 false이고 b가 true일 경우 처리;
}...
[3]
if ( a ) {
a가 true일 경우 처리;
}
if ( !a && b) {
a가 false이고 b가 true일 경우 처리;
}
에서 [1]은 확실히 별로인 방법이라 생각하지만, [3]도 확실히 추가연산 및 이해에서 안좋은게 맞네요.
역시 글에 쓴대로 댓글에 쓰신 고수님의 의견이.. 더 팁이되네요!
댓글에 원문을 남겼으니 글 내용은 수정하겠습니다.
와아아.. :fan:
매우 좋은 팁 감사합니다. 저도 사실 if else if문 말고, return문을 자주 애용하는 편입니다. 말씀하신 것 때문입니다.
그리고 조건 판단문이 복잡해 진다면 역시 함수로 뺍니다.
반복되는 기능은 모듈화를 잘 시키는 것도 중요하더라고요.
모듈화를 잘 시키면 작은 단위로 테스트 하는 것 역시 쉽습니다. 그게 안 되어 있고 Main에만 좌르륵.. 200줄, 300줄.
읽기는 합니다만.. ㅋㅋㅋ 좀 고됩니다. ㅠㅠ
사실 제가 다른 분들 질답글에 나온 코드를 디버깅 하는 방법 중에는
몇 개 단위로 주석 처리하고 시작하는 경우가 많은데요. (눈으로 훑어 보았는데 잘 안 보이는 경우에)
상대적으로 잘 나뉘어져 있으면, 후보해를 빠르게 좁혀 나갈 수 있어서 편합니다.
특히 알려져 있는 역량 테스트 문제의 경우 그런 경향이 상당히 강하게 나타나는데
이러한 부분은 반복되는 연산이 무엇이 있는지를 먼저 생각해 보고 구현한다면 상대적으로 쉽게 구현할 수 있어요.
이게 사실 쉬운 편이면 그냥 구현해도 문제는 없지만, 13460번이라던지 큐빙, 혹은 2x2x2 큐브와 같이 꽤 어려운 경우에 저는 함수 선언하는 것을 아끼지 않습니다.
그게 힘드시다면 다른 분들 코드 보는 것도 괜찮은 듯 싶어요.
ps. 초기화 잘 시키는 건 기본 중에 기본인데 가끔 저도 초기화 잘 안 시키고 제출하다가 틀리는 경우가 많더라고요.
감사합니다. 저도 if에서 return 쓰는 것은 동의합니다. 함수가 특정조건을 만족해야만 실행될 때 if elseif 보다는 if return으로 막아주고나서 나머지코드를 실행하는 것이 훨씬 이해를 돕죠.
뿐만 아니라 중첩된 for문에서 나와야 할때도 if flag break;break;보다는 함수로 뺀 다음 return으로 나오는 것을 좋아하지만, 이건 취향 문제 같기도 하네요.
댓글에서 고수의 느낌이.. 감사합니다!
맞습니다. 반복되는 부분을 잘 찾아 모듈화시키고,
OOP쪽이라면 추상화도 적절하게 해서 반복되는 부분을 최대한 줄여야 좋은 것 같아요.
그리고 공간을 더 써서 간략화 시키는 방법도 있습니다.
더미 데이터를 두는 방법이 그 중 하나입니다. 예를 들어서 Linked List에서 삽입/삭제 연산을 할 때
더미 데이터가 없다면, 삽입하는 경우의 수 3개, 삭제하는 경우의 수 3개를 모두 고려해야 하지만.
Head 더미 데이터랑 Tail 더미 데이터만 둔다면
중간에만 삽입하고, 중간에만 삭제하는 경우만 고려하면 되거든요.
댓글을 작성하려면 로그인해야 합니다.
© 2023 All Rights Reserved. 주식회사 스타트링크 | 서비스 약관 | 개인정보 보호 | 결제 이용 약관 | 도움말 | 광고 문의 | 업데이트 노트 | 이슈 | TODO
nahwasa 4년 전 7
전 이제 일주일차 늅늅이라 감히 이런글을 적긴 좀 그렇지만
문제 풀고난 후 다른분들 코드도 어떤식인지 구경하는편입니다.
솔직히 주석 달아놔도 복잡하게 짜여져있으면 아마 본인도 다시 읽기 힘들것같은 코드들이 꽤 보입니다.
그래서 올려봅니다.
제 개인적인 방식이므로 물론 정답은 아닐 수 있습니다.
아마 댓글에 달아주실 고수분들의 의견이 더 팁이될것같습니다.
- 예외의 경우 최대한 else 쓰지말고, 그냥 바로 거기서 끝내세요.
[1]
if (n == 0) {
출력;
} else {
n이 0이 아닌 경우 처리;
}
[2]
if (n == 0) {
출력;
return;
}
n이 0이아닌경우 처리;
- 처리 순서가 복잡할 경우에도 역시 else를 최대한 아끼세요.
[1]
if ( a ) {
a가 true일경우 처리;
} else {
if ( b ) {
a가 false이고 b가 true일경우 처리;
} ...
} ...
[2]
if ( a ) {
a가 true일 경우 처리;
} else if ( b ) {
a가 false이고 b가 true일 경우 처리;
}...
a가 false일경우 처리할 양이 많다고 else로 나눠서 처리하는 방식으로 할 경우
복잡하지 않을때면 그게 더 이해가 잘 될수 있으나,
문제가 복잡해질수록 인덴테이션은 점점 안쪽으로 복잡해지고..
(a가 false고 b가 true면서 c는 true고 d는 false일경우!)
결국 주석 달아도 나중엔 그냥 보기도 싫은 코드가 됩니다. 일종의 습관이죠.
... {
...
{
{
....
}
}
}
이런거요.. 주석 달아놔도 가독성은 노답입니다.
- 어쩔수없이 중첩이 많이되야한다면 적당한 선에서 함수로 빼버리세요.
[1]
for (.. ) {
for (.. ) {
for (.. ) {
if(.. )
}
if(.. )
for (.. ) {
}
}
}
[2]
for (.. ) {
for (.. ) {
doSomething(.. );
}
}