I missed the most important correct answer: you'll get fired. 😀
Luckily Shane does indicate in the explanation that using this type of table names is not a good idea.
A bit of additional background for those interested.
In the ANSI standard for SQL, the 'single quote' character is defined as the string delimiter, and the "double quote" is the delimiter for object names. Using [square brackets] is not supported at all.
In Access, the 'single quote' is used for VB-style comments (if I remember correctly), and the "double quote" delimits strings, so Microsoft had to come up with something else for object names - and the [square bracket] was born.
In SQL Server, Microsoft tried a halfhearted attempt at being compatible with both the ANSI standards (and hence the major competitors), and with Access (to facilitate upgrade from Access to SQL Server):
- [square brackets] are always seen as delimiters for object names (Access style - ANSI SQL would throw an error)
- 'single quotes' are always seen as string delimiters (ANSI style - Access would consider the rest of the line as a comment)
- And "double quotes" can be interpreted either as delimiters for strings (Access style), or as delimiters for object names (ANSI SQL style), depending on the setting of the SET QUOTED_IDENTIFIER option and/or the QUOTED_IDENTIFIER database setting. The ON setting, which is default, and also a requirement for a lot of features, implies that "double quotes" are interpreted ANSI style, as object name delimiter.
The effect of this is that, in theory, code ported from Access should work with SET QUOTED_IDENTIFIER OFF, and code ported from ANSI-compliant competitors should work with SET QUOTED_IDENTIFIER ON.
Another effect of this setting is that 'single quote' for strings and [brackets] for object names always work, and are "safe". But "double quotes" are less safe, because code that works can stop working when someone tampers with the setting. This is probably the reason why all Microsoft's documentation, and all Microsoft's code generating tools will always use [square brackets] - and that in turn has resulted in [square brackets] being the de facto standard for all code I ever see on SQL Server.
Which is a bummer if your boss ever decides to port the system to Oracle so that it can be sold to other companies. Now, apart from having to deal with all the "real" inconsistencies between the products, you will also have to replace all [object names] with "object names". And a simple search and replace won't work because [brackets] also have a special meaning in LIKE patterns (and that meaning really requires brackets, in all ANSI-compliant products).