Какой смысл в фигурных скобках внутри функций?

Question

Синтаксис в порядке, код работает нормально, кроме того, что он выглядит лучше, в чем смысл наличия фигурных скобок внутри функции?

public void Foo() 
{
    string txt = "hello world";
    { <---- THIS
        Assert.AreEqual("hello world", txt);
    } <---- THIS
}

ПРИМЕР: код был создан с использованием IDE Селена

// Generated by Selenium IDE
  [Test]
  public void fsdafdsafds() {
    driver.Navigate().GoToUrl("https://www.seleniumeasy.com/test/basic-select-dropdown-demo.html");
    driver.Manage().Window.Size = new System.Drawing.Size(1696, 1026);
    driver.FindElement(By.Id("select-demo")).Click();
    {
      var dropdown = driver.FindElement(By.Id("select-demo"));
      dropdown.FindElement(By.XPath("//option[. = 'Sunday']")).Click();
    }
    driver.FindElement(By.Id("select-demo")).Click();
    {
      var dropdown = driver.FindElement(By.Id("multi-select"));
      dropdown.FindElement(By.XPath("//option[. = 'California']")).Click();
    }
    {
      var dropdown = driver.FindElement(By.Id("multi-select"));
      dropdown.FindElement(By.XPath("//option[. = 'New Jersey']")).Click();
    }
    driver.FindElement(By.Id("printMe")).Click();
    driver.FindElement(By.Id("printAll")).Click();
  }

Answer 1

При генерации кода может быть полезно использовать фигурные скобки в качестве ограниченного по объему раздела кода, который можно вставлять несколько раз в одном и том же методе, и при этом его локальные переменные не могут запускаться в других «экземплярах» сгенерированного кода. которые появляются в той же области. Также полезным является тот факт, что код отличается от другого кода, и вы можете видеть его в виде «блока», подобного программному обеспечению LE GO, которое собирается на месте для массового производства. Еще одним преимуществом было бы то, что поиск и замена могли бы работать во всех вхождениях этого кода, но вы повторно генерируете код повторно (тогда опасно касаться его, и он выключен -пределы). Но если вы сгенерировали код один раз и вам нужно его оттуда поддерживать, то поиск и замена - это просто Бог!

Но мы не должны отвечать на этот вопрос, не указывая, что все эти копии кода просто «кажутся неправильными». DRY - Не повторяйся - правило очевидно нарушается. Таким образом, для рукописного кода, мы, вероятно, не должны этого делать. Но это указывает на, вероятно, более качественную парадигму, которую можно использовать вместо этого, а именно на использование одного из языков homoiconi c, таких как LISP, Scheme, Forth и Factor, которые также не имеют реального синтаксиса или ограничений ключевых слов, и поэтому вы можете писать в DSL и выполнять собственное метапрограммирование и создание парадигмы вместо генерации кода. Книга, которая поразила меня, была « Let over Lambda » Дуга Хойта, и хотя большая часть ее находится в Интернете, я купил копию для последних глав по оптимизации и его реализации Forth в Лисп (вау!) И оно того стоило.

Answer 2

Фигурные скобки просто ограничивают область видимости. Существует множество материалов для чтения, которые довольно легко найти в topi c из "scope", но проще говоря:

У всего, что определено в фигурных скобках, область действия ограничена этими фигурными скобками, то есть не может использоваться вне фигурных скобок, так как он будет разрушен при выходе из области видимости. Есть несколько причин сделать что-то подобное.

Первый случай показан в вашем примере. var dropdown может быть переопределено в каждой области видимости, таким образом, в первой настройке фигурных скобок dropdown.FindElement() работает с элементом select-demo. Во втором наборе фигурных скобок вы повторно используете то же имя, «раскрывающийся список», чтобы создать новый раскрывающийся объект, поскольку старый раскрывающийся объект вышел из области видимости и был уничтожен. На этот раз dropdown.FindElement() работает на «множественный выбор». В этом примере ограничение объема таким способом не является строго обязательным. Вы можете просто перезаписать var dropdown.

Второй случай включает в себя запуск объектов специальным деструктором. Рассмотрим следующий псевдокод.

public class Timer
{
    int mStart;

    public Timer()
    {
        mStart = Now();
    }

    ~Timer()
    {
        Console.WriteLine("Elapsed Time: {0}", Now() - mStart);
    }
}

public class MainFunction
{
    public static int Main()
    {
        {
            Timer timer();
            DoSomethingWorthTimming();
        } // <-- ~Timer() is called
        {
            Timer timer();
            DoSomethingElseWorthTimming();
        } // <-- ~Timer() is called
    }

Использование этого метода позволяет вам контролировать, когда для объекта вызывается деструктор. В этом случае это позволяет нам определить время блока кода.

Надеюсь, это поможет.