Opinion: Avoid Unneces Abbrevs

Many database developers (and other developers) seem to regard the endless use of abbreviations as some badge of honor. Don’t be one of these people.

Avoid abbreviations almost all the time.

I’ve written before about my dislike for the EOMONTH T-SQL statement. Given the same version introduced names like DATETIMEOFFSETFROMPARTS, surely we didn’t have to save 3 characters and could have had ENDOFMONTH. (I heard it was named this way to match the Excel function but matching something from another language that was created a long time ago isn’t the right answer here).

I’d also note that I’d rather have seen it as END_OF_MONTH. It’s a real pity that T-SQL has names like DATETIMEFROMPARTS but also names like NODE_FROM_PARTS all introduced in recent years. Again, I think there’s a need for more cranky old dudes in the development team.

Now we can’t change the language directly, but we can make better decisions when using the language.

For example, when using the DATEADD function, we have two choices for parameters. One is a set of (sometimes fairly obscure) abbreviated values. The other is a set of actual English words.

Please choose to use words not abbreviations.

Don’t write this code like this:

DATEADD(d, 1, @StartDate)

DATEADD(dd, 1, @StartDate)

DATEADD(y, 1, @StartDate)  

DATEADD(ww, 12, @StartDate)

Are you confident about what each of those means? Instead write this:

DATEADD(day, 1, @StartDate)

DATEADD(day, 1, @StartDate)

DATEADD(dayofyear, 1, @StartDate)

DATEADD(week, 12, @StartDate)

The same applies to column names. Don’t write Mbr when you could have written Member.

2018-01-16