Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

What's your .NET programming philosophy?

I've been doing VB for over 10 years, did ASP, JavaScript and VBScript, now doing .NET.
So we just hired this contractor. I asked him to write an import utility to parse data from an ascii text file and import it into an Oracle table. A week or so later, I looked at his code and I couldn't make heads or tails out of it. He had dragged and dropped all the data components (connection, dataset, etc). He had like 6 or 7 vb files with all these different classes. He had code that checked the schema of these drag-and-drop-tables just in case they ever change. And instead of writing good old-fashioned INSERT or UPDATE SQL, he set some sort of flags on the dataset, and let the data adapter update the records to the Oracle table in one fell swoop. We're talking over 2,000 records. Is this how all you other .NET programmers are doing things? Have I been out of the loop on something here? What's your philosphy drag and drop components and one-button-push-data adapter to do updates/inserts/deletes?

SongSing Writer
Sunday, October 03, 2004

For me, the answer depends on whether it was just a throw-away project, or whether it was intended to be used and maintained in the weeks and years ahead.

I did wonder why you'd want to write code to do this, then the Oracle tools will just do it for you, but that's another story.

The drag-and-drop approach is fine for disposable code, but, imho, is inappropriate for long-term code, as you cannot comment it.

Unless the code is trivial, in which case it doesn't really matter, it is useful to be able to comment and document your code, showing why it is like it is. The is generally not an option when you just use the designers.

In my case, I would never use the designers, preferring to code everything myself. I am not convinced they add much productivity (for someone who knows what they're doing) and they can hide a lot. Obviously, I don't hand code everything from scratch, and use library classes where appropriate to gein productivity.

I spend a large portion of my time writing web-applications in ASP.NET and I never use the "Design" view for webforms, preferring to see what I'm actually getting, by working in the "HTML" view all the time.

This is what I never liked about Dreamweaver, et al. It could do a lot by drag-and-drop, which is great, but if you need to debig it, or chase out performance issues, your swamped by a see of code that all looks the same.

Sunday, October 03, 2004

The code that he wrote is not throw-away, it's a permanent update program to run weekly. When I asked him to not do the drag-and-drop components for other things in the future, he got quite defensive, and said by not doing it that way, you'd be using more CPU, etc. On another project where I asked him to do a simple enhancement, he ended up adding a new class and re-writing underlying code with all these new procedures and all, which I found out when there were several odd bugs. When I tried to kindly point out that all that was needed was one procedure and one function, he again became very defensive and said that he'd been building systems for 15 years, and that was just his programming style. I told my boss all this, (who does not have a programming background, and doesn't like confontation), but he's not giving me much support.

SongSing Writer
Sunday, October 03, 2004

Sounds like an idiot, in fact the boss sounds like an idiot too.

Do you have the clout to specify how the work should be done ? If so, use it and give this person a formal warning each time they ignore your instructions, along with suitable praise if/when they do it your way.

If you don't have the authority, then it is perhaps time to look for a new job, and leave "laurel and hardy" to get on with it. Life's too short to work with these know-it-all, been-there-done-that maverick-types.

Sunday, October 03, 2004

What's my .Net programming philosophy?

"Crush your Bugs, see them driven before you, hear the lamentation of their women."

    Flava Flav!

Flava Flav
Sunday, October 03, 2004

Drag-and-droppers are often too disinterested or lazy to bother understanding the underlying details and produce slow and bloated code that they don't really understand. Hand-coders are often obsessed with technical details and happily spend a week coding something that the IDE could do in 10 seconds. The best coders learn stuff the hard way (eg. no IDE) and then use the various tools to make them more productive.

Monday, October 04, 2004

First off, some big props to Flava Flav... anything remotely related to Public Enemy is 'aight in my book.  If someone is defending drag n' drop on account of CPU cycles, I'd be a little skeptical.  The fact is that writing good code and practicing good development habits trancends any language, platform, etc.  Sounds like this person is hiding behind the toolset a bit and perhaps lacks a decent understanding of what the designer is infact doing under the covers. 

If someone busts open the visual designer to write a script, that seems a bit odd to me. 

Monday, October 04, 2004

INSERT or UPDATE SQL... Well, allthough I never use the components, no drag & drop programming for me!, I do not like coding INSERT and UPDATE SQL statements either.

Use ADO.NET! I believe you acquire a DataSet, manipulate that until it is what you want and then: Update the DataAdapter...

The problem with INSERT and UPDATE statements is: You have to define them in strings, escaping stuff, formatting dates accurately - oh, and what about all those funny characters? Are they guaranteed  to work? Did you set the language / codepage stuff correctly? ADO.NET does!

Daren Thomas
Tuesday, October 05, 2004

> The problem with INSERT and UPDATE statements is: You have to define them in strings, escaping stuff, formatting dates accurately
Not necessarily, you can use Parametered queries

