무조건 goto는 나쁘다?

저도 코딩시 goto 를 심심찮게 사용을 하는데요. 주관적인 관점에서 goto 의 사용은 저의 경우, 아래와 같은 경우에 사용합니다.

1. 코딩 생각하기 귀찮을 때. (즉, 직관적으로 goto 를 사용시 충분히 해결할 수 있을 경우.)
2. While 구문 만들기 귀찮을 때.
3. goto 를 제거하기 위해, 함수를 만들기 귀찮을 때.

-_- 즉, 귀찮을 때입니다. 하지만, goto 를 항상 귀찮을 때만 사용하지는 않습니다. 요긴하게 사용될 수도 있지요. 장단점이 항상 있습니다.

다중 루프를 빠져 나올 때, goto 만한게 없다고 하시는 분들도 있으신데, 전적으로 동의합니다. 하지만 goto 를 써야 할 만큼 커다란 다중 루프면 코드를 짤 때, 목적에 대한 접근 방식이 올바른지 한번 생각해 봐야 한다고 생각합니다. 대부분 함수 모듈화를 통해 극복할 수 있으며, 다중 루프에서 빠져나올 때는, 예외 상황 을 많이 염두해 두어야 하지 않을까요. 그만큼 책임감있게 빠져 나와야 할 듯 합니다.

간단하게 만들때는 스파게티가 되든 편한거 때문에 Goto를 가끔씩
쓰게 되더군요 :lol:

크게 만들어본적은 없는데 아직 Goto문 쓰면서
큰 불편함은 느껴본적이 없군요 :twisted:

근데 한가지 이상한게 이런 장점이 있는데도 학원 같은데서 보는걸 보면
Goto문을 아예 안가르치더군요 일부러 그런걸까요

Java 등에서는 다중 루프를 빠져나갈 수 있는 break문을 제공하죠.

goto문이 많이 들어간 코드는 눈으로 따라가며 보기엔 정말 좋지 않은듯요.
goto가 없다고 생각하고 코딩하는 경우 더 깔끔하게 코드가 나오지 않는지요;
습관의 문제.

다중 루프나 루프 안의 switch 문을 빠져나올 때만 씁니다.. -.-;
아니 그럼 이럴 때에는 당췌 어떻게 해야 합니까? -.-;;
C에서요..

93년 이후로는 goto를 쓴 적이 없구나 하고 생각이 드네요. 변수의 조건에 따라 루프를 들어가거나 나오고, 무조건 루프를 돌때는 정해진 만큼만 돌아야 하니 goto를 쓸 일이 없었던 것 같군요.

제 코드의 모든 goto 레이블은 out_of_{.*}_loop: 이랍니다. :)

저는 함수내 리턴용으로 사용합니다.
그외에는 별로 써본일이 없는것 같네요.

중요한 문제는 귀찮다는 것이 아니라, 루프 빠져나오려고 변수 쓰면 goto 보다 더 복잡해지고, goto 사용하는 경우 없어도 될 불필요한 루틴이 추가된다는 점입니다.

상황에 따라서는 정 goto 가 싫으면 함수로 잘 묶어서 리턴해버리는 방법도 있습니다.

존재는 알았지만 하도 사용하지 않는것을 권고 받다보니..
코딩시에 아예 까먹어 버렸군요.

그러고보니 전역변수는 편의(?)에 의해 심심치않게 사용하는데..
goto는 아예 사용을 안하는군요.

뭐.. 이젠 필요성도 느끼지 않지만요.

함수화.. 함수화..

흠.. 이 글을 보고 작업중인 코드를 확인해보니

한군데에 goto를 사용했네요.. ^^;

머리가 나빠서 뭘썼나 기억도 잘 못해서리..

전 필요하다고 생각되면 가차없이(?) 씁니다.

"goto문은 절대로 쓰지 마라"

이 말의 근원은, 과거 베이식이나 포트란 처럼 제어 구문이 발달되어 있지 않은 언어로부터, 제어 구문이 잘 발달된 C 로 넘어오는 과정에서 프로그래머들이 과거의 타성에 젖어 goto 문을 남발하는 상황에서 나온 말이라고 생각되는데요.

일례로 Numerical Recipe 의 C 버젼은 포트란 소스에 대한 직역본으로 수많은 goto 문을 남발하고 있습니다. 특히 공학용 교재의 수치해석 C 소스들에 goto 문이 많은 것을 볼 수 있습니다. 기존 포트란 코드의 영향일 것인데요...

