>>Walter is deliberately harassing me. Yet you permit it. That was my complaint to Koen. They cannot understand the simplest techniques. No one in the community accuses Walter, like I was accused.
>>
>>I have seen so much stupidity and I'm sick of it. We can do better. Transactions should be a standard, which is better than the piece-meal approach too often used.
>
>OK, time out on the field.
>
>Mike, at this stage, I'm really perplexed. I'm sorry to have to say this, but I'm going to - you need to calm down.
>(I'm not "permitting" anything). Yes, Walter has made comments I also don't agree with, but truthfully, you seem to be instigating much of this.

What you are missing is that recently someone asked about mdot. I give the most technically accurate scientific answer possible and all Walter does every god damn time is the argue against me out of sheer spite. So you're actually allowing him to continue by your silence. Check message 01680935 and see that he thinks it's fun. It's harassment and it should not be allowed. PERIOD.
>
>You and Walter are both swiping at each other, and quite frankly this entire thing is getting silly and out of hand. You are both smart guys and less experienced developers can learn from both of you....but not in this way.
>
>Both of you have made some valid points. All I was doing was building on a good point that Walter made - transactions are, among other things, the framework for the "ooops, never mind, I take it back" protection for integrity of the data. I was merely talking about one particular context of transactions. I agree, they should always be used.
>
>Final comment....these "if you do this, you might be a crappy coder" posts are not going to advance any ideas.
>
>I agree.....hard-coding names is a bad idea. Guess what, I've seen source code from commercial applications that do it.
>Copy/paste is a bad idea....guess what, I've seen source code from commercial applications where a change is required across X modules, simply because the authors didn't think about a level of abstraction.
>
>I could go on, but hopefully you get my point.
>
>There's bad code all around. It can happen for many many reasons.
>
>My boss wrote a 1.0 version of a cost piece before I showed up. It "worked", but he and I both agreed it didn't work well. There was repetitive code....there were things hard-wired...there were assumptions made that a query would only return one result. I took it over, was able to devote more time to it, and cleaned up a lot of things. My boss never felt any "pride of ownership" and never got defensive. Also, he built that 1.0 version out of NOTHING. I was able to fine-tune and clean up things because he had done much of the initial leg work on the project. Systems evolve...and even though his code probably broken about 50 of your rules, it doesn't mean he was necessarily a "crappy coder". I think that's kind of a simplistic way to look at it. There is a balance between business and time/resource realities, and writing good clean code that's nice and elegant and less likely to break.
>
>Now, some shops try to mitigate this by having code reviews. They can be good ideas, if they are run by experienced folks who know how to pick battles. I've been in some good code reviews and I've been in some that clearly resulted in making solutions far more complicated by over-abstracting.
>
>But seriously, this "if you do this, you might be...." is going nowhere, fast.