I'm confused: "I was moved to IT very shortly after that and I've been writing software here ever since. I've never been to college for this. I've worked very, very hard for the past fourteen years" So for 14 years you've been in IT? But your solution that kicked it all off used SQL Server 2008?

Different people will have different opinions and preferences. So you need to define what you think sucks about open offices, before people can suggest ways to desuckify them.

Good point, I just wanted to use let and drop the new[]. I believe I have manged it now if you look back at my post.

Great answer. Can use let rather than that new []{} however: int closest = (from i in inputs
let avg = inputs.Average()
select inputs.Aggregate((a, b) => Math.Abs(a - avg) < Math.Abs(b - avg) ? a : b)
).Single();
That is actually wrong, but this works and average is called just once:

        int closest = (from c in "A" //just to get it to loop once
                       let avg = inputs.Average()
                       select inputs.Aggregate((a, b) => Math.Abs(a - avg) < Math.Abs(b - avg) ? a : b)
          ).Single();

Does anyone know of a nicer way to cause just one loop in linq than my 'from c in "A"' trick?

int closest = inputs.Last(); Or have I missed the point? ;P

I am with you that if it's an integer or pointer do the code like you have described, it's fine code, I do prefer to do it this way. But you still arn't using defines for true and false, which is my original beef. However any compiler that doesn't define zero as false and non-zero as true for boolean expressions is not a standard C compiler.

Well this kind of code can be even more dangerous in C where you have #defined your true and false constants (dont' know if it's same in C++). Now you can get the situation where potentially neither section 1 or 2 runs:

if(a==true)
{
//1
}

if(a==false)
{
//2
}

At least if you don't use the constants, it behaves as a boolean, here either section 1 or 2 is guaranteed to run.

if(a)
{
//1
}

if(!a)
{
//2
}

I bet a happy programmer isn't one who gets their post "Message Automatically Removed"

The harm comes entirely from maintainance, more code == more bugs or at least harder to spot them. I apreciate your style preference on the last one, and the last thing I want is to start a style argument, but I am curious, would you also do this if you had two flags?:

if((flag1==true) && (flag2==true))
{
...
}

Because this guy does, and they get longer and longer because of all the ==true and ==falses, makes simple boolean expressions look very complicated.

This stuff drives me up the wall!!!

bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}

Or this:

bool counter_zero = counter==0 ? true : false;

Or this:

if (isUDPSetup()==true)
{
if ((forceSend==false))
{
...
}
}

(Variable names have been changed to protect the guilty) Or this *New one*:

void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
}

I sometimes do this in C:

void method(void)
{
//initialization, e.g. mallocs
do //think try
{
//some stuff

if(early exit condition)
{
break; //continue is also fine
}
//other stuff (but skipped in event of early exit condition)

} while(false); //think finally
//finalization, e.g. frees
}

This effectivly gives me a try...finally in C. Which helps reduce ifs nesting.

I'd prefer someone do this:

while(true)
{
if(matched condition A)
{
do something A
break;
}

if(matched condition B)
{
do something B
break;
}

}

to this:

bool exit = false;
while(!exit)
{
if(matched condition A)
{
do something A
exit = true;
continue;
}

if(matched condition B)
{
do something B
exit = true;
continue;
}
}

It's messy, longer and more prone to bugs when being supported/extended, and all just to avoid the "infinite loop", even though really it's just as "infinite".