이런 상황이라면 C 개발자들이 히스테리컬하게 '절대 쓰지 마라' 라는 말을 할 수 밖에 없었을 겁니다. 하지만, 현재 상황에서는 이렇게 부정적인 말보다는, "꼭 필요한 곳에만 써라" 정도로 바뀌어야 하지 않을까 생각합니다. 구전되어온 이 말이 뇌리에 박혀서 goto 를 필요해서 쓰면서도 항상 꺼려하는 게 좋지 않게 생각되네요.

잘 쓰면 藥, 잘 못 쓰면 毒.

절대로 못쓸 넘은 아니져^^

근데... 개인적으로는 제 코드에 goto 문을 써본적은 없습니다.

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

운영체제 관점으로 보자면..
"Locality를 해치기 때문에 Goto문을 쓰지 말아라"고 하는 것을 들었습니다.

시각적, 공간적으로 자주 쓰이는 부분이 계속 쓰인다는 것인데.. 운영체제는
이러한 Locality를 활용할수 있도록 만들어져있기 때문에 Goto 문처럼 다른
Local로 건너뛰어버리는 식의 코드는 이러한 Locality를 해칠 수 있다는 뜻이
지요. 프로그램적으로만 해석하자면..

이러한 부분을 놓칠수 있지 않을까 생각됩니다만..

<Quote>goto 문이 반드시 쓰지 말아야 할 것이라면, 아예 그것이 존재하지 않았겠죠. </Quote>

그래서 최근에 나온 고급 언어에는 없습니다. C에는 그냥 호환성을 위해 남아 있다고 보는 게 맞겠죠.

위에 제시된 예제는 아무생각없이 타이핑하기에는 편할지 모르지만 결코 좋은 코드라 생각되지 않습니다.
첫째, 결국 위의 코드가 하고자 하는 목적은 'case_a일때는 'do something A와 do something B에 있는 루틴을 실행하고 case_b일때는 do something B만 시행하라' 입니다.
그렇다면 그러한 알고리즘이 나타날 수 있도록 코드를 작성하는 것이 좋습니다. 하지만 위의 코드는 그러한 workflow를 명시적으로 드러내지 못하고 있습니다.
차라리

if (case_a || case_b)
    {
    if (case_a)
        do_something_only_A();

    do_something_A_and_B();
    }

혹은

if (case_a)
    {
    do_something_only_A();
    do _something_A_and_B();
    }

if (case_b)
    {
    do_something_A_and_B();
    }

이게 더 좋다고 생각합니다. 타이핑할 게 좀 더 많아 지고 if문이 두개가 사용되긴 하지만 실제 원하는 알고리즘과 코드가 일치하므로 가독성 면에서나 알고리즘 검증에 더 유리합니다.

또한 만약 차후 기능이 변경되어서 'case_a일때 do something A를 수행하고 do something B 이후에 do something C를 수행하는 과정이 더 추가되어야 하고 case_b일때는 원래대로 놔두어야 하는 상황(do something B만 수행)이 발생한다면 또는 case_b일때는 do something D를 추가해야 한다면...goto구문은 코드를 수정하는데 걸림돌이 되고 맙니다.

goto는 가독성 면에서나 알고리즘의 이해에 안좋은 점도 있지만 유연성이 떨어지므로 유지 보수 시 코드 수정에도 문제점이 있습니다.

글쎄요...인스트럭션을 조금 더쓰기 싫어서 즉, goto를 쓰는게 한순간 편하다고 해서 쓴다는 것은 문제가 있다고 봅니다...게다가 지금 당장은 저 코드가 문제가 없다 하더라도 훗날 기능 추가나 변경 등의 유지 보수 단계에서 이 코드가 씨앗이 되어 스파게티가 되지 않는다고 어떻게 장담할 수 있습니까?
리펙토링이나 디자인 패턴과 같은 것들이 요즘 사람들에게 많은 이슈가 되고 있는 것은 이제는 현재 구현할 기능을 얼마나 빨리 쉽게 만드느냐 보다 앞으로 이 코드를 가지고 얼마나 오래 울거먹을 수 있느냐하는 것이 중요하기 때문입니다...
goto는 코드의 재사용이 사실상 거의 불가능하다며 알고리즘을 제대로 반영하지 못하는 등의 단점이 있습니다.

