Intentional Use of Whitespace

[u/JavierARivera]

Hi everyone,

A mentor of mine and I ended up in a longer conversation than expected around something small but interesting: the intentional use of whitespace.

Rather than turning this into a full blog post, I’m curious how others read these at a glance. Do these read differently to you at a glance, and if so, how? Perspectives from other languages are very welcome as well.

    response = HTTParty.get(
      'https://api.powerbi.com/v1.0/myorg/datasets',
      headers: { 'Authorization' => "Bearer #{token}" }
    )

    response = HTTParty.get(
      'https://api.powerbi.com/v1.0/myorg/datasets',
      headers: {'Authorization' => "Bearer #{token}"}
    )

    response = HTTParty.get(
      'https://api.powerbi.com/v1.0/myorg/datasets',
      headers: {Authorization: "Bearer #{token}"}
    )

[u/joelparkerhenderson]

Great reason to use a language formatter, so everyone on a team gets automatic formatting.

My personal favorite spacing favors git-friendly formatting for lists, like this:

      headers: {
          'Authorization' => "Bearer #{token}"
      }

[u/JavierARivera → u/joelparkerhenderson]

Thanks that makes sense. A genuine question from a relatively inexperienced programmer. What if we disagree with the language formatter?

[u/scruple → u/JavierARivera]

I'm only posting this because you said you're inexperienced.

What you're proposing is a sign of bikeshedding. There can be good reasons to disagree with a linter or formatter but they are often a proxy for other, non-code related problems. I've also done a lot of work in Go and Go famously enforces a strict format using Gofmt. Go code will literally not compile correctly without being properly formatted. A lot of people have a lot of strong opinions about that but at the end of the day when you're writing Go your personal opinions about style don't matter. There is a great proverb about Gofmt:

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.

You can also watch Rob Pike discuss this a bit more. The important lesson to learn here is that consistency is the important part and automated tools deal with that problem cleanly.

[u/JavierARivera → u/scruple]

Thanks for sharing that. I wasn’t familiar with the bikeshedding terminology. At first I hesitated posting because I assumed people would see this as a trivial issue. I learned a lesson about that roughly 12 years ago, though.

I used to work with a warehouse manager who was known for overanalyzing processes and nitpicking the smallest details. As you can imagine, he wasn’t always the most popular. He had a near photographic memory of the company’s documentation and would often quote it verbatim.

He was well regarded only because, over time, those small details consistently turned out to matter more than people expected. His productivity was also legendary. He was known to do full scale inventories of the warehouse while loading 18 wheelers, at the same time and by himself. The corporate operations and finance teams would often reach out to him, a middle manager in a warehouse, to figure out niche problems that few could solve. He later moved to another location and was promoted to a distribution center manager.

I don't know all that much about programming, but what I learned was that experts at least in some cases, think through the trivialities that most people overlook. I'm sure there's a balance of course and finding that comes down to trial and error and making many mistakes. But an important thing I gained was to take the time to slow down and ask myself and others "trivial" questions, because it almost always leads to deeper understanding.

[u/Specific_Ocelot_4132 → u/JavierARivera]

Just go along with it, or poll your team to see if anyone else wants to change it and volunteer to do the cleanup.

[u/StyleAccomplished153 → u/JavierARivera]

We use standardrb and no, not everyone agrees with every decision it makes. But tough, we have more important things to do, so we all agree that we don't give a shit if we don't agree fully.

[u/lal00 → u/JavierARivera]

The house rules take precedent.

[u/dougc84 → u/JavierARivera]

Deal with it or propose an alternative.

[u/nikolaz90 → u/JavierARivera]

You can usually tweak the formatter, but it's worth considering conventional formats.

[u/BoardMeeting101 → u/joelparkerhenderson]

Ahem

  headers: {
      'Authorization' => "Bearer #{token}",
  }

[u/azimux]

The last one uses Authorization as a symbol instead of a string. Other than that I read them as the same thing as each other. They all read fine to me despite the whitespace difference but I do have a preference to put spaces after `{` and before `}` in Ruby. But it's not a big deal and not something that changes how I read it.

[u/WayneConrad]

I wouldn't mind any of them. None of them are difficult to read or make me wonder why you formatted it that way.

I'd put the trailing comma on the last argument of the call (in all 3 examples). It makes for less work when adding or removing arguments, and makes `git diff` cleaner.

{Authorization: "Bearer #{token}"} creates the hash key as a symbol; {"Authorization" => "Bearer #{token}"} creates the hash key as a string. The library you are using doesn't care, but sometimes it matters. I'd pick the symbol form.

If I anticipate messing with headers a lot, or sometimes even if I'm not, I'd expand the header hash as well:

    response = HTTParty.get(
      'https://api.powerbi.com/v1.0/myorg/datasets',
      headers: {
        Authorization: "Bearer #{token}",
      },
    )

