Thảo luận về IF, AND, OR... trong lập trình VBA (1 người xem)

  • Thread starter Thread starter VetMini
  • Ngày gửi Ngày gửi
Liên hệ QC

Người dùng đang xem chủ đề này

VetMini

Ăn cùng góc phố
Tham gia
21/12/12
Bài viết
17,745
Được thích
24,589
Bạn mô tả kiểu võ lâm thì mình làm theo kiểu thiếu lâm tự nhé, còn thiếu xíu nữa là hoàn chỉnh bạn tự bổ sung nhé. Khi nào siêng thì rút gọn code lại tí

Đúng ra Sub này nên tách ra làm 2 sub. Nếu H7 <> "" thì chạy 1 Sub và ngược lại
PHP:
Sub loc()
Dim Data(), Res(), i, j, k
[A13:H5000].ClearContents
Data = Sheet1.Range(Sheet1.[AB9], Sheet1.[AB65536].End(3)).Resize(, 10).Value
ReDim Res(1 To UBound(Data), 1 To 8)
For i = 1 To UBound(Data)
   If Data(i, 1) >= [D5].Value Then
      If Data(i, 1) <= [D6].Value Then
         If [H7].Value = "" Then
            If Data(i, 9) = [H6].Value Or Data(i, 8) = [H6].Value Then
               k = k + 1
               Res(k, 1) = Data(i, 1)
               Res(k, 2) = Data(i, 2)
               Res(k, 3) = Data(i, 3)
               Res(k, 4) = Data(i, 5)
               Res(k, 5) = Data(i, 7)
               If Data(i, 8) = [H6].Value Then Res(k, 6) = Data(i, 9)
               If Data(i, 9) = [H6].Value Then Res(k, 6) = Data(i, 8)
               If Data(i, 8) = [H6].Value Then Res(k, 7) = Data(i, 10)
               If Data(i, 9) = [H6].Value Then Res(k, 8) = Data(i, 10)
            End If
         Else
            If Data(i, 6) = [H7].Value Then
                If Data(i, 9) = [H6].Value Or Data(i, 8) = [H6].Value Then
                  k = k + 1
                  Res(k, 1) = Data(i, 1)
                  Res(k, 2) = Data(i, 2)
                  Res(k, 3) = Data(i, 3)
                  Res(k, 4) = Data(i, 5)
                  Res(k, 5) = Data(i, 7)
                  If Data(i, 8) = [H6].Value Then Res(k, 6) = Data(i, 9)
                  If Data(i, 9) = [H6].Value Then Res(k, 6) = Data(i, 8)
                  If Data(i, 8) = [H6].Value Then Res(k, 7) = Data(i, 10)
                  If Data(i, 9) = [H6].Value Then Res(k, 8) = Data(i, 10)
               End If
            End If
         End If
      End If
   End If
Next
k = k + 1
Res(k, 7) = "=sum(R13C:R[-1]C)"
Res(k, 8) = "=sum(R13C:R[-1]C)"
[A13].Resize(k, 8) = Res
End Sub

Không cần phải vậy. Các IF's trong bài này lồng trơn vào nhau - tức là không có lệnh khác. Như vậy ta có thể dùng AND. Phần code trong ELSE cũng in hệt như IF, nên có thể dùng OR

PHP:
   If Data(i, 1) >= [D5].Value AND Data(i, 1) <= [D6].Value _ ' trong giới hạn ngày '
         AND ([H7].Value = "" OR Data(i, 6) = [H7].Value) _ ' đúng mã KH '
            AND (Data(i, 9) = [H6].Value Or Data(i, 8) = [H6].Value) Then ' dúng mã tài khoản đối chiếu '
               k = k + 1
               Res(k, 1) = Data(i, 1)
               Res(k, 2) = Data(i, 2)
               Res(k, 3) = Data(i, 3)
               Res(k, 4) = Data(i, 5)
               Res(k, 5) = Data(i, 7)
               ' If Data(i, 8) = [H6].Value Then Res(k, 6) = Data(i, 9) '
               ' If Data(i, 9) = [H6].Value Then Res(k, 6) = Data(i, 8) '
               ' If Data(i, 8) = [H6].Value Then Res(k, 7) = Data(i, 10) '
               ' If Data(i, 9) = [H6].Value Then Res(k, 8) = Data(i, 10) '
               ' điều kiện đã thử rồi, [H6].Value bắt buộc phải = Data(i, 8 hoặc 9) '
               Res(k, 6) = Data(i, Iif(Data(i, 8) = [H6].Value, 9, 8))
               Res(k, Iif(Data(i, 8) = [H6].Value, 7, 8)) = Data(i, 10)
   End If
 
