Proposal: Allow named boolean expressions.

[visorz]

Proposal

Before:

var isRooted = _inputDirectory is not null && _inputDirectory.StartsWith("/");

if( isRooted  )
{ .. }

After:

if( isRooted: _inputDirectory is not null && _inputDirectory.StartsWith("/") ) 
{ .. }

Before:

var exists = _inputDirectory is not null;
var isRooted = _inputDirectory.StartsWith("/");
var isAbsolutePath = exists && isRooted;

After:

var isAbsolutePath = exists: ( _inputDirectory is not null ) && isRooted: ( _inputDirectory.StartsWith("/") ) )

Or:

if( exists: ( _inputDirectory is not null ) && isRooted: ( _inputDirectory.StartsWith("/") ) )
{ .. }

Named boolean expressions could explain the expression in-place. They offer a faster code reading without creating a variable name.

Reasons

Boolean expressions can be complex and therefore do not explain themselves easily.

if( _inputDirectory is not null && _inputDirectory.StartsWith("/") ) 
{ .. }

Giving them a name is like adding a meaningful explanation what the expression is about.

var isInputDirectoryRooted = _inputDirectory is not null && _inputDirectory.StartsWith("/");

if( isInputDirectoryRooted ) 
{ .. }

Because such expressions are often only used once, creating a scope-wide variable burdens the reader's mind with one more variable name to remember. Because it could be referenced further down in the method.

To support the reading flow, the explanation for the expression should be right in place.

if( /* isInputDirectoryRooted */ _inputDirectory is not null && _inputDirectory.StartsWith("/")) { ... }

But a comment takes the mind out of the flow of reading instructions in which one tries to be the compiler or computer that needs to execute the code. A comment places the mind into the role of the developer colleague that speaks from a third angle.

I do not want a disturbance of my instruction reading flow, that is why I do not want to use a comment for an explanation. I like what variable names can offer already.

[colejohnson66]

I don't understand your complaint about comments? Variable names are also written from the viewpoint of a third-party developer.

// are we "rooted"?
if (_inputDirectory is not null && _inputDirectory.StartsWith("/"))
{
    // ...
}

if (_inputDirectory is not null && _inputDirectory.StartsWith("/")) // are we "rooted"?
{
    // ...
}

if (_inputDirectory is not null && _inputDirectory.StartsWith("/"))
{
    // we're "rooted"
}

Alternatively, just use a helper function:

public static bool IsRooted(string? input) =>
    input?.StartsWith("/") == true;

Tangent: your method of determining if a path is "rooted" is wrong and will break on any non-Unix-like system, such as Windows. Path.IsPathRooted already exists, and the name gives clear intent on what it does. It even handles null just like your testing procedure.

[Richiban]

I agree that a helper function is almost exactly what the OP should go for in this situation; if you essentially want to give a meaningful name to an arbitrary expression that's pretty much the very reason for the existence of functions.

[HaloFour]

Or, in those cases where short-circuiting isn't necessary, assigning the subexpressions to local variables is also perfectly fine and an approach I use often. In both cases of a local function and a local variable, the big advantage is that all of the gritty details of the original subexpressions can be omitted, leaving code that is easily readable.

I could see maybe splitting a larger condition expression over a couple of lines with comments to explain what they're doing, but honestly if the conditional expression is that long and requires explanation in multiple places I would want to break it up into smaller parts anyway.

[visorz]

I see, so I'll go for the option with closest proximity, in case the expression is not required anywhere else.

var isSuccessful = expression;
if( isSuccessful )
{