Better to use t vs t() for type specifications?

Isn’t the formatter (running mix format) converting t into t() automatically?

It’s really totally up to you, both are correct and don’t let anyone tell you otherwise But as @stefanluptak says, it you use the formatter it’s decided for you.

My Elixir code has been dynamic up to now, but I’ve been watching DDD videos and other sources that are convincing me to start using types in some places. I didn’t even know a formatter would do that.
I write my code in VS Code with ElixirLS installed. Will it be formatted automatically?

I think this is one of those ambiguous things that doesn’t have a definite answer (much to my chagrin… I hate having to make meaningless design decisions).

I follow the convention for functions as defined in some of the style guides I’ve come across (here’s one by the Credo folks, and here’s some implicit examples from another style guide), which is: When defining a zero-arity function (or type, in this case), I omit the brackets, and when calling the function (or referencing a type), I always include the brackets.

For example:

Define a type

@type t :: String.t()

Use the type in a spec

@spec hello_world :: t()
def hello_world, do: "Hello world!"

@spec say_your_age(integer()) :: t()
def say_your_age(age), do: "You are #{age} years old."

For me, this is the most consistent way to do things, while still matching the spirit of the style guides I’ve seen.

Personally, I dislike the omission of the brackets in zero-arity functions. It’s a function, just give it the damn brackets. But I think it’s a holdover from the early days, when brackets were not required at all.