Code Writing Code

Question

Code Writing Code

Viewing 15 posts - 16 through 30 (of 34 total)

You must be logged in to reply to this topic. Login to reply

Gary Varga SSC Guru Points: 82166 More actions · Answer 1

It is also helpful if the generation is designed to be open to modification (perhaps thinking of the Open-Closed principle).

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

Steve Jones - SSC Editor SSC Guru Points: 734552 More actions · Answer 2

If you have custom requirements for some auditing areas, there's nothing to say that you can't modify the generated code. We used to build a generic auditing trigger for tables, or have a generator write the trigger code, but then this was modified at times.

Bill Nicolich SSCommitted Points: 1865 More actions · Answer 3

We should find a way to tag the various examples of assistive code or code writing code already in SSC.com so we can have a look at what people have done.

Regarding code writing code - or "assistive code" - some spend a lot of time in the Programmability area and some don't. When we're in there, we start to see patterns while programming. Whenever a pattern emerges and we're doing something repetitively, that's a candidate for some code to help write code.

To do anything with the pattern, there's some information that has to be available - or the gig is off. Often this is metadata. In the SQL environment, there's a lot of metadata at our fingertips such as column names, table names and so forth.

Not everyone is aware of or comfortable using the various System Views like INFORMATION_SCHEMA.TABLES that can be used to get at that information. So, as Steve said, this can be a growth area to dig in and become familiar with the metadata.

And there's tools. We've got T-SQL to help produce text as code - and there's also text editors with Regular Expressions support. I find myself using both T-SQL and Regular Expressions at times to expedite certain programmibility projects. Regular Expressions is a syntax and language in and of itself that's handy to learn.

The next question is if it's worth it. It's always a trade-off with time, effort and value. That's a zen question to decide if the extra steps to write assistive code are worthwhile in a given situation. That's a growth area - to fine-tune one's judgment of such things through experience.

So, yeah. I agree with Steve that writing assistive code can be a growth area in the programmability realm for sure.

Bill Nicolich: www.SQLFave.com.
Daily tweet of what's new and interesting: AppendNow

sknox SSChampion Points: 12388 More actions · Answer 4

From your editorial, I expected Buck Woody's post to be quite different from what it was. His focus is on generic tools that write code (i.e, code written by someone else that writes code for you), and I couldn't agree with him more. I dislike those tools for the same major reason he does -- they're generic, so they usually don't produce the ideal code, and often it's a case of rewriting what they've done almost completely to get the code you really need.

Instead, I prefer exactly what you talk about: writing your own code to write code. Why? Because if you've got a lot of mostly homogenous code to write, it gets boring very quicky -- and bored developers make mistakes. Even if it takes somewhat longer to write the code-generation code than it would to write the homogenous code, you're doing something less rote and more interesting*, and, as you mentioned, Steve, you can make the resulting code consistent and regenerate it quickly.

* That is, unless you get to the point where you're spending all day writing code-generation code -- at which point you may want to generalize and write a bit of code to automatically generate your code-generation code... 😉

James Goodwin Hall of Fame Points: 3691 More actions · Answer 5

I do a lot of process automation in my company--I look at what people are doing by hand, and find ways to automate what they do. I also get a lot of ad-hoc requests for data and reports. I have a mental guideline that if something will be done only once then you just do it, save it off, and don't worry about it. If it gets asked for again, it gets cleaned up. If something needs to be done three times then it gets an interface so the user can do it and I don't need to do it again. One of the first things I ask about a request is "Will you need this again? Ever?"

Code Writing Code is a specific case of this model with the difference that the user is myself.

--

JimFive

Revenant SSC-Forever Points: 42467 More actions · Answer 6

Code writing code was "the big idea" behind CASE, about 15 years ago. Ed Yourdon predicted that in 2000 "almost all" programmers would be using only CASE tools and if you are late to this game, you would lose your job because CASE would make programmers so efficient that the demand would go down and lots of us would end unemployed. Forget C and C++ or C# (which of course came later).

