Comments (11)
Yup, this has been on my mind for quite some time. I generally want to stay away from >2 _
s in the macro name (this couldn't be helped for {CHECK|REQUIRE}_BUFF_*
).
So, here's my workaround:
Whole-string Checks:
CHECK_STREQ --> CHECK_STREQ
CHECK_STRNEQ --> CHECK_STRNE
REQUIRE_STREQ --> REQUIRE_STREQ
REQUIRE_STRNEQ --> REQUIRE_STRNE
Substring Checks:
CHECK_STRNE --> CHECK_SUBSTREQ
CHECK_STRNNE --> CHECK_SUBSTRNE
REQUIRE_STRNE --> REQUIRE_SUBSTREQ
REQUIRE_STRNNE --> REQUIRE_SUBSTRNE
Adding the SUB
hopefully makes it more interpretable
from tau.
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.
However, following your proposed format, in order to have only one '_' in a macro, then also {CHECK|REQURE}BUF* should become {CHECK|REQURE}_BUF*. I think this will bring a reduced readability, especially if we wanted to add further check macros in the future. In fact, I see 3 important key words that should be clearly visible to the developer:
- the check/require statement
- the object (STR, SUBSTR, BUF, ...)
- the condition (EQ, NE, LT, LE, GT, GE, TRUE, FALSE, NULL, NOT_NULL)
Please note that in priciple even the conditions LT, LE, GT, GE could be applied to strings/substrings, in the future. Merging the object with the condition make the whole macro less intuitive for the developer and a bit harder to remember.
In my view, such macros could contain a maximum number of 2 '_' characters according to the following logic:
- 0 '_' chars, when neither the object nor the condition is specified in the name (like CHECK() or REQUIRE());
- 1 '_' char, where only the object is not specified in the name (i.e. the {CHECK|REQURE}_EQ );
- 2 and no more than 2 '_' chars where we have both the object and the condition, that for clarity are separated;
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.
from tau.
Thank you for your suggestions, @stefano-p. You're right, adding the _
s leads to greater readability, but not always.
The point of assertion macros is to do their job, providing just the right amount of clarity.
A STR*
compared to STR_*
is slightly less readable, yes, but it makes sense. I shy away from extreme verbosity (eg STR_EQ
) when STREQ
gets the point across. Now, this would not make sense for BUF_EQ
because this makes more sense that BUFEQ
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 _
chars.
from tau.
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.
But now I am considering the whole view of this framework. From this standpoint, uniformity is also important. So, in general you choose a pattern and then you want to stick to it without exceptions.
In this case the pattern is CHECK{object}{condition}, which basically applies to all macros with the exception to those related to strings. Are you really sure that this is what you want?
from tau.
Yes, the only break from uniformity is in the BUF_*
macros. Otherwise, the rest are in the format {CHECK|REQUIRE}_*
.
I think it's too early to decide on this at the moment. The goal with Tau is to provide clean and readable assertion macros. Uniformity is encouraged, but not the sole defining factor (of course, this works both ways since pure non-uniformity is a signal of chaos, not what we're trying to optimize for).
Hope this helps.
from tau.
@stefano-p, will you be working on a PR for this?
from tau.
@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.
In the meanwhile I'll keep reviewing other frameworks, to get the big picture.
from tau.
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 SUBSTR
, we can take a call on that later. For now, I think we'll go ahead as discussed.
from tau.
Okay but I am not sure that I can find the time this week, if it is urgent. Hopefully this weekend.
from tau.
Sure, no hurry
from tau.
Fixed in #9
from tau.
Related Issues (20)
- cmake's install() macro fails with _deps/tau-src/include/tau not found HOT 4
- Please fix tauPrintf macro HOT 1
- --no-summary option doesn't works HOT 1
- --list option must not run but only list the tests HOT 1
- defaults and changing them for compiler errors HOT 8
- question: how can I test for arithmetic overflow HOT 3
- base types: 128bit support and description of what arithmetic is checked or not checked (or how to check stuff)
- specify code formatting HOT 1
- Filtering by exact name doesn't work HOT 5
- CHECK with message doesn't work HOT 9
- Abi tests/Helper macros for char signedness HOT 2
- design questions on minimizing dependencies HOT 1
- docs: TEST blocks require that there is no return value HOT 3
- gcc 12.1.0 fails to compile the example
- Compiler warning: -Wunused-but-set-variable
- Documentation for fixture-based testing needed
- If we do tests in a loop, it seems we don't have an easy way to prompt which iteration failed HOT 4
- problem in tauClock under cygwin
- Support for Mocks + other features? HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tau.