stdlib-js / stdlib-js/stdlib

[RFC]: Add lint support for enforcing header filename conventions

Đang mở
#13,658 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
JavaScript
Star
6k
Fork
1.3k
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
611

Mô tả

A package's primary header file and its include guard needs to match the package name, except for being in snakecase, rather than kebabcase.

We have this convention so that end users have a consistent rule for how to convert a package name to a header include path. If packages are allowed to deviate from that convention, end users would need to explicitly look up the include path for each package they wanted to use, which just creates unnecessary friction.

We should both (a) document and (b) create a lint rule for enforcing filenames and potentially support separate linting for enforcing include guards (although this may be tied to us getting clang linting up and running).

When linting filenames, we'd need to distinguish between the main include and additional includes which are intended to be private. For the latter, these are allowed to have any name (e.g., see ndarray/base/unary). What should be the case is that if a package has an include folder, there should always be a header file having a path matching the package name, with the file basename being the base package name converted to snakecase. I cannot think of an exception to this rule. And if we ever needed to make an exception, we could consider, at some point in the future, adding an associated config option to a package's package.json which allows disabling the lint rule.

---
*Created via `/stdlib todo` from [stdlib-js/stdlib#11830](https://github.com/stdlib-js/stdlib/pull/11830) by @kgryte.*

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu bằng cách kiểm tra siêu dữ liệu trong package.json và các thư mục include của package để xác định cách biểu diễn tên package, các header chính và các header riêng tư. Ghi lại quy ước đặt tên tệp snakecase, sau đó xác định phạm vi của quy tắc lint và mọi hành vi riêng biệt của include-guard; công việc được xem là hoàn tất khi quy ước đã được ghi lại và các vi phạm dự kiến được phát hiện mà không đánh dấu các include riêng tư.

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

Đánh giá

Công nghệ
javascript
Lĩnh vực
documentation, tooling
Loại issue
Tính năng
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
45/100

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.