Lần chỉnh sửa cuối:
Xét trong trường hợp bạn nói, thì sự nguy hiểm đến từ câu "On Error Resume Next", chứ không phải từ chỗ If nhóm hay nhóm If.
Do đó, bản thân tôi cũng ít khi dùng câu này. Không dùng, và test thật kỹ để sửa lỗi, hoặc bẫy lỗi, chứ không bỏ qua lỗi. Trừ khi biết chắc rằng lỗi có thể bỏ qua.

Còn đối với người mới học tại GPE đây, (bài viết tại GPE thì thành viên GPE đọc nhiều nhất), thực sự mà nói thì đa số không qua trường lớp bài bản, kể cả tôi.

Vậy nếu tôi đi trước, tôi truyền lại 1 số kính nghiệm, truyền lại 1 số lỗi tôi đã gặp, thì tốt hơn là để họ trông mong vào "bản năng hướng thiện". Ít nhất, họ có thể rút ngắn thời gian học được vài giờ. Hơn nữa, học online thì những vấn đề căn bản như "chỉ dùng IIf cho tham số literal" có mấy ai nói cho mà biết, nên họ sẽ khó mà đạt mức "thấy nguy hiểm tự động tránh"

Còn vấn đề nguy hiểm của Goto, cho đến nay tôi chưa gặp phải, (vì bản thân tôi cũng ít dùng), nhân dịp này tôi cũng muốn lắng nghe thêm, bạn vui lòng viết tiếp cặn kẽ hộ.

Em xin bổ sung thêm vấn đề "On Error Resume Next"

1) Thời gian gần đây, em thường bẫy lỗi rất kỹ nên ít bao giờ thấy code của em dùng câu đó.

2) Em dùng nó trong trường hợp "bất khả kháng" như sau:

Nếu ta dùng hàm CDate, CLng, hay cDbl chẳng hạn, nếu nó quét qua dữ liệu là số thì cũng chẳng sao, nếu dữ liệu nó trộn giữa số và chuỗi thì bị "chửi rủa" lên liền!

Vậy thì phải xử lý!

Nếu đơn giản chỉ "On Error Resume Next" thì sẽ lờ qua lỗi, thế thì dữ liệu của "hàng" đó bị bỏ qua, còn nếu không dùng câu đó thì bị lỗi, phải làm sao?

Lấy lỗi "trị lỗi", Chẳng hạn:

On Error Resume Next
MyNum = cDbl(giatri)
If Err.Number = 0 then
MsgBox "Dang So"
Else
Err.Clear
MsgBox "Dang Chuoi"
End If


Nếu không dùng câu "On Error Resume Next" thì làm sao thủ tục chạy tới được thằng Else của If phải không?
 
Lần chỉnh sửa cuối:
Upvote 0
Hi hi, đừng chọc quê mình nha, test thời gian chớ gì nữa, nhưng phải nhân dữ liệu lên thật nhiều và thêm code "đo" thời gian vào, cái đó ở đây ai cũng biết mà!
Với dữ liệu trong file anh, em "nhân" lên 30,000 dòng, test thời gian gần như bằng nhau giữa 2 code
Cũng đúng, vì dữ liệu của anh nó quá đơn giản
 
Upvote 0
@Hoàng Trọng Nghĩa:


Lý do chính tôi đưa ra đoạn code trên là vì code nguyên thuỷ có sự lặp lại hai đoạn code in hệt nhau. Tôi chỉ đề nghị gộp lại thành một đoạn cho dễ nhìn dễ sửa. Những cái còn lại tuỳ thuộc vào trường phái sở thích riêng từng ngưòi.

