Có vẻ như tôi đã gây ra một số giận dữ trong những năm qua vì lập trường gây tranh cãi của tôi rằng Option Explicit không hữu ích trong VBA. Tôi đã được nhắc nhở về điều này gần đây khi tôi thực hiện một phiên Skype tại Excel Weekend của Brazil. Tôi đã viết một cuốn sách về Excel VBA cho QUE. Cuốn sách đó đã được dịch sang tiếng Bồ Đào Nha cho thị trường Brazil. Vì vậy, rõ ràng là tôi đã dạy những người giỏi của Brasil về Excel VBA trong 15 năm. Bây giờ tôi đã 15 tuổi và khôn ngoan hơn, tôi sẽ thừa nhận rằng có thể có những lý do chính đáng để sử dụng Option Explicit.
Tại Notre Dame, tôi tham gia các khóa học kinh doanh với sự tập trung cao độ vào lập trình. Thông qua một loạt các tình huống kỳ lạ, tôi đã tham gia mọi khóa học lập trình có sẵn tại ND từ cả hai trường Kỹ thuật và Kinh doanh. Tôi đã học Fortran, Pascal, Assembler và COBOL. Tôi yêu lập trình. Các khóa học lập trình đó đã giải cứu điểm trung bình của tôi và giúp tôi không bị loại. Ngày trước, các giáo sư của chúng tôi nói với chúng tôi rằng chúng tôi phải lập kế hoạch chương trình của mình và vẽ sơ đồ trước khi bắt đầu viết mã. Tôi là một kẻ nổi loạn. Tôi sẽ viết chương trình trước và sau đó vẽ sơ đồ sau khi hoàn thành.
Tôi đã dành 18 tháng đầu tiên trong sự nghiệp của mình để viết các chương trình COBOL. Nhưng sau đó tôi chuyển sang ngành Tài chính và có mười năm làm việc trong lĩnh vực Tài chính Kế toán. Tôi chủ yếu làm công việc kế toán, nhưng khi tôi cần viết một số mã, tôi đủ biết để viết một số mã.
Tôi đã lập trình macro trong Lotus 1-2-3 và sau đó bắt đầu viết Macro VBA sau khi chúng tôi chuyển sang Excel vào năm 1995. Tôi vẫn còn phản đối ở điểm đó: việc khai báo các biến của tôi trước thời hạn dường như quá giống như vẽ một sơ đồ trước khi viết mã. Tôi không bao giờ là người có kế hoạch trước. Đi sâu vào. Bắt đầu viết mã. Nếu bạn cần một biến mới ở đâu đó trên đường đi, chỉ cần tạo biến.
Tôi là một kẻ nổi loạn, viết mã đầu tiên và vẽ sơ đồ sau đó Khai báo các biến, tôi lập luận, là dành cho các lập trình viên chính thức. Nếu bạn đang làm việc trong lĩnh vực Kế toán và chỉ đơn giản là gõ 20 dòng mã, không có lý do gì để khai báo các biến của bạn trước thời hạn.
Lập trường của tôi về điều đó đã đưa tôi vào một số tranh luận thân thiện với các chuyên gia Excel khác. Jordan Goldmeier. Bob Phillips. Cristiano Galvão.
Trước hết, tôi luôn khuyên bạn nên khai báo Biến đối tượng của bạn. Trong đoạn mã dưới đây, WSD được khai báo dưới dạng trang tính và được gán bằng lệnh Đặt. Nếu bạn khai báo biến đối tượng, bạn có thể duyệt qua tất cả các thuộc tính và phương thức bằng cách nhập biến theo sau là dấu chấm.
Bằng cách không sử dụng Option Explicit, bạn có nguy cơ mắc lỗi chính tả. Trong đoạn mã dưới đây, một biến có tên là FinalRow được tạo. Trong dòng tiếp theo, tôi có thể muốn lặp lại từ 2 đến FinalRow, nhưng tôi đã gõ nhầm biến là Fina1Row.
Nếu không có Tùy chọn rõ ràng, ai đó có thể không nhận ra lỗi đánh máy ở đó. Biến FinalRow có thể chứa 100. Nhưng mã bên trong vòng lặp sẽ không thực thi vì biến Fina1Row chưa bao giờ được khởi tạo và sẽ chứa số không.
Để ngăn chặn sự thất vọng khi gỡ lỗi mã với các lỗi đánh máy tiềm ẩn, bạn có thể mở Công cụ, Tùy chọn trong menu VBA. Chọn hộp Yêu cầu Khai báo Biến được hiển thị bên dưới.
Tất cả các mô-đun trong tương lai sẽ bắt đầu bằng một dòng cho biết Tùy chọn rõ ràng. Bạn sẽ phải thêm các dòng mới ở đầu macro xác định biến FinalRow và i. Excel sẽ không cho bạn biết về lỗi chính tả cho đến khi bạn thực sự cố gắng chạy macro. Sau đó, họ sẽ cảnh báo bạn rằng Biến Không được Xác định.
Vì vậy, nó là cuộc gọi của bạn. Nếu bạn không ngại lập kế hoạch trước và khai báo tất cả các biến của mình, bạn sẽ có mạng lưới an toàn VBA cho bạn biết nếu bạn nhập một biến không chính xác. Đối với tôi, tôi thích cảm giác hồi hộp khi gỡ lỗi mã từng dòng một và tự mình tìm ra những lỗi đánh máy của mình. Nhưng nếu bạn không cảm thấy muốn sống một cách nguy hiểm, hãy bật Tùy chọn rõ ràng.
Tôi không thực sự chắc chắn liệu hành động của mình có liên quan đến các Bước 5, 8 hoặc 9 trong số 12 bước hay không. Nhưng nếu ai đó đã dành thêm thời gian để gỡ lỗi mã của họ vì lỗi đánh máy, tôi xin lỗi vì đã gây ra cho bạn nỗi đau đó.
Thứ bảy hàng tuần, tôi sẽ thảo luận về một trong những thói quen xấu của tôi trong Excel và thảo luận tại sao có thể bạn nên làm những gì tôi nói thay vì làm những gì tôi làm.
Suy nghĩ của Excel trong ngày
Tôi đã hỏi những người bạn Excel Master của mình để được tư vấn về Excel. Hôm nay cần suy ngẫm:
"Không thay đổi các nhà phát triển bảng tính giữa thời điểm."
Jordan Goldmeier
