Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAvoid using ambiguous terminology in str.h/str.c #159
Conversation
This and the following commit change the names of functions, as well as their documentation, to use unambiguous terms "bytes" and "code points" instead of ambiguous terms "size", "length", and "characters".
|
@jermar, @jxsvoboda Any comments? |
|
Hm, I don't feel knowledgeable enough, so whatever you and @jxsvoboda deem proper. |
|
I understand where you are coming from, but you will notice the cunning correspondence between the 'l' prefix and the 'length' suffix (although not for n vs size which gets lost with your change. Also _code_points is wordier than _length. Overall I am not convinced this change is for the better. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Instead of ambiguous terms "size", "length", and "characters", use unambiguous terms "bytes" and "code points", including in function names.
Function name changes:
(w)str_(ln)size->(w)str_(ln)bytes(w)str_(n)length->(w)str_(n)code_pointsThe purpose of this change is to avoid confusing the purpose of those functions, especially given the conflicting terminology of standard
strlen, and the nonexistence of the term "character" in Unicode (there we have code units, code points, and grapheme clusters, only the last of which actually being what's colloquially understood as a character).