Coding Arguments - aka How to Start Religious Wars

I am lucky enough to work for a company that  really encourages us to get together and learn/hang out etc.  One way this happens is by Tech Nights. Basically, we have in office meetings which are recorded via Live Meeting, where someone picks a topic and teaches about it. Afterward, folks go to dinner and the company picks up the tab. Two weeks ago I had done the presentation and we all went out afterward.  Two of our new guys were with us, and the rest of the folks there had all worked together at a particular client.  Both of our new guys are really sharp, can talk their share of smack when necessary and been here long enough to feel comfortable speaking their minds if they want to.

The first discussion was regarding Frameworks.  One of us mentioned that he liked Frameworks and believes in them.  Being the smart a55 that I am, I asked "What in the h3ll does that mean?"  .  He proceeded to explain that he believed in code reuse and has build reusable code at every opportunity.  Trying to have a little fun and encourage discussion, I asked him "Who doesn't believe in code reuse?  But if that's the only goal, then a function gets the job done.  Above functions, the whole reason for OOP is to facilitate reuse and simply building a bunch of objects that can be used sounds a lot more like an API than a Framework".  The guy in question is a top notch coder and certainly understands the difference, he just had a little trouble using 'official definitions'.  But asking what differentiates a Framework from an API turned out to be a pretty decent question to ask b/c neither have absolutely conclusive definitions that make them mutually exclusive. As such, it's precisely the type of argument that a bunch of nerds can argue into the ground over dinner.

 I mentioned before that the 'rest of us' all worked at a certain client together.  Personally, I'm pretty fond of standardization when it comes to coding. So even if I think my way is better, I'll use the predominant methodology in most cases simply b/c I think that in general, any improvements that doing it 'my' way brings will be more than offset by complications resulting from differing coding styles. If nothing else, it will usually mean that every time someone looks at it, they are going to ask "Why is it like this instead of ...".  It ends up causing you to explain it over and over and have pedantic discussions with each new person that joins the team. Similarly, if you differ from what's being done, it's a virtual certainty that the implication of it will be that 'the other way is wrong'. Most of the folks I work/worked with are humble enough to acknolwedge that any given way they chose to implement something could have been better (any *real* coder will always acknolwedge it could have been done better. Anyone that says it couldn't is either egotistical or clueless).  However, just because people are ok with admitting they didn't chose an optimal design methodology, that doesn't mean it's cool to rub it in their face.  After all, you'll be on that side of the equation unless you never have to design stuff.  Not that I recommend doing things wrong just to save people's egos, but some times, it's too easy to get so carried away with saying "this is right" or "this is wrong' that you forget to remember  "It needs done". Another problem with doing things differently is that opinions are like Carrolls, everyone has one.  What seems obvious as day to one person may seem utterly silly to another.  Design decisions are all about tradeoffs and since we all see the value of tradeoffs differently, well you know...

 Since a few of us worked at the same client, I decided to provoke a little bit.  We had worked there at different times, except for me - I was there throughout the time each of the other guys was there. So one of them had really strong opinions about how well code should be formatted.  So on the one side we had the following:

• Upper case for Keywords and reserved words
• Commas at the beginning of the line
• Each column on a different line
• Lining up words in the center
  UPDATE Whatever
   SET Whatever
 WHERE WHATEVER
• Immediately getting rid of any objects that aren't used or that were just used for testing
• Using Source Control to track versioning differences.
• Death to Hungarian Notation
• Names should be self documenting - no acronyms, developer initials or anything that might lead to confusion about what the method should do.
• Only including update information in the procedure's/parameter's  documentation and leaving big changes to the source control system.

Since we didn't have a Source control system at the client (their choice not ours), part of this reasoning was problematic and I'm probably leaving a few things out,but overall, this characterizes Argument 1.

Argument 2 on the other hand was

• Document everything in the  procedure.
• Have a dated comment showing who made the change every single time anything was changed
• Leave backups and test objects in the database because they may be needed later
• Minimal attention to formatting (although each person that advocated this was very careful about how their code performed. So it  would be totally unfair to imply their work was sloppy - they just had more of a don't sweat the small stuff but make really sure the big stuff is right approach
• Use initials for personal utility procedures so they can be found and used easily.

Personally, I am a nut about formatting. I'm really fastidious about formatting and would clearly rather have NO comments than out of date comments or too many comments - but that's not to say that I am anti-comments in any sense. I also am pretty fussy about source control, if you are going to have any configuration management, I can't stand it being done in comments inline or at the top of the code - it needs to be in a version control system.  So on this one, the people that were on the project who preferred Argument 1 were in the minority. However at the table, we were in the Majority.  This immediately led to a small trash talking session among friends.  Little did we know the new guys were so interested in the topic. One of them seemed to be pretty opinionated but it wasn't until a week later that we realized how much so.

The thing is that while I consider myself a Data guy, my theoretical understanding of Relational Database theory is much stronger than say my DBA skills are. And although I'm admittedly a little fussy about formatting and the like, I have to admit that many of the best DBA's I've worked with are much more relaxed about formatting and commenting than I am. Many of them not being AppDev guys don't depend on Source Control and prefer to handle versioning issues inline. It's difficult to argue against competency so in the end, my utimate belief is to defer to the best guy on the project.

 Have you encountered any discussions like this that you didn't really think would get people talking much but ended up getting people really involved?  Personally, I think that as long as you're dealing with mature professionals, these sorts of things are great b/c folks are passionate about them, so you have smart people putting forth their best arguments, and you can't help but gain perspective and knowledge. On the other hand, if you deal with people who get defensive easy, or who have trouble admitting they don't know everything (funny how the more defensive they are , the less they actually know in most cases), well, this stuff will do nothing but cause bad blood. 

So which side do you fall on?  I'm guessing it's not this black and white in many cases, for instance, the comma issue could fall in either group.

What sorts of things have you come across that have stirred discussion? Any specific coding arguments, and if so, what?