Splitting example is way too much indirection, but capturing what the code does in the code itself is a preference for me. In any high level language don't know why the middleground wasn't explored:

    var hasSymbol = getSymbol(symbolName) != null
    var replacementPending = !alreadyReplaced.contains(symbolName)

    if(hasSymbol && replacementPending){
      alreadyReplaced.add(symbolName);
      stringToReplace = stringToReplace.replace("$" + symbolName, translate(symbolName));
    }

Technically this performs worse because you lose short-circuiting, but in performance-sensitive contexts code styling is less a concern anyways. And I also wouldn't rely on short-cutting alone to avoid a really expensive operation or side-effect: at some point someone will fail to notice it.

▲ 1718627440 4 days ago | parent | next [-]

As for the comments, I would probably write it like this:

    /* Symbol actually exists */
    if ((NULL != getSymbol (symbolName)
    /* and still to be added */
    &&  (!alreadyReplaced.contains (symbolName))
    {
        ...

Although in this specific case the comments seem like noise to me.

> Technically this performs worse because you lose short-circuiting

Not really, because optimizing compilers are a thing, when this thing is parsed into SSA, there won't be a difference.

▲

BoorishBears 3 days ago | parent [-]

The compiler would have to determine that these are pure calls which I wouldn't rely on if performance actually matters

I just tested a recent gcc at -O2 with a contrived example using strings in an unordered_set: a look-up always occurs if not relying on short-circuiting

	▲	1718627440 3 days ago \| parent [-]
		True, I missed that the calls likely traverse translation units, because this is not how I write code.

▲ broken-kebab 4 days ago | parent | prev [-]

I like your version, and it's certainly possible to split too much without any practical result just for the dogma. But wrt the particular example I can see what's going on with a glance over the split part, while I have to focus at the commented one. Comments themselves can be helpful, but they can also be misleading cause code and coder's thoughts are not guaranteed to be in harmony all the time.