Question

Code is read more often then updated. Writing more readable code is better than writing powerful and geeky code when compilers can optimize for best execution.

For example see below code – this code can be compressed by combining the nested if statements, but will the compiler not optimize this code for best execution anyway while we get to maintain the readability of it?

// yeild sunRays when sky is blue.
// yeild sunRays when sky is not blue and sun is not present.
if (yieldWhenSkyIsBlue)
{
    // if sky is blue and sun is present -> yeild sunRaysObjB.
    if (sunObjA != null)
    {
        yield return sunRaysObjB;
    }
    else
    { 
       // do not yield ; 
    }    
}
else
{
    // if sky is not blue and sun is not present -> yeild sunRaysObjB.
    if (sunObjA == null)
    {
        yield return sunRaysObjB;
    }
}

As opposed to something like this :

// yeild sunRays when (sky is blue) or (sun is not present and sky is blue).
// (this interpretation is a bit misleading as compared to first one?)
if(( sunObjA == null && yieldWhenSkyIsBlue ==false) || (yieldWhenSkyIsBlue && sunObjA != null) )
{
    yield return sunRaysObjB;
}

Reading the first version depicts the use case better for future enhancements\updates ? The second version of the code is shorter but reading it does not make the use case very apparent or does it ? Are there other advantages of second case apart from concise code ?

update #1 : yes it returns ObjB in both cases but based on the condition it may not yield at all. so the strategy decides when to yield and when not. ( one more reason why readability is imp)

update #2 : updated to site a better example. copied the syntax from stripplingWarrior

update #3 : updated for “What do you expect to happen when the sun is out and the sky is blue”.

Answer 1

Unless you’re doing it for fun or a specialized use case, I would argue human-readability is by far the more important quality of good code. The compiler is going to collapse much of your expressive code into more efficient forms, and what it misses you probably won’t ever notice.

Given that, idiomatic code is easier to read even when it’s less concise. Experienced readers of a language are going to recognize a common pattern more quickly than unfamiliar code that is, arguably ‘more human’ but breaks the familiar pattern. Looping/incrementing constructs are a good example of code that should be unsurprising. So, my approach is: Be expressive but not too clever.