## Explicit Approach in Coding

During early years of my programming, I tend to make everything super generic, as automatic as possible. For example, if I want to make rendering system to render multiple layers (opaque, translucent, etc2). I will do a generic system so that each layer will register to a render manager. Subsequently, render manager will just iterate through all registered layers and do something (update/render) with them.

Something like this:
// Assume we have RenderManager class and RenderLayer class

// Initialization
void RenderManager::Init()
{
// Create and register each layers
RegisterLayer( "Opaque" );
RegisterLayer( "Translucent" );
RegisterLayer( "PostFX" );
...
}

void RenderManager::Render()
{
for (int i=0; i < numLayers; ++i)
layers[i].Render();
}

Isn't this awesome? We can create as many layer as we want and when adding a new layer, we just need to modify Init()!

Issue #1: Ordering

One thing we have to resolve is that how do we determine the order of the layers. Is it the same as the order of registration? or maybe we can add some sorting value when registering? Whichever method you choose,  changing the order should be easy to do.

Ok, with some way of ordering the layers, the system looks great! This surely will be the best system right? The problem with this is that when the project grow bigger and then more people are involved. Let say we have some problem when rendering the translucent layer, we have to inject some code such as:
void RenderManager::Render()
{
for (int i=0; i < numLayers; ++i)
{
if ( layers[i].Name == "Translucent" )
__debugbreak();
layers[i].Render();
}
}

If you opt with "sort value" system to determine the order, you need to write Dump() function to print out the ordering.

In this case, the better way is to do this explicitly. This basically laying out the rendering order in the code. It will be self-documenting code and it will be easy to debug.
void RenderManager::Render()
{
...

RenderOpaque();

RenderTranslucent();

RenderPostFX();

...
}

When you encounter this code, it will much easier to read! Of course, the downside is that you need to modify Render() when adding a new layer. However, this happens infrequently, so it makes sense to do explicit approach.

So, do you think we have to change all our system to explicit approach? Nope, surely not, there are certain things that will benefit from general approach. You need to evaluate whether it makes sense to do explicit approach. Explicit approach is not always a bad thing, sometimes it's better than general approach.

If there's one thing to be picked up from here is that we have to remember that our code will be read with other people (including ourself), we have to craft it so that it's easy to understand (and to debug)

## Migrating to Mac for Windows User

This post aims to help Windows user/developer to switch to Mac. If you are a developer and wanted to jump to Mac for iOS/Mac development, this post will help you :)

Must-Have Apps

• Sublime Text 2 - this is more for Notepad++ replacement in Mac
• gfxCardStatus - menu bar app that will show you which graphics card is in use (discrete or integrated)
• XtraFinder - misses Windows Explorer? this is must install that will make Finder a little closer to Windows Explorer.

## Mixing Compile-Time and Run-Time Conditionals

When working in a large project with multiple features, you might be facing with a lot of #if-s. For example:
#if DO_FEATURE_A && DO_FEATURE_B
if ( doCheck || doCheckA || doCheckB )
#elif DO_FEATURE_A
if ( doCheck || doCheckA )
#elif DO_FEATURE_B
if ( doCheck || doCheckB )
#else
if ( doCheck )
#endif
{
...
}
The problem with this code is that as the number of features arises, you will have more and more permutations of #if-s to take care. Let see something a little bit better:
if ( doCheck
#if DO_FEATURE_A
|| doCheckA
#endif
#if DO_FEATURE_B
|| doCheckB
#endif
)
{
...
}
The code is orthogonal, however, imagine you have lots and lots of this, your codebase will be super hard to read! I like to organize this a little differently, which have best of both worlds: orthogonality and clarity:
bool doSomeCheck = doCheck;    // General check on all conditions
#if DO_FEATURE_A
doSomeCheck |= doCheckA;       // Check on Feature A
#endif
#if DO_FEATURE_B
doSomeCheck |= doCheckB;       // Check on Feature B
#endif

// The logic below will be uncluttered and easy to see
if ( doSomeCheck )
{
...
}
Depending in the situation, it might better to refactor it to a function too:
static bool ShouldDoThis()
{
bool doSomeCheck = doCheck;
#if DO_FEATURE_A
doSomeCheck |= doCheckA;
#endif
#if DO_FEATURE_B
doSomeCheck |= doCheckB;
#endif
return doSomeCheck;
}

// so the existing code becomes
...
if ( ShouldDoThis() )
{
...
}

There's some minor catch of organizing it the way I described. You will lose some logical shortcut, because instead of using || we are essentially just use |. So, there might be a place where this technique is not appropriate. However, most of the time, the penalty is small so you should be able to use this style.