Rust's Block Pattern

There are DRY and WET principles. We can argue which one of them is better, but to move something used exactly once to a method just due to an anxiety you can need it again seems to me a little bit too much. I move things into functions that are called once, but iff it makes my code clearer. It can happen when code is already complicated and long.

The block allows you to localize the code, and refactoring it into a separate function will be trivial. You need not to check if all the variables are temporary, you just see the block, copy/paste it, add a function header, and then add function call at the place where the block was before. No thinking and no research is needed. Veni, vidi, vici.

> The fact that you need to explain what’s happening with comments is a smell.

It is an example for the article taken out of a context. You'd better comment it for the sake of your readers.

> I think blocks are useful when you are referencing a lot of local variables and also have fairly localized meaning within the method.

I do it each time I need a temporary variable. I hate variables that exist but are not used, they make it harder to read the code, you need to track temporaries through all the code to confirm that they are temporaries. So even if I have just two local variables (not "a lot of") and one of them is temporary, I'd probably localize the temporary one even further into its own block. What really matters is a code readability: if the function has just three lines, it doesn't matter, but it becomes really ugly if a lifetime of a variable overshoots its usefulness for 20 lines of a dense code.

The other thing is mutability/immutability: you can drop mutability when returning a value from a block. Mutability makes reasoning harder, so dropping it when you don't need it anymore is a noble deed. It can and will reduce the complexity of reading the code. You'll thank yourself many times later, when faced with necessity to reread your own code.

There is a code and there is the process of devising the code. You cannot understand the former without reverse engineering the latter. So, when you write code, the more of your intentions are encoded somehow in your code, the easier it will be to read your code. If you create temporary variables just to parse config with the final goal to get the parsed config in a variable, then you'd better encode it. You can add comments, like "we need to parse config and for that we need three temporary variables", or you can localize those three temporary variables in a block.

Much of the value of this block pattern is that it makes the scope of the intermediate variables clear, so that you have no doubt that you don’t need to keep them in mind outside that scope.

But it’s also about logical grouping of concepts. And that you can achieve with simple ad hoc indentation:

  fn foo(cfg_file: &str) -> anyhow::Result {
      // Load the configuration from the file.
          // Cached regular expression for stripping comments.
          static STRIP_COMMENTS: LazyLock = LazyLock::new(|| {
              RegexBuilder::new(r"//.*").multi_line(true).build().expect("regex build failed")
          });

          // Load the raw bytes of the file.
          let raw_data = fs::read(cfg_file)?;

          // Convert to a string to the regex can work on it.
          let data_string = String::from_utf8(&raw_data)?;

          // Strip out all comments.
          let stripped_data = STRIP_COMMENTS.replace(&config_string, "");

          // Parse as JSON.
          let config = serde_json::from_str(&stripped_data)?;

      // Do some work based on this data.
          send_http_request(&config.url1)?;
          send_http_request(&config.url2)?;
          send_http_request(&config.url3)?;

      Ok(())
  }

It might seem odd if you’re not used to it, but I’ve been finding it useful for grouping, especially in languages that aren’t expression-oriented. Tooling may be able to make it foldable, too.

I’ve been making a lightweight markup language for the last few years, and its structure (meaning things like heading levels, lists, &c.) has over time become almost entirely indentation-based. I find it really nice. (AsciiDoc is violently flat. reStructuredText is mostly indented but not with headings. Markdown is mostly flat with painfully bad and footgunny rules around indentation.)

—⁂—

A related issue. You frequently end up with multiple levels of indentation where you really only want one. A simple case I wrote yesterday in Svelte and was bothered by:

  $effect(() => {
      if (loaded) {
          … lots of code …
      }
  });

  $effect(() => { if (loaded) {
      … lots of code …
  } });

  effect(|| if loaded {
      … lots of code …
  });

  effect(|| {
      if loaded {
          // … lots of code …
      }
  });

I would like to see people experiment with indentation a bit more.

—⁂—

One related concept from Microsoft: regions. Cleanest in C♯, `#region …` / `#endregion` pragmas which can introduce code folding or outlining or whatever in IDEs.

  {
    const x = 5;
    x + 5
  }
  // => 10
  x
  // => undefined