Learn Coding Skeptically

That “Senior” developer, might not know what they are talking about.

Photo by Michelle Tresemer on Unsplash

Medium is a great resource for building or honing your coding skills. There are a lot of great articles on an amazing amount of topics. There is a dark side though.

An article recently popped up in my recommended stories titled, “Stop Using Booleans in Your Swift Code.” I was immediately intrigued and asked myself, “What is more simple than a bool and how could I possibly stop using it?, “ Who is this genius?”

Lesson 1: Watch out for strange calls to action

Any time you see an article telling you to start doing something crazy, or to stop doing something normal, your ears should prick up. Your face should look something like that dog above.

The author gave an example of a boolean usage:

var isDataLoading = false
isDataLoading = !isDataLoading
isDataLoading = true
isDataLoading = false

He said the code wasn’t necessarily readable for everyone because “we confused a negative case with a negation condition.”

Did we? I don’t think so. I think he might be talking about the logical not operator? (!)

Continuing through the article he recommends replacing the boolean with a two value enum. Which he starts as:

At this point I was thinking he is was going to make something ultra-readable and concise type of enum hybrid that would integrate with the thing doing the loading in the original boolean. I couldn’t have been more wrong. (The comments are his, not mine.)

Yes. That’s what happened.

He wants to replace a bool, with an enum.

More accurately:

He wants to replace a bool with an enum with an on and off case, with a boolean property to tell you if it is on, with a boolean property to tell you if it is off, with a function to toggle between on and off, and a current value property that computes a boolean based on itself.

He replaced a boolean with an enum with three boolean properties and a function.

It got worse, he showed usage: (The comments are his, not mine)

/// Variable Declaration [sic]
var isDataLoading: BoolEnum = .on
/// check is data loading on
if isDataLoading.isOn { 
   print("Loading is on")
}
/// check is data loading off
if isDataLoading.isOff { 
   print("Loading is off")
}
/// Switch varaible [sic] state
isDataLoading.switchType()
/// Get current Value of variable
isDataLoading.currentValue 

Confused Dog

I tried to write a “not mean” response in hopes he might remove the article as I didn’t want any beginner Swift programmer to see this “Senior” Developer’s work. As a developer community, we need as much good information and as little bad information out there as possible. I’ve put my response to him at the bottom of this article.

I told him how “isDataLoading.isOn” looked more confusing than the original bool. I told him how it would be less efficient. I told him that his “changeType” function was poorly named as it wasn’t changing a type and that Swift booleans already have a “toggle()”

Lesson 2: Watch out for bad or no reactions.

If someone critiques or ask questions of them in the comments and they block them or ignore them. Might want to put on the skeptical glasses. If someone has a good idea, they should be happy to defend it. As coders, when critiqued we should embrace constructive criticism and correct our deficiencies when identified. That’s how we get better.

Lesson 3: Watch out for bad practices.

If someone is commenting their code like this:

/// currentValue  will give what is the current value
var currentValue : Bool

It’s time to put on your skeptical glasses. A violation of something as basic as DRY, should raise red flags.

It doesn’t necessarily mean that their further writing is wrong. It’s just an indicator to be careful.

Conclusion: Be skeptical

While there are plenty of great coding resources available to us on Medium and other places, we need to be skeptical of new or unvalidated sources. Anyone, including me, can sign up for Medium and label themselves a “Senior” Developer. Ask yourself questions like:

“Is this more complicated than the problem it is trying to solve?”

“Was there a problem in the first place?”

“Is this clickbait?”

Thanks for reading. I’d love to hear from you in the comments below. Was I being too harsh?

A portion of my original response to him is below:

If I saw:

if isDataLoading.isOn {}

I would be confused and have to look up the definition of isDataLoading to see what’s going on. What is an “isDataLoading” if it’s not a boolean. What does it mean for an “isDataLoading” to be on? I know what it means if is “true.” You know… like a boolean. If my code has people doing double-takes, or asking bizarre questions of themselves like, “Why or how does this boolean have an “isOn” property?,” then I know I’ve done something genius, or more likely horrible.

The normal way:

if isDataLoading {...}

… makes complete sense.

You could make it more clear by making it a property of what is doing the data loading and call it like so.

if dataLoader.isLoading {...}

The switchType() mutating func is inappropriately named. It does no type switching. Boolean already has toggle()

…