Với bạn thì có thể trình độ cao hơn mình và nhiều người khác, nhưng thật sự khi tôi đã test thì thấy được rằng:

Trong vòng lặp, cụ thể là For ... Next đi, nếu tôi "ép" dữ liệu chỉ trong 1 vòng lặp thì điều gì sẽ xãy ra? Mỗi 1 vòng lặp nó tính n biểu thức, trong đó có những biểu thức loại trừ, nó cứ lặp đi, lặp lại cho đến hết.

Vậy tại sao ta không loại trừ trước rồi mới dùng vòng lặp sau? Có thể nhìn vào code ta thấy dùng nhiều vòng lặp, nhưng thực tế, sau khi loại trừ, thì thực sự code chạy có 1 vòng lặp thôi, còn ngược lại, với 1 vòng lặp, nhưng mỗi vòng-lặp lại lặp-lại cái loại trừ thì có phải tính toán sẽ bị chậm hơn không?

Chính vì thế, tôi chấp nhận code dài thườn thượt, nhiều vòng lặp trong mỗi biểu thức loại trừ (nhưng thực tế chỉ có chạy 1 vòng lặp khi điều kiện True), hơn là 1 vòng lặp với nhiều biểu thức loại trừ trong đó.

Đó chỉ là kinh nghiệm của tôi chứ không có tính tranh luận gì hết bạn nhé.
 
Lần chỉnh sửa cuối:
Upvote 0
Với dữ liệu trong file anh, em "nhân" lên 30,000 dòng, test thời gian gần như bằng nhau giữa 2 code
Cũng đúng, vì dữ liệu của anh nó quá đơn giản

Càng đơn giản thì sự so sánh càng chính xác, vì trong khi code chạy thì công việc chính chủ yếu là kiểm tra True và False chớ không xử lý gì khác.
 
Upvote 0
Càng đơn giản thì sự so sánh càng chính xác, vì trong khi code chạy thì công việc chính chủ yếu là kiểm tra True và False chớ không xử lý gì khác.

Chưa chắc đâu Anh, ở đây so sánh thì so sánh đồng bộ, dữ liệu đơn giản với cấu trúc đơn giản, dữ liệu phức tạp với cấu trúc phức tạp.

Mà thường người ta tính cái phức tạp, dữ liệu rất lớn để tính thời gian nhanh chậm, chứ còn đơn giản đôi khi cả 2 cái đều cho thời gian "tự làm tròn" = 0 hết cho các thời gian quá nhỏ thì làm sao biết được cao thấp chứ Anh.
 
Upvote 0
Càng đơn giản thì sự so sánh càng chính xác, vì trong khi code chạy thì công việc chính chủ yếu là kiểm tra True và False chớ không xử lý gì khác.

Nhưng trong thực tế có khi không đơn giản vậy
IF A AND B nhưng A B là kết quả của 1 quá trình tính toán phức tạp, lúc ấy so sánh mới thấy sự khác biệt
(thực tế chẳng mấy khi ta có A và B = TRUE hoặc FALSE ngay từ đầu)
 
Upvote 0
Em xin bổ sung thêm vấn đề "On Error Resume Next"

1) Thời gian gần đây, em thường bẫy lỗi rất kỹ nên ít bao giờ thấy code của em dùng câu đó.

2) Em dùng nó trong trường hợp "bất khả kháng" như sau:

Nếu ta dùng hàm CDate, CLng, hay cDbl chẳng hạn, nếu nó quét qua dữ liệu là số thì cũng chẳng sao, nếu dữ liệu nó trộn giữa số và chuỗi thì bị "chửi rủa" lên liền!

Vậy thì phải xử lý!

Nếu đơn giản chỉ "On Error Resume Next" thì sẽ lờ qua lỗi, thế thì dữ liệu của "hàng" đó bị bỏ qua, còn nếu không dùng câu đó thì bị lỗi, phải làm sao?

Lấy lỗi "trị lỗi", Chẳng hạn:

On Error Resume Next
MyNum = cDbl(giatri)
If Err.Number = 0 then
MsgBox "Dang So"
Else
Err.Clear
MsgBox "Dang Chuoi"
End If