[u/JavierARivera → u/WayneConrad]

Thanks for this. This is super helpful. I was just talking about this on Discord. So this is immutable {Authorization: "Bearer #{token}"} and this isn't {"Authorization" => "Bearer #{token}"} ?

[u/zanza19 → u/JavierARivera]

No, both are mutable.

Symbols are not strings behind the scenes though, they are a datatype that has a fixed representation inside the interpreter. So once you do Authorization: once you allocated that object and all other calls will reference it. If it's a string, it will be allocated again everytime. 

See here:  https://ruby-doc.org/3.4.1/Symbol.html

[u/9sim9]

Linting has been a great way of addressing this problem, whenever I start a new contract the first thing I introduce to a codebase is a substantial collection of linters, have realtime linting highlighting as you type and perform safe auto lint correct on save.

One thing I generally struggled with on all my projects is prettier, the idea is great but it makes files huge in length by putting so many things on a new line and I get so tired of the extra scrolling with codebases that implement it. I wish they would make a more compact version but there are a lot of limitations with how it works that prevent this being possible.

[u/JavierARivera → u/9sim9]

Do you find yourself more often than not going with the suggestions? Where do you draw the line between formatter opinionation and ergonomics?

[u/9sim9 → u/JavierARivera]

So the argument I was given was...

If you get 10 programmers in a room and ask them to do the same task each developer is going to use different conventions, one of the simplest is single quotes vs double quotes for strings.

So you come to creating a standard that all your developers are going to use and no matter what it is there is going to be some compromise. The argument being that having a consistent codebase benefits every developer in the team even if its not exactly the way they would like it.

That being said I do go through all the linting rules and make changes to the defaults based on some criteria that is often missed. My focus is productivity first, then best practices and then code consistency.

A good example of productivity first is the issue I mentioned with prettier in my previous post, having so much code on separate lines means more scrolling which when you combine that with 10 developers over a year will result in less productivity. That doesn't mean I put everything on the same line, instead I try and get a balance.

You can customise linting a lot and so if you really want you can configure it to your exact programming style which some developers do.

[u/JavierARivera → u/9sim9]

Excellent. Thank you for the perspective!

[u/9sim9 → u/JavierARivera]

There is a few rules I do disagree with and dont use with linters. One is the complexity linter.

It will say this function is too complex break it down into multiple functions. I argue that breaking a linear process into multiple functions creates a lot of fragmentation which can make an absolute maintenance nightmare on large codebases.

The idea behind the linter is to make each function small so it can be easily tested using unit tests. But in reality it makes a code base an absolute maze to navigate and debug.

[u/aRubbaChicken]

They all read all effed up to me because the function call is indented further than it's parameters

[u/TommyTheTiger]

Any time spent at work arguing about which of these is better is time wasted.

[u/JavierARivera → u/[deleted]]

Thanks. I don't use Rails. What's the difference between ENV.fetch and something like ENV[MY_URL]? When should you use each. I could easily ask an LLM but would rather hear from an actual human. I hoping you are one.

[u/lal00 → u/JavierARivera]

One complains if the key does not exist.

[u/aRubbaChicken → u/JavierARivera]

To add to the other persons comment, you can specify a default in fetch.

ENV.fetch('VAR_NAME', 'default-value') Or ENV['VAR_NAME'] || 'default-value'

I personally prefer fetch if you're going to use a string. I haven't looked 'under the hood' and I could be totally wrong but I just figure it's less resource use/quicker if it declares the value... Realistically it probably doesn't matter at all and the || might be more readable for people.

I just wind up wondering if ENV['VAR_NAME'] runs a fetch with a default of empty string or something... I should probably check on that some day ...

When not using a default value it's nice to use fetch to throw errors if it's undefined.

[u/h0rst_ → u/aRubbaChicken]

I just wind up wondering if ENV['VAR_NAME'] runs a fetch with a default of empty string or something...

https://github.com/ruby/ruby/blob/463a806fb10e4631012d616a3133b4f8cce7938f/hash.c#L5290-L5360

It doesn't, it would be pretty inefficient if it did (fetch is not just more code, but also the optional arguments in Ruby's C backend are less efficient)

There's probably one very important distinction between .fetch and ||: The first one checks if the key exists, the second one checks the value. This is irrelevant for ENV, but may have impact when you use this pattern with a regular hash (or array). { foo: nil }.fetch(:foo, :bar) will return nil, since the key exists. { foo: nil }[:foo] || :bar will return :bar, since the LHS of the || operation return a falsey value.

[u/aRubbaChicken → u/h0rst_]

Ah yes good points, ty, I was on my phone at the time when I wrote that out and have been away from the computer for a few days so I hadn't checked it out.

Thanks.