If the worksheet you want to retrieve exists at compile-time in ThisWorkbook
(i.e. the workbook that contains the VBA code you're looking at), then the simplest and most consistently reliable way to refer to that Worksheet
object is to use its code name:
Debug.Print Sheet1.Range("A1").Value
You can set the code name to anything you need (as long as it's a valid VBA identifier), independently of its "tab name" (which the user can modify at any time), by changing the (Name)
property in the Properties toolwindow (F4):

The Name
property refers to the "tab name" that the user can change on a whim; the (Name)
property refers to the code name of the worksheet, and the user can't change it without accessing the Visual Basic Editor.
VBA uses this code name to automatically declare a global-scope Worksheet
object variable that your code gets to use anywhere to refer to that sheet, for free.
In other words, if the sheet exists in ThisWorkbook
at compile-time, there's never a need to declare a variable for it - the variable is already there!
If the worksheet is created at run-time (inside ThisWorkbook
or not), then you need to declare & assign a Worksheet
variable for it.
Use the Worksheets
property of a Workbook
object to retrieve it:
Dim wb As Workbook
Set wb = Application.Workbooks.Open(path)
Dim ws As Worksheet
Set ws = wb.Worksheets(nameOrIndex)
Important notes...
Both the name and index of a worksheet can easily be modified by the user (accidentally or not), unless workbook structure is protected. If workbook isn't protected, you simply cannot assume that the name or index alone will give you the specific worksheet you're after - it's always a good idea to validate the format of the sheet (e.g. verify that cell A1 contains some specific text, or that there's a table with a specific name, that contains some specific column headings).
Using the Sheets
collection contains Worksheet
objects, but can also contain Chart
instances, and a half-dozen more legacy sheet types that are not worksheets. Assigning a Worksheet
reference from whatever Sheets(nameOrIndex)
returns, risks throwing a type mismatch run-time error for that reason.
Not qualifying the Worksheets
collection is an implicit ActiveWorkbook reference - meaning the Worksheets
collection is pulling from whatever workbook is active at the moment the instruction is executing. Such implicit references make the code frail and bug-prone, especially if the user can navigate and interact with the Excel UI while code is running.
Unless you mean to activate a specific sheet, you never need to call ws.Activate
in order to do 99% of what you want to do with a worksheet. Just use your ws
variable instead.