Skip to content
This repository has been archived by the owner on Oct 26, 2021. It is now read-only.

KLC: Use prescriptive language with terms defined in RFC 2119 #289

Open
Ratfink opened this issue Jun 2, 2018 · 0 comments
Open

KLC: Use prescriptive language with terms defined in RFC 2119 #289

Ratfink opened this issue Jun 2, 2018 · 0 comments

Comments

@Ratfink
Copy link

Ratfink commented Jun 2, 2018

As I have previously mentioned (KiCad/kicad-library#1622 (comment), KiCad/kicad-library-utils#233 (comment)), I think it would be great to make KLC use the technical language defined in RFC 2119 (perhaps using a bold or italic font instead of all-caps). Careful use of must, should, and may, and saying where these terms are defined, would not only clarify existing rules, it would make it easier to know what conditions are supposed to be errors vs. warnings in the kicad-library-utils checking scripts.

This should go along with re-writing KLC to consistently use prescriptive language, rather than sometimes using descriptive language as it does now. Notable examples of this include many of the rule titles, including but not limited to these:

G1.2 - Each library is limited to 250 items → Each library should be limited to 250 items
G1.7 - Library files use Unix style line endings → Library files must use Unix style line endings
S3.1 - Origin is centered on the middle of the symbol → Symbol must be centered on the origin (In this one I think the symbol should come first, because the rule is about the symbol, not the origin.)
S5.1 - Symbols with a default footprint link to a valid footprint file → Symbols with a default footprint must link to a valid footprint file
F1.1 - Footprint libraries are categorized by function → Footprint libraries should be categorized by function
F9.1 - Footprint meta-data is filled in as appropriate → Footprint meta-data must be filled in as appropriate

This would be a big project that would require going over KLC rule-by-rule with a fine-toothed comb, so maybe it could be done on a separate branch with individual pull requests for each rule to keep things manageable.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants