• Ginssuart (unregistered)

    bool isFristOrSecnod() { if(isFrist() && isSecnod()) { return fileNotFound(); } else { return !fileNotFound(); } }

  • (nodebb)

    "Maybe it's just me, but isFoo() && isBar() is more clear in its intent than isFooAndBar()."

    That may be true, but if "isFoo" and "isBar" are private members, you may still need "isFooAndBar". I can easily imagine a scenario (obviously not the same scenario as the post here) where "isFooAndBar" contains all of the logic, this gets refactored into "isFoo" and "isBar", leaving "isFooAndBar" as a one-liner like this. In that case, going through to refactor all of the callers and making "isFoo" and "isBar" public may not be worthwhile, or may be basically impossible if "isFooAndBar" were part of an externally-exposed API of some sort.

  • Argle (unregistered)

    I've been in the programming business professionally since 1978. I was in the airplane sector then and have returned to it again. This snippet of code doesn't surprise me. I see it littering code on a regular basis (and I'm not talking about my time teaching when I was seeing beginner mistakes). It's a wonder I dare set foot on an airplane. I recently went through an exercise where I landed an Airbus 320 in full simulator. The landing can be done without a single person in the cockpit. And the simulator itself is amazing.... BUT I'VE SEEN THE CODE! I have to shake my head in disbelief on a regular basis. Just yesterday, I was ripping up some code that was taking a number that represented up-time in seconds which was being forced into a Javascript Date class for the purpose of getting HH:MM:SS out of it. It wasn't working. Another piece of code I worked on had a quicksort written correctly in the code... but the same is already in the standard library.

    [sigh]

    You're not getting me in a self-driving car.

  • Joe (unregistered)

    "Besides, isn't the point of a function to encapsulate the behavior?"

    I mean, I kinda have to admit that I understand why someone with a certain level of, let's just say OCD, would stick to their guns on something like this. That said, name the function what-it-does, not how-it-does-it, in case the how changes, amiright?

  • Loren Pechtel (unregistered)

    I agree about the evolution, but I disagree on whether it's bad to have something like that. I consider IsFooAndBar() a bit easier to comprehend and I'm from the camp that favors minimizing the cognitive load of any given routine. So what if it's only called from one place? The optimizer is going to see that and inline it. But when it doesn't do what it says on the label nuke from orbit.

  • Anonymous Coward (unregistered)

    If they had watched Dune recently, we'd have gotten contrived "s and w or m" boolean expressions all over the code.

  • (nodebb)

    I submitted that ages ago, and had completely forgotten about it. So many more WTFs that I've found since then. So many dynamic_casts to do manual dispatch. So many C-style strings that overrun their local array length because people don't understand how sizeof works. I could fill the coffers of this site.

  • (nodebb)

    About the readability of isFooAndBar - it's like taken directly from the book Clean Code. There is so much debate on why would you move all the boolean expressions into "readable" functions. While i agree that if we have and expression with like 5 different expressions embedded - fine, the function name might actually convey the logic, but still - not for simple things like this && that

  • Officer Johnny Holzkopf (unregistered)

    Regarding the "what is is" vs. "what it does" (read like "how it does it"): What would you prefer? A function like double average(int x[], size s) or double addAllSElementsOfXaAndDivideItBySThenReturnTheResult(int x[], size s)? You must choose! And I, for one, welcome our new elaborate signature overlords.

  • LZ79LRU (unregistered) in reply to Officer Johnny Holzkopf

    Neither. I would prefer a name that describes the actual purpose of the operation and not the operation it self.

    For example, say you have a class called Inventory that contains a list of items. Now say you have a method that adds a new item to the inventory. The method should be called "Add item" and not "increment internal item list by one".

    Same story here. IsFooOrBar is a terrible name not because it erroneously describes the internal workings of the function but because it tells me, the end user, absolutely nothing about what that function is for and in which specific situations I am supposed to use it instead of just manually typing IsFoo || IsBar.

    Function names are a contract that you as the developer leave to the poor guy that has to maintain and expand your system. And they should be written accordingly.

Leave a comment on “Not What They Meant By Watching "AndOr"”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article