symengine
Inconsistent Styles
I noticed that in many places, SymEngine uses and and or, which are the alternative operator representations of && and ||. In other places, the standard && and || were used.
Which one is best to use has been the subject of quite some discussion on Stack Overflow.
However, many people suggest sticking to the standard && and || pair.
Moreover, these alternative operator representations aren't even taught in most introductory C++ courses so it comes as a big surprise to newcomers. The Google Style Guide uses &&, as does the LLVM Style Guide.
Thanks for the suggestion.
Personally I really like the and, or and not operators since they are less easy to confuse with the & and | operators and the && as r-value reference. With the words of Bjarne Stroustrup (from the C++ programming language):
Some characters from the basic source character set, such as |, are not not convenient to type on some keyboards. Also, some programmers find it odd to use symbols, such as && and ~, for basic logical operations. Consequently, a set of alternative representations are provided as keywords:
I still agree though that it would be good to standardize this in our code base and the only reasonable standardization is to use the more common &&, || and ! versions. And if this is less surprising to newcomers I am all for it. Perhaps even the code checker could be configured to disallow the keyword forms.
Just to give an example code line that would need changing:
if (is_a_Number(*arg) and not down_cast<const Number &>(*arg).is_exact()) {
into
if (is_a_Number(*arg) && !down_cast<const Number &>(*arg).is_exact()) {
Any other opinions?
Personally I don't have any strong opinions, but I agree with @rikardn, if we decide on a preferred style, we need to automate the enforcement, preferably using clang-format since @isuruf has set up such a nice bot for this project. I had a quick look, but didn't see any such rules.
On that note, clang-format 15 will be able to insert braces (InsertBraces), which I seem to recall is another inconsistency in our code base.
@bjodah Do you mean to always
if (a) {
do_something();
}
in stead of:
if (a)
do_something();
? In that case I am for enforcing this.