-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor of macro names related to strings and substrings check, to avoid confusion #7
Comments
Yup, this has been on my mind for quite some time. I generally want to stay away from >2 So, here's my workaround: Whole-string Checks:CHECK_STREQ --> CHECK_STREQ Substring Checks:CHECK_STRNE --> CHECK_SUBSTREQ Adding the |
With your suggested workaround we have for sure solved the ambiguity around the strings and substrings check, which was the main goal of this ticket.
In my view, such macros could contain a maximum number of 2 '_' characters according to the following logic:
That been said, I hope you'll consider also this perspective, aiming to find a compact and intuitive format, which possibly could also be graceful and easy to remember. |
Thank you for your suggestions, @stefano-p. You're right, adding the A I'm aware that this results in slight non-uniformity in the codebase, but the point is to have the macros make the most sense without overdoing on the |
I think I got your point. If we just consider the CHECK_STROK macro itself, I agree with you that STROK sounds better than STR_OK. |
Yes, the only break from uniformity is in the Hope this helps. |
@stefano-p, will you be working on a PR for this? |
@jasmcaus , I was thinking that your point of view makes sense to me, but we did not find full agreement on the naming and you also stated that "it's to early to decide at this moment". Maybe a wiser decision will come later, possibly with feedback coming from other people. So I think that for the time being I can solve this on my side only, by adding a wrapper for the macros in question, without touching the original repo. |
Actually, I strongly feel that this change should be made now, opposed to later. Tau has very few users currently, so the scope of change will not have a significant impact. If later there arises a need to change away from |
Okay but I am not sure that I can find the time this week, if it is urgent. Hopefully this weekend. |
Sure, no hurry |
Fixed in #9 |
Hello @jasmcaus ,
I decided to contribute to this unit test framework because I am really going to use it in practice for all my projects. I found it here and I chose it among the others due to its simplicity and effectiveness.
So, I like it very much, but in my opinion there is one aspect that absolutely it is worth to improve. If we consider CHECK_EQ and CHECK_NE as the opposite statement, as well as CHECK_BUF_EQ and CHECK_BUF_NE, I would expect that for strings comparison CHECK_STREQ would be coupled with CHECK_STRNE. Unfortunately, CHECK_STRNE is already used to compare two substrings that are supposed to be equal. In other words, the pattern "_EQ/_NE" is broken.
As such, in order to avoid confusions and keep the whole structure intuitive, I would propose to rename the macros related to strings and substrings as indicated below:
Whole-string Checks:
CHECK_STREQ --> CHECK_STR_EQ
CHECK_STRNEQ --> CHECK_STR_NE
REQUIRE_STREQ --> REQUIRE_STR_EQ
REQUIRE_STRNEQ --> REQUIRE_STR_NE
Substring Checks:
CHECK_STRNE --> CHECK_STRN_EQ
CHECK_STRNNE --> CHECK_STRN_NE
REQUIRE_STRNE --> REQUIRE_STRN_EQ
REQUIRE_STRNNE --> REQUIRE_STRN_NE
As an alternative solution for the substring checks (but this has still to be evaluated) we could allow an optional third parameter in the string check macro. Something like this: CHECK_STR_EQ(actual, expected, n) is like calling CHECK_STRN_EQ(actual, expected, n)
Just to make this transition smooth I would also keep the old names as "deprecated" defines at the bottom of tau.h, so that they can be removed safely at some point in the future.
What do you think?
If you agree, I would be more than happy to take care of this in my repository and then submit a pull request.
Stefano
The text was updated successfully, but these errors were encountered: