Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Reorganize sample files used in tests.

Đang mở
  • Có gì không ổn?
#43 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
php
Lĩnh vực
documentation, testing

Hướng nghiên cứu

Bắt đầu với bố cục hiện có trong snifftests/files/ và đọc các phần README mô tả cách sử dụng các tệp mẫu. Kiểm kê các mẫu quy tắc hiện tại, sau đó xác định mẫu nào thuộc must/ hoặc must_not/ mà vẫn giữ nguyên các kỳ vọng của bài kiểm thử. Cập nhật README với lý do được nêu cho whitelist và blacklist, rồi chạy bộ kiểm thử hiện có để xác nhận rằng tất cả các mẫu vẫn được kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement help-wanted

The codesniffer is unique in that it's not really a binary "yes/no" detector. In fact, it works in a strange kind of 3-way state in most cases:

"This must be X" vs "This must not be X" vs "This must be x^" vs "This must not be x^" vs "I don't care really."

Or using an example, you can write a sniff that dictates the opening brace must not appear "on the same line," but that doesn't necessarily preclude it from being two lines down:

if (...) { // fail
  //...
}

//vs

if (...) // pass
{
  //...
}

//vs

if (...) // pass(?)

{
  //...
}

Writing a rule in a "blacklist" fashion like this allows you to prevent a single bad behavior while not specifying a single preferred behavior. The alternative is a whitelist style rule that says, "this one way is accepted, all others are errors". Depending on what you want to allow and how flexible you want your standard to be, one or the other (or both) will be most appropriate in each case, but this makes testing hard.

In fact this typically means that good test cases have two sides to them: a file (or files) that fail a specific sniff as example(s) of breaking a rule, and other file(s) that demonstrates "proper" or "all acceptable" behavior that passes all sniffs.

To aid in understanding and reinforcing this dynamic, I'm suggesting grouping the sample files we test the ruleset against into folders that make their purpose a little more explicit: snifftests/files/must/ and snifftests/files/must_not/. There's more information in the README about the intended purpose of this, but the basic idea is that whitelist tests for rules that enforce a single specific style go in must/ and blacklist tests that ban a single specific behavior go in must_not/.

In fact, the README could probably stand to be updated to include a little more of this "theory" explanation too.

Ngôn ngữ chính
PHP
Star
0
Fork
0
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của loadsys/loadsys_codesniffer

Tất cả issue của loadsys/loadsys_codesniffer

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.