Who of you, guys, is even using Visio Enterprise to do SQLS designs? (I don't.)

david_wendelken SSCrazy Points: 2388 More actions · Answer 7

I think I would rather get my teeth drilled - every day - than use Visio to design a database with more than one table and column in it.

Steve Cullen SSCertifiable Points: 5598 More actions · Answer 8

We do a lot of this. We keep tables of extended metadata that include source and destination information, conversion and special mapping instructions. These are used to generate stored procedures that maintain our data warehouse.

Converting oxygen into carbon dioxide, since 1955.

Ray K SSC-Dedicated Points: 31148 More actions · Answer 9

Allow me to open a can of worms . . .

In perusing the forums, I see many arguments for and against dynamic SQL.

I would think this qualifies as code writing code. How well can dynamic SQL work, if coded properly?

Discuss.

+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/

Jeff Moden SSC Guru Points: 1003894 More actions · Answer 10

Ray K (3/10/2010)
Allow me to open a can of worms . . .
In perusing the forums, I see many arguments for and against dynamic SQL.
I would think this qualifies as code writing code. [font="Arial Black"]How well can dynamic SQL work, if coded properly?[/font]
Discuss.

VERY well. I don't shy away from Dynamic SQL... I just make sure that it's safe if it's public facing.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

david_wendelken SSCrazy Points: 2388 More actions · Answer 11

Dynamic SQL is over-used by ignorant programmers who do not know what a SQL Injection attack is, or by lazy unprofessional ones who don't care.

There can be performance penalties for using Dynamic SQL compared to parameterized statements.

That said, there is nothing wrong with using Dynamic SQL where it is needed. I love it and use it frequently.

(I also harden my code and my application design to make SQL Injection attacks harder or impossible, as the case may be.)

Ray K SSC-Dedicated Points: 31148 More actions · Answer 12

david_wendelken (3/10/2010)
Dynamic SQL is over-used by ignorant programmers who do not know what a SQL Injection attack is, or by lazy unprofessional ones who don't care.

And don't forget us former newbies from many years ago who were just learning, and didn't know any better! 😉

(Although I will admit that I'm still learning the finer points of writing decent dynamic SQL!)

+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/

michael.wiles SSC Veteran Points: 292 More actions · Answer 13

I completely agree that generating code to write code for a customized solution can be extremely benefiicial. This is particuliarly true if the database design has not been finalized and you have 60 views, 60 stored procedures and 60 datatable types that need to be maintained or updated when the database schema changes. Now updating the database schema and keeping the schema in synch with .net datatables(required for passing .net datatables to sql server where column order matters) a breeze. It also ensures that most data errors will be found at the app level before they are sent to the database.

kevin77 SSCarpal Tunnel Points: 4054 More actions · Answer 14

Nobody here has mentioned NHibernate, which is partially what the referring blog post was about. I left a comment on that blog post last month. Does anybody else here use NHibernate (or the original Java version Hibernate)?

michael.wiles SSC Veteran Points: 292 More actions · Answer 15

Ray K (3/11/2010)
david_wendelken (3/10/2010)
Dynamic SQL is over-used by ignorant programmers who do not know what a SQL Injection attack is, or by lazy unprofessional ones who don't care.
And don't forget us former newbies from many years ago who were just learning, and didn't know any better! 😉
(Although I will admit that I'm still learning the finer points of writing decent dynamic SQL!)

Newer coding technologies make using parameterized commands significantly easier(i.e with .Net). Older technologies like ADODB had them but it was a real pain to use and was extremely error proned. With ADODB, the order you added the parameters mattered and had to match exactly the order in the query, regardless of whether they were named or not. So, if your above query changed you needed to evaluate or redo your parameter variable definitions to ensure you didn't introduce a runtime error. It was for this reason that I never used parameters with ADODB.

Since .Net makes this process so seemless, you can easily create dynamically created SQL and used parameterized commands without any trouble at all really. With .Net there is no reason to not use the benefits of parameterized commands.

In other words, it has nothing to do with lazy. It has more to do with deciding to accidentally introduce a runtime error that was almost guaranteed if your order was off or risk the error at the expense of an sql injection that may never happen.