DEV Community

loading...
Cover image for Code Smell 24 - Boolean Coercions

Code Smell 24 - Boolean Coercions

mcsee profile image Maxi Contieri Originally published at maximilianocontieri.com Updated on ・1 min read

Booleans should be just True and false

Problems

  • Hiding Errors

  • Accidental complexity coupled to one particular language.

  • Readability

  • Difficulty to hop among languages.

  • IFs

Solutions

  1. Be explicit.

  2. Work with booleans for boolean conditions. Not integers, not nulls, not strings, not lists. just booleans.

  3. Fail fast

Sample Code

Wrong

Right

Detection

This is a language feature. Some strict languages show warnings with this magic wizardry.

Tags

  • Coercions

  • Primitive

Conclusion

Some languages encourage doing some magic abbreviations and automatic castings. This is a source of errors and a Premature Optimization warning.

We should always be as explicit as possible.

Relations

More Info

Discussion (17)

pic
Editor guide
Collapse
yoursunny profile image
Junxiao Shi

Go doesn't allow conversions from and to boolean type altogether.

Meanwhile in C, it's normal to test an integer as boolean, but I'd rather write if (i == 0) although I know the compile will optimize the comparison away.

Collapse
mcsee profile image
Maxi Contieri Author

Exactly ! Let the compiler do it for you if it is safe.
Go is much stricter than C. I think Go lacks several important features like Exceptions or Full Closures. Once it catches up with older languages it would be an excellent option

Collapse
eljayadobe profile image
Eljay-Adobe

Shouldn't that be if (i != 0) ...?

Collapse
yoursunny profile image
Junxiao Shi

Depending on whether you want true or false. I usually test for error condition and return early.

Collapse
mcsee profile image
Maxi Contieri Author

what is 'i' ?

what real world entity does it represent ? the letter 'i' ? Why would you compare a letter with a number ?

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

Considering the example talks about C, i is probably a counter variable for a numeric loop.

Thread Thread
mcsee profile image
Maxi Contieri Author

i think we should name it 'counter' or 'index'
We are doing software, not math

Thread Thread
yoursunny profile image
Junxiao Shi

My real code uses the variable name res.
github.com/usnistgov/ndn-dpdk/blob...

int res = rte_hash_add_key_with_hash_data(pcct->tokenHt, &token, hash, entry);
if (likely(res == 0)) {
  break;
}
Enter fullscreen mode Exit fullscreen mode

That likely is not "premature optimization". This code is for a high speed router that processes millions of packets per second.

Thread Thread
mcsee profile image
Maxi Contieri Author

I don't know what 'res' stands for.

But if you performed a real benchmark on the code and found out it really needed to be optimized it does not classify as 'premature'.
I'm ok with that since in this very special case speed is more important than readability

Thread Thread
yoursunny profile image
Junxiao Shi

res means result. It is common in C code.

Thread Thread
mcsee profile image
Maxi Contieri Author • Edited

ok. that's why i don't like low level languages. They are more cryptic.
I try to specialize on higher level languages. Most code smells apply to them.

I suggest not to use 'res' 'i' ir 'result' as variable names since they have no business meaning.

more examples here:

maximilianocontieri.com/what-exact...

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

certain things like res and i are so common that I'd consider them expressive variable names, but there's not many. For res, I really like the pascal feature of assigning to the subroutines name, because presumably that's already a descriptive name for the result value.

re not liking low level languages, it seems to me like high- and low-level languages have completely different appeals (I happen to like both of them), so one might like one but not the other. Thinking in systems and poking at bits are as much different areas as back-end and front-end.

Thread Thread
mcsee profile image
Maxi Contieri Author

you are absolutely right. They are different tools for different purposes

Collapse
darkwiiplayer profile image
DarkWiiPlayer

I hate languages that treat "empty" values as falsey. It's dumb and leads to unexpected errors. An empty array is still an array, an empty string is still a string, zero is still a number. Neither of them has anything "false" about them and languages that treat them as such are just poorly designed (low-level languages like C being the exception, for obvious reasons)

Collapse
darkwiiplayer profile image
DarkWiiPlayer

I really prefer how this would work in ruby:

if vaccines.empty?
   puts "We have no vaccines yet. Keep researching"
else
   puts "Let's get vaccinated"
Enter fullscreen mode Exit fullscreen mode

It's closer to human thinking.

Collapse
mcsee profile image
Maxi Contieri Author

i agree.

empty is much better than strlen()=0

Collapse
alainvanhout profile image
Alain Van Hout

I'm a bit confused here. You say to not use coercion, but your 'right' example treats an array as a boolean.