Операторы GoTo и альтернативы в VB.NET

Я собираюсь отличаться от всех остальных и сказать, что GOTO сами по себе не все зло. Зло исходит от неправильного использования GOTO.

В общем, почти всегда есть лучшие решения, чем использование GOTO, но действительно бывают случаи, когда GOTO - правильный способ сделать это.

При этом вы новичок, поэтому вам не должно быть позволено судить, является ли GOTO правильным или нет (потому что это почти никогда) в течение еще нескольких лет.

Я бы написал ваш код так (мой VB немного ржавый ...):

Dim valid As Boolean = False

While Not valid
    Console.WriteLine("Please enter the day you were born: ")

    Dim day As String

    day = Console.ReadLine

    If day > 31 Or day < 1 Then
        Console.WriteLine("Please enter a valid day.")
    Else
        valid = True
    End If
End While

Если вы возьмете свой код GOTO и посмотрите на него, как кто-то сначала подойдет к вашему коду? «Хм ... retryday? Что это значит? Когда это произойдет? О, значит, мы переходим к этой метке, если день выходит за пределы допустимого диапазона. Хорошо, поэтому мы хотим выполнить цикл до тех пор, пока дата не будет считаться действительной и находящейся в диапазоне» .

А если вы посмотрите на мой:

«О, мы хотим продолжать делать это до тех пор, пока он не станет действительным. Это действительно, когда дата находится в пределах допустимого диапазона».

http://xkcd.com/292/ Я думаю, что это стандартное мнение GoTo.

Вместо этого попробуйте использовать цикл Do Until. Do Until циклы всегда выполняются один раз и отлично подходят, когда вам нужно побудить пользователя и вы хотите убедиться, что вы не продолжите, пока он не введет правильную информацию.

Sub Main()
    'Every time the loop runs, this variable will tell whether
    'the user has finally entered a proper value.
    Dim Valid As Boolean = False

    'This is the variable which stores the final number which user enters.
    Dim Day As Integer = 0
    Do Until Valid
        Console.WriteLine("Enter the day:")
        Dim DayStr As String = Console.ReadLine()

        If Not Integer.TryParse(DayStr, Day) Then
            Console.WriteLine("Invalid value! It must be a valid number.")
            Valid = False
        ElseIf (Day < 1) Or (Day > 31) Then
            onsole.WriteLine("Invalid day! It must be from 1 to 31.")
           Valid = False
        Else
           Valid = True
        End If
    Loop

    'blablabla
    'Do whatever you want, with the Day variable
End Sub

Конструкция GOTO производит код сфагетти. Это делает практически невозможным отслеживание кода.

Процедурное / функциональное программирование - гораздо лучший подход.

Вопросы о достоинствах заявления GoTo (или, скорее, об отсутствии такового) на этом сайте постоянно возникают. Щелкните здесь, чтобы увидеть пример: Является ли GoTo по-прежнему опасным?

Что касается альтернативы GoTo, в предоставленном фрагменте кода неплохо подойдет цикл while, может быть, что-то вроде:

day = -1
While (day < 0)
   Console.WriteLine("Please enter the day you were born : ")
   day = Console.ReadLine
   If day > 31 Or day < 1 Then
     Console.WriteLine("Please enter a valid day")
      day = -1
   End If
End While

GOTO - это довольно политический вопрос. «Решение» для GOTO - использовать другие встроенные конструкции навигации, такие как функции, методы, циклы и т. Д. Для VB вы можете создать подпроцедуру, которая запускает этот код, или поместить ее в цикл While. Вы можете довольно легко погуглить обе эти темы.

Немного неуклюже, но:

    Dim bContinue As Boolean

    Console.WriteLine("Enter a number between 1 and 31")

    Do
        Dim number As Integer = Console.ReadLine()
        If number >= 1 AndAlso number <= 31 Then
            bContinue = True
        Else
            Console.WriteLine("Please enter a VALID number between 1 and 31")
        End If
    Loop Until bContinue

Также рассмотрим некоторые основные петли в "goto land"

        Dim i As Integer
startofloop1:

        Debug.WriteLine(i)
        i += 1
        If i <= 10 Then
            GoTo startofloop1
        End If

        i = 0

startofloop2:

        Debug.WriteLine(i * 2)
        i += 1
        If i <= 10 Then
            GoTo startofloop2
        End If

Вот хороший эквивалент:

   For x As Integer = 0 To 10
        Debug.WriteLine(i)
    Next
    For x As Integer = 0 To 10
        Debug.WriteLine(i * 2)
    Next

Что более читабельно и менее подвержено ошибкам?

Использование goto уже несколько десятилетий считается плохой практикой. Возможно, это была негативная реакция на исходный BASIC (до Visual Basic). В исходном BASIC не было циклов while, локальных переменных (только глобальные) и (в большинстве версий BASIC) функции не могли принимать параметры или возвращать значения. Более того, функции не были явно разделены; управление может неявно переходить от одной функции к другой, если вы забыли оператор RETURN. Наконец, отступы в коде были чужеродным понятием для этих ранних BASIC.

Если вы какое-то время использовали исходный BASIC (как я), вы бы оценили, как повсеместное использование глобальных переменных и gotos делает большую программу трудной для понимания и без особой осторожности превращает ее в запутанный беспорядок. "спагетти". Когда я изучил QBASIC с его циклами WHILE..WEND и SUB, я никогда не оглядывался назад.