"좋은 코드" 라는 포괄적인 얘기를 하자면, 제가 제시한 1, 2, 3 이 "상황에 따라" 좋은 코드가 될 수 있다고 말씀 드릴 수 있겠죠. 그리고, 물론 goto 를 쓴 코드도 상황에 따라 좋은 코드가 될 수 있다고 말씀드릴 수 있습니다.

말씀하신 이슈가 되는 바에 대해서는 저도 중요하다고 생각합니다. 제가 goto 를 주장하는 것이 말씀하는 이슈들에 역행하는 것으로 오해하진 않으셨으면 합니다.

동의 할 수 없습니다. 이유는 이전의 제 글이나, goto 를 옹호하는 입장을 가지신 분들의 의견에 이미 있을 것이고, 코드 재사용이 불가능하다거나 알고리즘이 제대로 반영되지 않는 단점 같은 것은 saxboy 님께서 말씀하신
Structured Programming with goto Statements
이 글로 해결될 수 있을 겁니다.

'상황에 따라' 라고 말씀 드린데에 유념해 주세요. 필요한 상황이 있기 때문에 호환성을 위해 남아있는 것이 아니라고 말씀드린 겁니다.

* 좀 더 읽어보니, 저는 인스트럭션을 조금 더 쓰기 싫어서라고 말씀드린게 속도 최적화 관점에서 말씀드린 것인데 "인스트럭션을 조금 더쓰기 싫어서 즉, goto를 쓰는게 한순간 편하다고 해서 쓴다는 것은 문제가 있다고 봅니다." 이런 의미로 오해하신 게 아닌가 생각되네요.

goto를 쓰지 말라 해서 안쓴다기 보다는 그다지 쓸 일이 안생기더군요.

제 생각엔 생각하는 스타일 자체가 goto 랑 if/else/for 중첩과는 조금 다르다고 생각합니다.

그래서 주로 한 스타일로만 생각하는게 편해서 아예 다른 스타일로는 생각할 여력도 없더군요..

뭐 사실 if else for 중첩도 심해지면 정말 이해하기 힘듭니다. 뭐 제가 코드를 잘못 짜서 그럴 수도 있겠지만 case 와 그 안의 if else 로 파서를 구현했는데 정말 죽을 맛이었죠.(직접 만든 IRC클라이언트의 mIRC의 컬러 루틴 파서였습니다만..)

goto로도 얼마든지 간단하고 이해 가능하게 짤 수 있을테고, 중첩문으로도 얼마든지 햇갈리게 못짤 수 있다고 봅니다.

goto를 쓰지 말라! 에 내포된 진짜 이야기는, 명령어의 문제라기 보다는 프로그래밍을 이해하기 어렵게만 안짜면 된다는 이야기겠죠.

음 하지만 역시 goto를 쓰면 OpenGL의 스펙 문서의 "3.3.1에 무슨무슨 디테일이 나와있습니다." 이런식으로 나와있는것 처럼 정말 귀찮은 코드가 될 가능성이 높겠지요.

뭔가 스크롤을 바꾼다는건 이런거랑 비슷한지 않나요? "다른 곳으로 갔다가 온다." 사무실 A 에서도 할 수 있는데 사무실 B 사무실 C~Z 옮겨가며 하면 정말 귀찮죠. 중복되는 내용이 있더라도 OpenGL 문서가 "3.3.1에 좀 더 디테일이 써져 있습니다" 라는 식이 아닌, 그자리에서 모두 중복될지라도 디테일을 자세히 설명했다면 좀 더 보기 좋았을 거란 생각이 듭니다. MSDN의 OpenGL 문서는 그렇게 되어 있지요. 뭐 물론 별반 차이 없다고 보시는 분들도 계시겠지만.. 가끔 힘든일을 하다보면 사소한 일에도 짜증이 나는 법이라서;;

뭐 물론 AcroRead 의 "뒤로가기" 기능에 익숙해지고 나면 이런 것도 불편한 건 못 느끼지만요. 오히려 중복되는 내용이 많아서 짜증나는 경우도 있겠죠.

뭐 결국 GOTO문의 문제는 "익숙하지 않은 할 일"이 너무 많아지기에 짜증나는 경우랄까요.. :$

C 의 goto 가 단지 호환성을 이유로 남아있다는 말씀에 대한 반론이었고, 단편적인 예였습니다. 그러나 실재 발생할 수 있는 상황이고 발생했던 상황입니다. 그냥 예제를 위한 예제는 아니었구요.

