In this instance using ... varchar without a length works as well, but we really shouldn't get into that bad habit.
Definitely a bad habit 🙂 ... the resulting data without a SIZE is 30 characters. Of course that is big enough for a date formatted to be 10 characters 🙂 ... but ...
SELECT CONVERT(varchar, @d, 104)
... if that data is then further-processed the assigned width will be 30 char rather than 10. That sort of thing leads to bugs downstream which are then very hard-to-find.
varchar used, without size, in a DECLARE statement has size = 1 - although maybe that is likely to cause trouble immediately! and thus come to light, whereas a default CAST / CONVERT size of 30 for Date, Int, etc. is "big enough" to go unnoticed most of the time (but not GUID)
I think the fault here is that SQL doesn't have a "STRICT" parameter which would make it possible to "disallow" such shortcuts which are hangovers from legacy decades ago.
Here's another that I hate and would like to have the option of a STRICT setting to disallow:
SELECT Col1 AS MyCol1,
Col2 AS MyOtherColName,
largely because of the risk of accidentally typing that, the risk of which increases with very long lines, or multiple line statements, we use this style of formatting such that typo-errors are far more visible to the programmer
SELECT Col1 AS MyCol1
, Col2 AS MyOtherColName
Actually our preference (again because of the risk of an "AS" being at the end of a long / multi-line statement) is
SELECT [MyCol1] = Col1
, [MyOtherColName] = Col2
but of course code formatting is up to the user, all the formats are valid, my own advice would be "be 100% consistent"