Я не думаю, что gotos вредят в небольших количествах, но в культуре кодеров сохраняется сильное чувство, что они в чем-то злы. Поэтому я бы избегал gotos только по одной причине, кроме как во избежание оскорбления чувств. Иногда я обнаруживаю, что goto решает проблему чисто (например, выход из внешнего цикла из внутреннего цикла), но вы должны подумать, делает ли код более читаемым другое решение (например, поместите внешний цикл в отдельную функцию и используйте " функция выхода "вместо goto во внутреннем цикле).

Я написал программу на C ++ примерно с 100 000 строк кода и 30 раз использовал goto. Между тем существует более 1000 «нормальных» циклов и около 10 000 «если» операторов.

Функции FTW!

Хорошо, я не уверен, действительно ли ваш код здесь VB.Net, так как у вас есть кое-какие странные вещи (например, Console.Readline возвращает String, а не число, с которым вы можете сравнивать) ... так что мы ' Забуду на время о типе.

Console.Writeline("Please enter the day you were born : ")
day = Console.Readline()

While not ValidDate(day)
   Console.WriteLine("Please enter a valid day")
   day = Console.Readline()
End While

И отдельно

Function ValidDate(day) As Boolean
  Return day > 31 Or day < 1
End Function

Или вы могли бы повеселиться с синтаксисом рекурсии и раннего возврата! ;)

Function GetDate() As String
  Console.Writeline("Please enter the day you were born : ")
  day = Console.Readline()

  If ValidDate(day) Then Return day 'Early return

  Console.Writeline("Invalid date... try again")
  GetDate()
End Function

Вы можете делать почти все, что можете делать с GOTOs, с помощью простых встроенных языковых конструкций, таких как структуры принятия решений и циклы, а операторы GOTO часто создают беспорядочный, непонятный спагетти-код. Циклы, «если» и тому подобное имеют четкое, приемлемое и понятное использование.

См., Как обычно предлагают, Заявление Дейкстры о переходе, которое считается вредным

Часто рекомендуется следовать совету Дейкстры в «Заявлении о вреде».

Дональд Кнут довольно убедительно ответил Дейкстре. Этот пример является современной версией одного из его контрпримеров. Лично я пишу бесконечные циклы с внутренними перерывами, когда сталкиваюсь с этим, но есть несколько других редких случаев, когда я буду писать операторы GOTO.

Наиболее распространенными для меня являются выход из глубоко вложенных циклов и такой шаблон:

ContinueTry:
   Try
        'Worker code
   Catch ex as IO.IOException
        If MessageBox.Show(...) = DialogResult.Retry Then Goto ContinueTry
        Throw
   End Try

У меня также есть два случая больших конечных автоматов с операторами goto, обеспечивающими переходы.

Я брошу свой, даже если волки «по книге» будут голосовать против. Взгляните на: Выгодно ли когда-нибудь использовать goto в языке, поддерживающем циклы и функции? Если да, то почему?

Я должен согласиться со всеми здесь: GOTO сам по себе не является злом, но неправильное его использование, безусловно, сделает вашу жизнь несчастной. Есть так много других управляющих структур на выбор, и хорошо написанная программа обычно может обрабатывать практически любую ситуацию без goto. При этом я нахожусь почти на этапе завершения программы, которая содержит около 15000 строк, и я использовал один и только один оператор GOTO (который я, возможно, заменю, мы увидим). Я впервые использовал GOTO из последней дюжины программ, с которыми мне приходилось иметь дело. Но в этом случае он избавился от ошибки компилятора (используя Me.Close () дважды в одном и том же Sub, но в разных структурах If; я мог бы подавить его, но я просто добавил метку и заменил один Me.Close () на a GoTo CloseLabel). Если я начну сталкиваться с большим количеством экземпляров, требующих Me.Close () в этой подпрограмме, я, вероятно, помещу Me.Close () в ее собственную подпрограмму и просто вызову эту подпрограмму из структур If или других циклов, которые приведут к закрытию программы ... Как я уже сказал, есть альтернативы, но иногда и при очень редком, экономном и стратегическом использовании GoTo все же может быть полезен. Просто остерегайтесь спагетти-кода, это мерцающий беспорядок, лол

Ваш код в порядке. Это лаконично и понятно. Это лучше, чем раздувать работу на 50–200% дополнительными переменными и разными глаголами, которые делают то же самое.

Если вы просто переходите назад или вперед к началу или концу логического блока, тогда перейдите (к) для этого. «Цикл» или «Конец в то время» все еще остается переходом, но адрес назначения подразумевается. Единственное преимущество заключается в том, что компилятор не позволит вам создать перекрестные пути двух циклов, но не с парой goto. При использовании goto не пересекайте потоки. Это было бы плохо. - Доктор Шпенглер

Другая моя любимая мозоль - это правило «один вход - один выход». Конечно, у вас может быть только один вход, если вы не пишете на ассемблере. Но правило «одного выхода» глупо. Это просто приводит к набору вложенных проверок границ, которые уводят ваш код за пределы правого поля. Гораздо понятнее проверить все ваши параметры в верхней части подпрограммы и «выход из подпрограммы», если они недопустимы. Что имеет больше смысла?

if badparam then
  log error
  exit sub
  endif

if badparam2 then
  log error2
  exit sub
  endif

do stuff

или это?

if goodparam then
  if goodparam2 then
    do stuff
  else
    log error2
    endif
else
  log error 
  endif 

Когда у вас есть шесть проверок границ, а «материал» - это 60 строк, которые вы не можете разбить на более мелкие части, тогда второй способ превращается в кошмар для всех, кто должен его поддерживать. Лучше завершить то, что вы делали - проверку исключений, - чем откладывать всю обработку исключений до конца.

My $0.02