최근의 고급언어들이 다중 루프를 빠져나오거나, 예외 처리를 지원하는데, C 는 그런 것이 없어서 어쩔 수 없이 goto 가 있는 게 아니냐라는 주장에 대한 반론이지요.

goto 를 문제를 쉽게 풀기 위한 목적으로 사용한 개발자라면, 그것은 goto 를 남용하는 상황이겠죠. 저도 이것은 반대입니다. '최선'이라는 관점에서 사용해야 한다는 것입니다.

속도 최적화는 열악한 환경이기 때문에 하는 것이 아니라, 더 빠른 것을 원하기 때문에 하는 것입니다. 하나의 예를 원하신다면 소프트웨어 렌더러를 만들때 goto 를 써서라도 최적화합니다. 이것은 열악한 환경이기 때문에 사용되는 goto 가 아닙니다. 삼각형 스캔라인 렌더링 루틴에서 인스트럭션 하나를 줄이는 것은 전체 그래픽 렌더링 성능에 적지 않은 영향을 미칩니다. 이것은 알고리즘이나 자료 구조 최적화로 해결할 수 없는 문제 입니다.

물론 알고리즘과 자료 구조에 의한 최적화가 매우 중요한 것이 사실이고 이것은 반론의 여지가 없습니다. 그러나 좋은 알고리즘과 자료구조가 적용된 이후의 최적화는 인스트럭션을 줄이는 것입니다.

최근에 실시간 하드웨어 렌더링이 비약적으로 발전했지만, 여전히 실사에 가까운 화질을 낼 수 있는 비실시간 알고리즘은 하드웨어에 적용되지 않습니다.

     if (malloc1 == error)
          goto error1
     if (malloc2 == error)
          goto error2
     if (malloc3 == error)
          goto error3
     Do_Job
     return OK

error3:
     free3
error2:
     free2
error1:
     free1
     return ERROR

단계적으로 resource를 받아서 처리하는 부분에서 중간에 하나의 resource를 얻지 못해서 이전에 받은 resource를 모두 해제해는 경우라면 goto를 쓰는게 가장 좋지않을까 합니다.

저는 그러한 경우 아래와 같이 작성합니다...

int i = ERROR;
if (malloc1 != error)
    {
    if (malloc2 != error)
        {
        if (malloc3 != error)
            {
            Do_job
            i = OK;
            free3
            }

        free2
        }

    free1
    }

return i;

예전 devpia에서도 이 스타일에 대해서 글을 쓴적이 있는데 예상대로 중첩 if문에 대한 반발이 심하더군요... 8)
하지만 그건 이런 중첩 if문 스타일에 익숙하지 않기 때문이고 이런 것에 익숙해 진다면 goto를 사용하는 것보다 유지 보수나 리펙토링에 훨씬 유리한 코드라 생각합니다.
적어도 제 경험상으로는 그렇습니다... :wink:

와우! 역시 andrei...라는 말밖에는...
마지막에 RefHolder class에 대한 글에 가서는 완전히 두손 두발 다 들고 말았습니다... :shock:
정말 좋은 것 배웠네요... :wink:

말씀하신 것들이 대부분 옳습니다. 그리고 그런 것이 틀리다고 얘기하는 것이 아니라는 것을 미리 말씀드린 것 같구요. 관점과 그 범위의 차이에 의해 다른 의견이 나오는 것으로 생각됩니다. 예를 들어

일단, 그 이유는 게임 성능의 80~90%를 점유하는 그래픽 렌더링 부분이 하드웨어에서 지원되는 시대이기 때문입니다. 그래서 저는 소프트웨어 렌더러를 말씀드렸고, 하드웨어에서 지원되지 못하는 렌더링 기법이 아직 많다고 말씀드렸지요.

게임의 성능과 goto 를 논하기엔 게임은 너무 범주가 커서, goto 를 사용하냐 마느냐는 매우 편협한 하나의 상황에 해당합니다. 게임 하나를 놓고봐도, 온갖 객체 지향 기술을 적용할 수 있는 부분이 있고, 그것이 유리한 부분이 있는가 하면, 그렇지 않은 부분도 있습니다.

말씀하신 다른 예들에 대해서도 저는 관점과 범주에 서로 차이가 있다고 봅니다.

그래서, 아주 미세한 차이로 여겨지는 다음 두 주장이 오고가는데,

