Superpiplining. Methods that call methods that call methods do not magically add value along the way.

If one tier is bad, two tiers is better, why not n tiers (or layers), I mean, literally an infinite number of tiers, each adding zero value along the way. I call this patter “Super Pipelining” Super pipelining makes dependency tracing a pain. A typial super-pipelined application will still put all authorization, validation, calculations in the UI and pass System.Data or SqlClient objects back and forth the super pipeline.


class Customer() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}

class CustomerBusinessLogicDomainScenarioDatabasePersistenceObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}


Ziggurat. A class that inherits from a class that inherits from a class that inherits from a class where the middle classes and the base don’t do anything. The classes in the middle do not magically make your code better.


class BusinessObject: BaseObject {}
class BaseObject: BasementObject{}
class BasementObject: UndergroundObject{}
class UndergroundObject: UbberBasementObject{}
class UbberBasementObject: SuperDuperBasementObject{}
class SuperDuperBasementObject: AceOfBaseObject{}
class AceOfBaseObject: China{}


I beseech the developer community to swear to never use #region or #endregion blocks again, except for possibly machine generated code.

The first step is to stop typing #region and #endregion. This will greatly improve the transparency of your code. Next, because you are the sort of person that uses #region and #endregion to hide the code you are ashamed of– go find all those HACK:, BUG:, and CRAP: comments.

You will get a YSOD, but the finally block executes before the YSOD.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
}
finally
{
int foobar = 1 + 1;
}

This is kind of like a IDisposable patter at the method and code block level. It means, on the way out of this code block, I want some clean up code to run. Off hand I can’t think of a good reason for this if you aren’t releasing resources. Using it as a control of flow technique looks very iffy especially if it wasn’t the error you were expecting.

Identical behavior to the above, YSOD, but finally block runs just before the YSOD. The following is code you’d see in code generation scenarios where the try/catch/block is code generated with the hope that the developer would fill better error handling later.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
}
catch (Exception) {
throw;
}
finally
{
int foobar = 1 + 1;
}


YSOD after line one, no other code after the error is executed

int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
int foobar = 1 + 1;