I'd rather that then the people who use strings for everything...*shudder*

Well, we hire them...

Code is written for people, not computers.

Maybe it wasn't always a string?

You're kidding right?

It was VERY common prior to .Net 2.0 which introduced the TryParse methods. There really wasn't a 'good' way to do this, so if the result of GetAge() was normally a valid number, then it wouldn't hurt performance much. The performance hit is only noticable if there is actually an exception thrown.

Agreed...but how does 2 wasted hours delay integration nearly a week?

I generate my cells with classnames, then run the data through a filter, and setup proper mso-number-format styles on the cells prior to sending it to excel. It works well

I'm actually using a similar technique in a recent app we have written. However, the HTML passed to excel comes from the browser. This allows us to take the data, render HTML, the user then has the ability to hide/show columns, sort, filter, etc, then export the result to excel. If I don't pass the HTML to excel (well, a per-processor that cleans it up), then I have to look at it, determine what they are currently showing, query the db all over, then try to create an excel document that mimics the displayed data WITH all the current formatting, which is a duplication of effort since all that work has already been done in rendering the HTML. It also allows us to just modify the rendering of the HTML, and the export to excel is almost always working automatically without also having to modify the code that generates the excel document.

Excel can load Html tables no problem. There are some CSS issues that arise from it. But it really does work quite well. And while it doesn't appear that in this case you're going to have any styles being applied, if you did apply formatting to the GridView, they would be reflected in the excel document.

Some of the latest bad error messages we've seen here are "An unknow error has occurred" (yep, with the spelling mistake) Another From a M$ app logged this useful message to the windows event log "The" I think that's my favorite.

I've never heard of "the problem of having too many functions"... Have you read books like Clean Code or Code Complete, etc?

It's sad how many devs don't know about the null coalesce operator either Which reminds me, I have to go teach a fellow "dev" how asynchronous programming works...

You think debugging is more difficult with more functions? I disagree. My IDE steps into functions, or over them...which makes debugging simpler, not harder. I can step over functions I've already eliminated as the problem, and into those which could be an issue. Rather than stepping on every line of code. And I should know if the bug is in a function or not by writing tests for it. My "STPVolume" or "GetVolumeAtSTP" function should have test methods ensuring it's accurate. As for the name, physics isn't my domain, so I didn't know the proper name, I made my best guess. The essence of my point still stands.

A developer should know the language they work with

// Volume by ideal gas law at STP (25C, 1 atm)
surfaceVolume = volume * 298 * p / (T * 101325);

Or even better...put that formula in a well named function and call it, so your call looks something like

surfaceVolume = CalculateVolumeByIdealGasLaw(volume, pressure, temperature);

Now you don't need the comment. And your code is easier to test.

Reminds me of things like this...

for (int i = 0; i < 5; i++) {
switch (i) {
case 1: {

    }
    case 2: {

    }
    case 3: {

    }
    case 4: {

    }
    case 5: {

    }
    default: {

    }
}

}

or TryParse ...

I presume each of these duplicated sections was in it's own method, otherwise it won't even compile. Since each var statement keeps declaring variables that are already declared.

There was tons of that in there too. Along with lots of catch blocks that broke the call stack by throwing a new, useless error message.