Nếu không dùng câu "On Error Resume Next" thì làm sao thủ tục chạy tới được thằng Else của If phải không?

Có lẽ bạn tự làm khó mình rồi, chạy thử code sau:
Mã:
Sub test()
Dim mynum
mynum = 123
MsgBox VarType(mynum)
    If VarType(mynum) <> 8 Then
        mynum = CDbl(mynum)
        MsgBox VarType(mynum)
    End If
End Sub

---------------------------------------------------
BS
Mã:
Sub test2()
Dim mynum
mynum = "a"
MsgBox VarType(mynum)
    If VarType(mynum) <> 8 Then
        mynum = CDbl(mynum)
        MsgBox VarType(mynum)
    Else
        MsgBox "mynum la chuoi"
    End If
End Sub
 
Lần chỉnh sửa cuối:
Upvote 0
Có lẽ bạn tự làm khó mình rồi, chạy thử code sau:

Anh lại tiểu tiết rồi! Với bài đó tôi đang nói đến chuyện KHI NÀO THÌ DÙNG "On Error Resume Next"đưa ra 1 ví dụ cụ thể trong hàng tỉ vụ bẫy lỗi như vậy. Chứ bẫy lỗi thì có quá nhiều cách, tùy người dùng cách nào mà thôi.

Ví dụ tôi đặt giá trị NGÀY mynum = "1/1/2013" hoặc tại ô A1, vì lý do nào đó người ta đặt dấu nháy (') trước ngày chẳng hạn '1/1/2013 thì VarType nó hiện lên giá trị của số nào? 7 hay 8 vậy?

Dữ liệu trên Web hay xuất từ 1 phần mềm nào đó, thì dạng ngày tháng năm thường có ký tự Chr(160) trước ngày tháng năm (cái này thường xuyên xử lý trên diễn đàn), nhưng với ?CDATE([A1]) thử trong Immediate, với A1 =CHAR(160) & "1/2/2013 3:5" thì nó vẫn cho ra kết quả là 01/02/2013 03:05:00 đấy nhé! Nhưng với VarType nó lại cho giá trị là 8 (dạng string) chứ không phải là 7 (dạng date), cho nên cái giá trị thật sự để so sánh lại bị bỏ qua.

Bởi nguồn dữ liệu đôi khi copy từ file này qua file khác, xuất từ phần mềm khác, tải từ trên mạng xuống v.v... có thể có những định dạng hỗn hợp, nên chúng ta phải lường trước nó thuộc lỗi hay không lỗi để biết mà xử lý. Còn VarType, kiểu nào cũng cho giá trị, và những giá trị đó chưa chắc đúng trường hợp cụ thể nào.
 
Lần chỉnh sửa cuối:
Upvote 0
"On Error Resume Next"

Tôi chẳng nói nên hay không nên dùng. Chỉ thấy trong một bài nọ lợi dụng đặc tính bẫy lỗi code nhét item vào dictionary cho nên tôi ngỡ cái này được mọi người chấp nhận.

(Chỉ nhớ mang máng bài ở góc VBA mà quên mất bài nào, cho nên không đưa đường dẫn được, xin lỗi)

Vả lại tôi cũng chẳng phê bình code dài. Cái tôi chỉ trích là một đoạn code lặp lại 2 lần. Cái nào tôi chỉ trích tôi nói thẳng là chỉ trích. Từ hôi biết đọc code đến giờ tôi chưa hề thấy ai biện luận lặp lại code để bảo đảm tốc độ cả. (nhưng tôi khong phải là chuyên viên, trên đời còn rất nhiều việc hay mà tôi chưa hề thấy)
 
Upvote 0
"On Error Resume Next"

Tôi chẳng nói nên hay không nên dùng. Chỉ thấy trong một bài nọ lợi dụng đặc tính bẫy lỗi code nhét item vào dictionary cho nên tôi ngỡ cái này được mọi người chấp nhận.

(Chỉ nhớ mang máng bài ở góc VBA mà quên mất bài nào, cho nên không đưa đường dẫn được, xin lỗi)

Vả lại tôi cũng chẳng phê bình code dài. Cái tôi chỉ trích là một đoạn code lặp lại 2 lần. Cái nào tôi chỉ trích tôi nói thẳng là chỉ trích. Từ hôi biết đọc code đến giờ tôi chưa hề thấy ai biện luận lặp lại code để bảo đảm tốc độ cả. (nhưng tôi khong phải là chuyên viên, trên đời còn rất nhiều việc hay mà tôi chưa hề thấy)

Tôi vẫn đang thắc mắc, tại sao không dùng Goto vậy bạn?

Theo tôi hiểu nôm na, Goto thì phải đi với một Label trong code, để giảm đi số lần lặp đi lặp lại một thủ tục khi gặp trường hợp False thì người ta Goto đến nhãn đó. Thế thì tại sao lại không dùng với các lập trình viên chuyên nghiệp?

Và xin được chỉ giáo với câu nói này:

Hàm IIF chẳng có gì phải ngại nếu dùng với literals. Bình thường thì người ta chỉ tránh dùng nó khi gọi functions:
 
Lần chỉnh sửa cuối:
Upvote 0
Lý do chính khiến Goto nên tránh (lưu ý: chỉ là 'nên' chứ không 'bắt buộc'):

Khi có lệnh goto thì các lệnh trước cái tiêu đích (label) không được bảo đảm. Ví dụ cổ điển:

code ...

goto nhảy_vài_dòng

code ...

x = 0 ' đọc code đến đây mình đinh ninh x sẽ là 0 cho đến khi được gán trị khác

nhảy_vài_dòng:

---> x ở đây chưa hẳn là 0

Kết luận: nếu mình kiểm soát được ở đâu nhảy tới label thì dễ, nhưng sau vài lần sửa đổi code tùm lum, đến chừng phải mò thì cực lắm. Mỗi lần nhìn thấy cái label là bắt buộc phải cẩn thận trị của biến.
 
Upvote 0
Lý do chính khiến Goto nên tránh (lưu ý: chỉ là 'nên' chứ không 'bắt buộc'):

Khi có lệnh goto thì các lệnh trước cái tiêu đích (label) không được bảo đảm. Ví dụ cổ điển:

code ...

goto nhảy_vài_dòng

code ...

x = 0 ' đọc code đến đây mình đinh ninh x sẽ là 0 cho đến khi được gán trị khác

nhảy_vài_dòng:

---> x ở đây chưa hẳn là 0

Kết luận: nếu mình kiểm soát được ở đâu nhảy tới label thì dễ, nhưng sau vài lần sửa đổi code tùm lum, đến chừng phải mò thì cực lắm. Mỗi lần nhìn thấy cái label là bắt buộc phải cẩn thận trị của biến.

Nói chung, ý bạn muốn nói là ngại khi kiểm tra và chỉnh sửa. Thôi thì là quan điểm của mỗi người.

==================================================

Còn vấn đề này thì sao hả bạn? Mình rất muốn biết ý đó của bạn.

Hàm IIF chẳng có gì phải ngại nếu dùng với literals. Bình thường thì người ta chỉ tránh dùng nó khi gọi functions:
 
Lần chỉnh sửa cuối:
Upvote 0
1. Goto "phá vỡ" trật tự, thứ tự của code, code trở nên rối rắm, khó hiểu, khó theo dõi, khó kiểm soát, khó tìm lỗi hơn.
2. Khi dùng goto thì cơ hội phạm lỗi sẽ lớn hơn. Điều này dễ hiểu vì code với goto rối rắm hơn nên ta dễ sơ ý, dễ không nhận thấy những vấn đề quan trọng.
3. Phân tích code có nhiều goto khó hơn nhiều do code rối rắm hơn.

Nói chung, ý bạn muốn nói là ngại khi kiểm tra và chỉnh sửa. Thôi thì là quan điểm của mỗi người.

Không hẳn như vậy. Thậm chí bạn viết cho bản thân mình mà code ngắn, dùng 1 goto thì cũng chả sao. Nhưng bạn viết một code dài hoặc có nhiều goto thì 1 năm sau quay lại tôi nghĩ rằng bạn sẽ "lạc" trong chính code của mình, và mất nhiều thời gian hơn để hiểu so với code không có goto. Còn nếu bạn làm việc trong một nhóm với 1 project lớn thì sao? Code của bạn khó hiểu thì bạn cam chịu nhưng nếu bạn đưa cái code ấy cho đồng nghiệp thì ... tôi thương xót đồng nghiệp ấy. Và code của bạn nó "khuấy động" sự hài hòa có trong project chung. Và khi cần chỉnh sửa bổ sung code thì rất khó và dễ phạm lỗi.
Không phải cấm dùng goto. Nếu 1 goto trong th đơn giản thì hoàn toàn có thể chấp nhận. Nhưng nếu có thể viết khác đi mà không dùng goto thì nên viết khác đi. Mà thường là 99% các trường hợp có thể viết khác đi mà không dùng goto.
Khi bạn đánh giá goto thì bạn làm y hệt như khi đánh giá mọi việc khác trong cuộc sống. Có nên làm cái này không? Lợi là thế này, hại là thế này. Được bằng này, mất bằng này. Rồi "hạch toán" thôi. Goto lợi ít mà hại nhiều.
Nếu bạn hỏi 100 người lập trình chuyên nghiệp, hoặc đọc 100 trang web nói về goto mà 80% nói là goto "nên tránh - nên dùng" khi có thể thì lúc đó không nên nói: "Thôi thì là quan điểm của mỗi người". Bởi vì phải có nguyên nhân gì đó nên người ta mới khuyên không nên dùng hoặc nên dùng.
 
Upvote 0
1. Goto "phá vỡ" trật tự, thứ tự của code, code trở nên rối rắm, khó hiểu, khó theo dõi, khó kiểm soát, khó tìm lỗi hơn.
2. Khi dùng goto thì cơ hội phạm lỗi sẽ lớn hơn. Điều này dễ hiểu vì code với goto rối rắm hơn nên ta dễ sơ ý, dễ không nhận thấy những vấn đề quan trọng.
3. Phân tích code có nhiều goto khó hơn nhiều do code rối rắm hơn.



Không hẳn như vậy. Thậm chí bạn viết cho bản thân mình mà code ngắn, dùng 1 goto thì cũng chả sao. Nhưng bạn viết một code dài hoặc có nhiều goto thì 1 năm sau quay lại tôi nghĩ rằng bạn sẽ "lạc" trong chính code của mình, và mất nhiều thời gian hơn để hiểu so với code không có goto. Còn nếu bạn làm việc trong một nhóm với 1 project lớn thì sao? Code của bạn khó hiểu thì bạn cam chịu nhưng nếu bạn đưa cái code ấy cho đồng nghiệp thì ... tôi thương xót đồng nghiệp ấy. Và code của bạn nó "khuấy động" sự hài hòa có trong project chung. Và khi cần chỉnh sửa bổ sung code thì rất khó và dễ phạm lỗi.
Không phải cấm dùng goto. Nếu 1 goto trong th đơn giản thì hoàn toàn có thể chấp nhận. Nhưng nếu có thể viết khác đi mà không dùng goto thì nên viết khác đi. Mà thường là 99% các trường hợp có thể viết khác đi mà không dùng goto.
Khi bạn đánh giá goto thì bạn làm y hệt như khi đánh giá mọi việc khác trong cuộc sống. Có nên làm cái này không? Lợi là thế này, hại là thế này. Được bằng này, mất bằng này. Rồi "hạch toán" thôi. Goto lợi ít mà hại nhiều.
Nếu bạn hỏi 100 người lập trình chuyên nghiệp, hoặc đọc 100 trang web nói về goto mà 80% nói là goto "nên tránh - nên dùng" khi có thể thì lúc đó không nên nói: "Thôi thì là quan điểm của mỗi người". Bởi vì phải có nguyên nhân gì đó nên người ta mới khuyên không nên dùng hoặc nên dùng.

Vâng em hiểu ý của Thầy, tuy nhiên viết code trong Excel thường là những code ngắn chừng 200 dòng là thấy giải quyết được các vấn đề. Người ta cũng khuyên, nếu code dài quá thì cắt ra từng thủ tục nhỏ, nếu đúng điều kiện thì gọi thủ tục (sub) đó (như em đã làm với hàm NewAutoFilter), thế thì ai mà viết code dài có lẽ cũng nên học cách "chia để trị" phải không Thầy?
 
Upvote 0
Vâng em hiểu ý của Thầy, tuy nhiên viết code trong Excel thường là những code ngắn chừng 200 dòng là thấy giải quyết được các vấn đề.

Thì đây là đang bàn về lập trình nói chung - goto trong các ngôn ngữ lập trình

Người ta cũng khuyên, nếu code dài quá thì cắt ra từng thủ tục nhỏ, nếu đúng điều kiện thì gọi thủ tục (sub) đó (như em đã làm với hàm NewAutoFilter), thế thì ai mà viết code dài có lẽ cũng nên học cách "chia để trị" phải không Thầy?

Không hẳn cứ dài là cắt ngắn thành thủ tục. Nhưng nếu có một loạt dòng code liên tiếp tạo thành một cụm lôgic thì có thể tách ra và gọi hàm, code sẽ dễ hiểu hơn. Hoặc khi một đoạn code lặp lại nhiều lần chỉ khác nhau về giá trị của một số biến trong mỗi lần lặp thì nên tách ra, code sẽ gọn và dễ đọc, dễ hiểu hơn.
Cũng tùy trường hợp. Nhiều khi không có lý do gì để dùng hàm nhưng có thể viết khác đi dùng các cấu trúc khác, vd. vòng lặp, thì code gọn hơn và dễ hiểu hơn.
 
Upvote 0
Vâng em hiểu ý của Thầy, tuy nhiên viết code trong Excel thường là những code ngắn chừng 200 dòng là thấy giải quyết được các vấn đề. Người ta cũng khuyên, nếu code dài quá thì cắt ra từng thủ tục nhỏ, nếu đúng điều kiện thì gọi thủ tục (sub) đó (như em đã làm với hàm NewAutoFilter), thế thì ai mà viết code dài có lẽ cũng nên học cách "chia để trị" phải không Thầy?
Nhờ các anh chị giúp em đoạn code vba change trong sheet1 công thức này với:
=IF(OR(AND(H8=66121,I8=111,M8<>"PLP"),AND(H8=334,I8=111,M8<>"PLP"),AND(M8="PLP",X8=1),AND(X8=1,H8<>111)),1,IF(OR(AND(H8=66122,I8=111,M8<>"PLP"),AND(M8="PLP",X8=1),AND(X8=2,H8<>111)),2,0))
 
Upvote 0
Nhờ các anh chị giúp em đoạn code vba change trong sheet1 công thức này với:
=IF(OR(AND(H8=66121,I8=111,M8<>"PLP"),AND(H8=334,I8=111,M8<>"PLP"),AND(M8="PLP",X8=1),AND(X8=1,H8<>111)),1,IF(OR(AND(H8=66122,I8=111,M8<>"PLP"),AND(M8="PLP",X8=1),AND(X8=2,H8<>111)),2,0))

Tôi chẳng hiểu bạn làm gì với công thức trong sheet này. Muốn gì thì bạn phải gửi cái file lên, đồng thời bạn cho một kết quả mong muốn là gì, chứ nhìn vậy chả ai giúp bạn được trọn vẹn.
 
Upvote 0
Tôi chẳng hiểu bạn làm gì với công thức trong sheet này. Muốn gì thì bạn phải gửi cái file lên, đồng thời bạn cho một kết quả mong muốn là gì, chứ nhìn vậy chả ai giúp bạn được trọn vẹn.

Em gửi file lên đây nhờ các anh chị xem giúp em viết code vba cho cột E tương ứng các giá trị với các cột kia.
 

File đính kèm

Upvote 0
Em gửi file lên đây nhờ các anh chị xem giúp em viết code vba cho cột E tương ứng các giá trị với các cột kia.

Giúp em code cho công thức Cell với file ở trên. cảm ơn các anh chị, em đã sửa lại file cần hỏi, nhờ các anh chị giúp.
 

File đính kèm

Lần chỉnh sửa cuối:
Upvote 0
Web KT

Bài viết mới nhất

Back
Top Bottom