Tuesday, October 05, 2004

I use parameterized queries and sprocs.  Dynamic SQL when absolitely necessary, but it's easy to externalize them to a resource file.  I don't use the updating data-adapters, never have.  Never used those features in regular ADO either.  It's just a non-portable paradigm.

Basically my .NET programming philosophy is data tier -> domain / model tier - > UI.  I use LLBLGEN (ORM) for the CRUD, and write custom code on top of that.  It's cake.

Tuesday, October 05, 2004

SQL goes in a seperate file with a .sql or .plsql or .tsql extension that is then embedded as a resource.  This lets you use all your normal SQL editing tools.

I load the resource to a string in a static constructor.  If it is a situation where I *have* to use dynamic, parameterized SQL (never just dynamic SQL) instead of static parameterized SQL, I'll load it into a StringBuilder instead.

Richard P
Tuesday, October 05, 2004

I actually don't like the idea of putting SQL into a ressource file. My strategy is to build all the SQL statements during runtime using a set of strict naming conventions and .NET reflection.

Having encapsulated sql statement computing into database specific classes, changing the database from Oracle to PostgreSQL to Access to MySQL to ... therefore is a snatch.

I also wrote a custom reflection level for associations, which enables me to build database independend queries and even complex joins using objects, not strings, and compute and optimize the SQL at runtime.

This works out very well, unless you do not have to do 100% optimized queries for terrabyte of data.

Gerd Riesselmann
Wednesday, October 06, 2004

Doesn't Oracle have a bulk copy program like SQL Server?  You just give it a schema and off it goes doing the transformation for you much faster than any program you could write even using the world's greatest sprocs and data adapter.

In any event, unless this is a much more complicated job than you've made out, it sounds like a classic single-source-file script style utility to me.  Under 1000 lines which anyone can follow, edit and compile without a makefile or project in the future.

Wednesday, October 06, 2004

"On another project where I asked him to do a simple enhancement, he ended up adding a new class and re-writing underlying code with all these new procedures and all, which I found out when there were several odd bugs..."

I sympathize with him on this, because I've been working on an Excel-based system where I had to do a lot of refactoring in order to make sense of the code, which had lots of global variables, vague references to ActiveWorksheet where it should have used an object variable to a specific worksheet, and so forth.

Of course, refactoring shouldn't result in bugs that weren't there before, and shouldn't go beyond the stuff you really need to change; I've left a lot of stuff as ugly as I found it simply because it works fine and there's no need to enhance or change it.

One thing driven home to me on this project is the importance of preserving the interface.  Some worksheets call procedures in other worksheets, so if I rename an existing procedure, I've broken the interface.  Instead, in places where I've combined as many as twelve nearly-identical procedures into one, I've introduced a new procedure with parameters and pointed the old procedures to it.

Monday, October 11, 2004

I suggestion think a bit about what his VALUES are:

E.g., he justified an approach as "saving CPU cycles".

Is "convervations of CPU cycles" something he values?

Sounds like he may have different values from you:
e.g.,  CPU cycles, future expansion capability, etc.

We often get caught up in our PERSONAL values, forgetting the needs of the job.

E.g., a perfectionist who cares more about perfection than productivity.
A "busy" person who cares more about looing/feeling busy than in efficiency (e.g., they'd rather hand code all day long than sit back and THINK for a while because that feels LAZY)

If you communicate to him what YOUR values are perhaps you can sell him on those values.

Steve Jobs was trying to get the Mac developers to get the Mac to boot faster. So he said "a million uses will boot up twice a day on this machine. If you can shave off 5 seconds you'll save 10 million user-seconds EVEY DAY. Or about 2 billion user-seconds a YEAR."


Mr.Analogy (Shrinkwrap ISV company owner)
Tuesday, October 19, 2004

From what I can tell, the contractor was doing the right thing. This is how stuff is done in ADO.NET.
DataAdapters exist for several reasons. ONE of which is to ensure that INSERTS, UPDATES etc. are abstracted in a uniform manner. Another is to ensure that an INSERT or UPDATE is performed when and only when neccessary. Whether you work with 20 rows or 20,000, the approach is sound.
As for using "drag-and-drop" tools, I do not find anything wrong with that approach. The tools have been created by smart people who have solved a given problem many times, and have evolved a method of doing this efficiently. Provided one knows what these tools do, exactly, there is nothing wrong with using them. Case in point: I use the designers in VS.NET to create typed datasets.
A question I would like to ask the original poster; why is the "programming philosophy" important to you?

Raj Chaudhuri
Monday, October 25, 2004

Who let John Kerry into this discussion (Mr. Analogy)?

The guy's a contractor for god's sake... fired his ass and find someone else. 

Friday, November 05, 2004

*  Recent Topics

*  Fog Creek Home