저는 두번째를 주장하는 것이며, 사실 두 주장의 차이는 크지 않습니다. 어떠한 최신 이론을 적용하든, 저 두 주장에 대한 판단은 결국 "상황에 따라" 개발자 가 하는 것이라고 말씀드리는 것까지로 제 주장을 마치고 싶습니다. 저 미세한 차이는 좁혀지지 않는 것이라 생각하고, 좁힐 필요가 없다고 보여지네요.

goto로 빠져나와야하는 상황은 대체로 return으로 빠져나올 수 있고 그렇게 함수를 구조화시키는 것이 대체로 더 좋은 코드입니다. 그리고 goto와 return의 속도 차이가 중요해지는 경우는 "없다"라고 해도 큰 과장이 아닐 겁니다.

goto를 분기하는데 사용하는것이 일반적이지만.. 약간 모양새를 달리하면
label, goto를 사용해서 재사용은 불가능하지만 그럭저럭 함수형태를 만들수 있습니다.
어떤 언어에선 예외처리로 사용하기도 하더군요..

예전에 베이직 언어나.. 코볼같은 경우, goto만으로 프로그램이 만들어질만큼 goto의 의존성이 높았더군요. 21세기에 살면서 19세기때 만든것 같은 코볼 소스를 본 적이 있습니다. ;;

그때는 소프트웨어 공학적 측면에서나 언어의 수준등이 지금보다 한참 뒤떨어졌을때가 아닌가 싶은데.. 요즘엔 goto를 쓸 이유는 전혀 없어 보입니다.
적어도 새로 개발되는 프로그램에선 말이죠..
하지만 기존에 잘 돌아가던 프로그램이 goto로 도배 되어있다면 전 그 방식을 그대로 따를 겁니다. -_-

데몬같은거 만들때(C 로) 메모리 누수 막기에는 효과적인 코딩이라 생각해 한표 던지고 갑니다.

개인적인 취향의 문제인데요...

물론, goto를 안쓰고, 얼마든지 해결할 수 있습니다.

break를 사용하던가, 혹은 함수의 return 키워드로 빠져나가던가,

메모리같은 경우도 루프가 포함된 함수밖에서 할당한 후
포인터로 인자를 통해 넘겨서, 함수가 돌아올때 해제하는 식으로
해결할 수 있습니다.

다소 작위적이고 무리해보이는 goto 사용이
소스의 가독성에 도움이 되는지는 고민해 보아야 하죠...

소스의 가독성이란 부분은 어느 일부분은
개인의 성향에 따르는 부분이므로, 쉽게 정의내리기 어렵다는 생각입니다.

루프안에, break를 사용한 것이나 return 키워드로 빠져 나간 것이
goto를 쓰는 것과 별반 차이가 없다라고 생각이 드는 사람과,
goto와 label 자체에 익숙하지 않아서...
이게 도대체 뭐하는 키워드야 하는사람이 있다면... 결과는 판이할 수 있다는 생각입니다.

예외처리같은 부분에서 goto를 사용했는데 paging이 자주 일어난다면 그것은 더 이상 예외가 아닐겁니다.

그런데 c#이나 java에서도 goto를 지원하는데
이건 쓰라고 만든거 아닌가여?
쓰지 말라고 하면서 왜 goto는 지원하게 하는지 궁금..

비유해보자면, goto는 가벼운 병에 걸렸을 때 먹으면 잘 듣는 약 정도로 생각합니다. 약을 복용하지 않아도 병이 자연치유되지만, 적당한 때 적당히 복용하면 효과를 빨리보는 그런 약 말이죠. 물론 남용하면 건강을 해치게 되니까 정말 필요 할 때 제한적으로만 복용하는것이 원칙이겠죠.

이 경우에도 여러가지 '조언'들이 가능합니다. 어떤 사람은 어차피 자연치유될 수 있는것이니 절대로 약을 먹지 말라라고 얘기할수도 있고, 아니면 정석대로 적당한 때에 적당히 복용하는것은 필요하다던지, 그냥 귀찮으니 아플때마다 복용하는것도 괜찮다라고 한다던지하는등등의 얘기들..

