You don't need to use fzf. Zoxide has an interactive function too.

Yes, because you don't have to pop in order. "zoxide <subpath>" is "search the history of working directories for a path ending in <subpath> and cd to that".

I use history | grep quite a lot, because of the non-fuzziness with default ctrl+r. If I know exactly what the substring is, then that's great, but sometimes I also want to see the sequence around the command too (e.g. two step processes like eval ssh agent + ssh add key)

I've relied on this so much that I copy my entire history between machines...

ag is also a little more ergonomic with its default flex casing: your query is case-sensitive if it has any uppercase letters, otherwise case-INsensitive. rg defaults to case-sensitive (but does have flags for insensitive and flex casing)

Flow control is not always necessary. Other times it can be minimized. The point is not to never branch, but to avoid unnecessary ones.

It's not applicable to every situation, but one way to do this is some very basic fuzzy logic. You do a little math and then either choose a single branch at the end, or sometimes avoid a branch altogether. https://www.geeksforgeeks.org/artificial-intelligence/fuzzy-...

Another way to avoid some branches is to have specialized routines, maybe with multiple dispatch, rather than more general methods with a bunch of checks within them for slightly different situations.

A classic performance hack for critical sections is loop unrolling.

Here's an example of removing a branch that was posted to HN a little over a month ago: https://www.greyblake.com/blog/branchless-rust/

  if (x == 0) {
      return y;
  }
  
  y += 25*x;
  return y;

  if (count == 0) {
      return;
  }

  for (int i = 0; i != count; i++) {
    puts("hello");
  }

Maybe they mean rather than:

if (thingThatIsTrue):

  // a bunch of logic here...

else:

  // different logic here...

they mean:

if (thingThatIsTrue):

  return doThisWhenTrue()

return dothisWhenFalse()

Just a simple example. I'm not sure if this is what you consider "obfuscating" the branches. Logically the same, but a bit more linear to understand?

Edit: I am bad at formatting comments here.

  Two spaces before start of line.

  int main() {
    return 0;
  }

There's stuff like the "Command Pattern"/dispatching/subclasses etc that can make this nice, although it's not always a good fit.

Like imagine you have a few different classes of things A,B,C so instead of checking if the thing you're handling is an A,B,C you have like a shared interface across all and can call Thing.do_it or whatever.

Still branching conditionally but it's passing it off to language features instead of code you have to write.

well here is a branching strategy I often see, pseudocode, and often this is a really stupid example as I do not have the time to come up with a good one:

if Val === "A" then Do funcA() else if Val === "B" then

and so forth for lots of values, or using a switch statement or similar branching instead of

Object functions = { "A": funcA() {does what funcA does}, "B": funcB() {does what funcB does} etc. etc.

}

runnableFunction = functions[val]; runnableFunction();

Actually writing it I remember now someone who did this, a junior who had to update a validation function for XML invoices based on their root namespaces, which there could be a large number of these, and so she wrote out

switch namespace == "somenamespace" { validatingscheme = "someschema"; doPreliminaryFunctionToDetermineifshouldvalidate(); }

I can't remember all the details as this was almost 20 years ago, however while it was true that one branched on the schema, it made much more sense to look up what one was supposed to do based on the rule for branching and then just execute that one action rather than writing a bunch of branching logic.

So to make it more concrete: Once branching rules becomes sufficiently complex prefer query for what you should do rather than branching

on edit: note again, not real code, but should be understandable and translatable into real code to understand what is being said easily enough.

on 2nd edit: this is also just basically one of the things I prefer instead of getting a lot of branching logic. I have never seen any stats on any benefit to this model than just having a bunch of branching statements, but I feel that the benefit is there nonetheless.

Probably by using various convenience functions.

A common pattern in an old C++ job I had: People writing for loops, coupled with if conditionals, for things that could just be done by chaining functions in the algorithm library.

Don't do a for loop, check for a condition, and break. Use find_if.

What people refer to when they say "branchless code" is something very particular, and it refers to not triggering the CPU's branch prediction. That is, don't make the CPU have to guess which fork in the code you're going to take. This is usually accomplished in one of two ways: either bit twiddling hacks or specialized instructions that do not affect the CPU's branch prediction, such as the 'cmov' family in x86. If you search for `examples of branchless code using conditional moves` using your search engine of choice, you'll find numerous examples.

A trivial example is actually written with a branch in C/C++, but relies on compiler optimizations to kick in. If you compile a ternary operator in C/C++ (and probably rust, C# and other languages) such as in:

   int min_branchless(int a, int b) {
        return a < b ? a : b; // Often emits cmov with -O2
   }

With gcc/clang a -O2, one would expect the compiler to emit the following assembly:

    cmp edi, esi
    cmovle eax, edi   ; select a if a <= b
    ret

There's numerical tricks for other operations/comparisons, and compilers know a lot of them. But, I just suggest compiling your code and configuring your compiler to emit the generated assembly with references to the code it was generated from (you should be able to get it to emit source line references in the assembly). You'll likely be surprised at the optimizations applied at -02, and utterly confused by what you find at -03.

edit: Also, it doesn't mean to never branch, but to minimize branching, especially in tight loops. Branch outside loops, not inside, for instance.

e.g. don't do:

    for (...) {
        if (condition independent of loop variable) { 
          ...
        } else {
          ...
        }
    }

do:

    if (condition independent of loop variable) { 
        for (...) {
          ...
        }
    } else {
        for (...) {
          ...
        }
    }

    vector conditionmask = <some computation...>; // E.g., 11111111 00000000 00000000 11111111
    vector truebranch = <some computation...>;
    vector falsebranch = <some computation...>;
    vector result = (truebranch & conditionmask) | (falsebranch & ~conditionmask);

There are multiple ways to avoid branches. An early return, a lookup table are two that I use regularly and consider a code smell when the AI uses many if clauses or switches.

Maybe something (contrived) like this providing no-op defaults?

  total = calculateOrderTotal(user.order);
  if (user.isPremiumMember) {
    total = total * 0.9;        // 10% discount

versus

  total = calculateOrderTotal(user.order);
  discount = calculateDiscount(user);  // Returns 0.9 or 1.0
  total = total * discount;

  total = calculateOrderTotal(user.order);
  total = total * user.discount;

  total = calculateOrderTotal(user.order);
  total *= user.discount;

  return 
         calculateOrderTotal(user.order)
       * user.discount;

   return 1 - user.isPremiumMember * 0.1;

some initial function like

  v = setup()
  if v == 1:
    side_effect_1()
  elif v > 1:
    side_effect_1()
    side_effect_2(v)
  else:
    raise Exception()

then we can "refactor"

  v = setup()
  if v < 1:
    raise Exception()
  
  side_effect_1()
  if v > 1:
    side_effect_2(v)

i know that this might seem "dumb" that the code was ever setup the first way but code can grow into that shape pretty easily. this refactor "removes" the v==1 branch. this new code also follows the "early return" pattern, which improves readability.