VS Code sees the signature of EmployeeSearch() and knows that Employee is a DM.Employee, so you'll get code completion automatically here also.

I'm still not a big fan of #dim. It was useful for code completion in Studio. But it hasn't been necessary for code completion in VS Code for a while. Check this post from last year for more details. Perhaps code clarity is the only remaining reason to use it, to help developers who are used to declaring variables in other languages (like Python type hints).

My main reason for discouraging its use is that it makes it seem like it's necessary to declare variables in ObjectScript, which it isn't. There is no variable declaration in ObjectScript, as you can read at the top of the documentation that @Vachan C Rannore cited. He is not the first developer to write something like this: "#DIM declares the variable and it's Data Type at COMPILE TIME." #dim causes confusion for developers.

As @Evgeny Shvarov says, the compiler skips #dim. But as the examples prove (thanks @Vitaliy Serdtsev), the compiler doesn't skip #dim that includes variable assignment, which it helpfully changes into Set statements. More confusion...

The first example looks a little weird because it uses #dim but doesn't include "as datatype".

#dim a,b,c = ##class(Sample.Person).%New()

Why use #dim syntax that supposedly declares something, and then avoid declaring anything? Confusing. The compiler just changes it into this standard Set syntax. Just use the Set syntax in the first place.

set (a,b,c) = ##class(Sample.Person).%New()

For the second example, I admit that it's slightly useful to get 3 different objects with a single statement. I never knew about this. The compiler turns this #dim statement into 3 separate Set statements, so it does save some typing.

set a = ##class(Sample.Person).%New(), b = ##class(Sample.Person).%New(), c = ##class(Sample.Person).%New()

Some developers will like this "insider trick." But I think using an obscure non-command instead of just calling %New() 3 times for this one special case is not worth it. Just use Set statements.

By the way, what do you think this statement does? Note the %OpenId(20) at the end instead of %New(). 

#dim a,b,c As Sample.Person = ##class(Sample.Person).%OpenId(20)

Confusing. How about this statement?

#dim a,b,c As Sample.Company = ##class(Sample.Person).%New()​

Do you get 3 companies or 3 persons? Does it try to "cast" persons as companies? Do you get an error at compile time or run time? Would it work if Sample.Company extends Sample.Person? More confusion...

Nice post. I just want to point out that "handle them carefully" does not mean "check your indexes every day to make sure they're in sync with the database. It does not mean "make sure you run %BuildIndices() on a regular basis to make sure the indexes are in sync with the database." Applications, old or new, ensure that any updates to the data (insert, update, delete) are automatically reflected in the indexes.

"Handle them carefully" does mean, as Karthick points out:

• If you're running a query and you're not seeing data that you know is there, investigate whether the index is up to date. You can exclude the index like this: WHERE %NOINDEX Age = 26. If the missing records appear, you know that the index probably needs to be rebuilt. It would be good to investigate why the index got out of date, but that may be difficult. Which is why...
• ...rarely if ever manipulate the index globals directly, like this: "we accidentally deleted two entries from the index structure (not from the main table)."