그냥 그 이상의 의미는 없는것 같네요. 위의 사항과 함께 "정말 복용이 필요 할 때"가 언제인지 정도만 숙지하고 있으면, 별로 논란이 될만한꺼리조차 되지 않는다는게 제 생각입니다만, 뭐가 이렇게 goto에 대해 시끄러운지 모르겠습니다. (물론 꼭 이곳사람들만 지칭하는게 아니라 여러곳에서 다소 소모적인 goto사용에 대한 토론이 산발적으로 일어났던것을 알고 이런 얘길 하는겁니다.)

개인적으로 과거 goto사용에 대한 마소의 기사 한편에 많은 사람들이 낚인것 같다는 생각이 드는군요. 다익스트라의 고전을 파헤친건 의미있는 시도였지만, 끝을 명확하게 봉합하지 못한것이 아쉬운 부분입니다.

어쨋든 goto라는것으로 꽤 많은 프로그래머들이 제대로 낚였습니다.

막연한 추측은 가능하죠. program의 size가 커서 많은 page를 점유한 상황에서 goto로 이리저리 왔다갔다 하면 많은 page를 access 해야하니까 page fault 확률이 높아지겠죠. 마찬가지로 cache miss도 많아질 수 있구요. 하지만 별다른 통계적인 근거가 없는 이상 "X Window가 C/S 구조니까 느리지!"와 같은 수준의 막연한 추측일 뿐, 신뢰할 만한 근거는 아닙니다. 언제나 profiling 없는 퍼포먼스 논의는 무의미합니다.

게다가 어차피 goto를 method call 같은 걸로 대체한다면 jump가 일어나는 건 똑같기 때문에 goto의 책임인 것도 아니죠.

goto 를 유일하게 써서 이득을 보는 곳은 다중 루프 빠져나가기인데
이에 대한 것도 s모님께서 이미 언급하셨듯 Knuth 할아버지께서 해법을 내놓으셨습니다.
이것은 라인에 레이블을 붙이는 것이 아니라 루프나 블럭에 레이블을 붙이고
break loop1 하면 얼마나 깊이 들어왔든 그냥 loop1 바깥으로 튀어나가는 거죠.
이게 있으면 하면 goto를 쓰는 모든 프로그램과 똑같은 효율을 갖는 프로그램을
goto 없이도 작성할 수 있다는군요. 그러나 이게 있으면 goto 를 쓸 이유가 없습니다.

자바에도 이게 있죠.

이게 지원되지 않는 언어에서 다중루프를 빠져나올 때
실행 속도에 조금도 손해를 보기 싫다면
goto로 빠져나가는 것은 유일하게 허용할 수 있겠죠.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

윗글과 중복되어서 지웁니다. -_-;

§ 햇.살.이.항.상.그.대.의.길.에.빛.나.길.

쓰라고 만들어놓은걸 왜 자꾸 쓰지말라고 하는걸까 ㅠㅠ

goto 문은 저 역시 사용하지 않은 지가 15년도 넘었습니다.

결정적으로 goto 문을 사용하지 않게 된 동기는 바로 N.S chart 덕분이었습니다.

86년에 처음으로 플로우차트를 배웠는데 템플릿까지 사서..... ㅠㅠ

그해 여름, 갑자기 N.S 차트를 알게 되었습니다.

N.S 차트를 이해하다보면 goto 사용은 엄청나게 줄어듭니다.

그렇다고 아예 쓰지 말라는 건 아닌데요.

아마 goto 문을 어쩌다 쓰는 건 문제가 없겠죠.

하지만, 위에서 말씀하신 스파게티 코드(제 경험상 스파게티 국수 생각보다 잘 엉기지 않습니다^^)라기 보다 라면 코드를 만드시면 곤란합니다.

자기가 짜고도 못 읽을 수준이라면 그건 더이상 유지보수하곤 담 쌓은 절대 하지 말아야 할 것이 되겠죠. 언어가 무엇이든지 간에요.

요즘은 nested if를 너무 복잡하게 써서 정신이 하나도 없게 하는 경우가 더 많은 것 같습니다.

goto 문은 일반 어플리케이션에서는 거의 본적이 없네요.

There's always another way, dear.

시대적으로 봤을 때...

구조적 패러다임의 시대!!

순차문, 분기문, 반복문으로 모든게 해결가능하지(?) 않을까란 인식이 점차 확산되는 시대였는데...

GOTO문이 구조적 패러다임의 걸림돌처럼 느끼지 않았을까라고 조심스레 추측해봅니다.

물론 다음 패러다임시대에서는 더욱 극악이죠. 객체지향!! GOTO OUT!!