Naming Conventions and Coding Standards, the Feuerstein Way

I am often asked about the naming conventions and coding standards that I use. My answer is usually a combination of muttering and vague statements and hand-waving.

That's because I have a confession: I don't have a single naming conventions and coding standards document that I use. Why not? Because I am a software developer! That is, I feel (well, I am) very busy, overwhelmed by deadlines. I don't feel like I have the time to stop and write down the few rules that I might actually follow more of less consistently. And it seems that a part of me is somewhat resistant to being accountable to a standard. Sound familiar?

Sigh...unfortunately (no, make that very fortunately), lots of other PL/SQL developers look to me for advice about how to "do things right." Ah, the pressure, the pressure!

Ah, the hypocrisy. That's what it really comes down to: I am a big hypocrite. I routinely violate just about every best practice I push on others. I sound high and mighty, but when I write code, I feel the same pull to do the quick and dirty.

So I've decided to take a few moments out of my various plane rides (I am now - when I started this document, anyway - flying from Manchester, UK, to Sweden to do a presentation to the Stockholm OUG, then a couple of days of customer visits in Stockholm and Milan, then two days of training for Oracle in Helsinki) to jot down what have become my de facto coding standards.

You see, I do have standards, and I even follow them, more or less. I just didn't want to take the time to write them down.

So that's what (finally) you'll find here. It's a combination of the naming conventions I follow, certain naming conventions with which I disagree, and a variety of other suggestions. I hope you find it useful. I'm not going to make much of an effort to justify my approach or explain away the inconsistencies. I'll just show you what I do and you can decide for yourself if you'd like to use my path as a model for your own journey.

I also hereby declare this to be a work in progress. So...

1. If you have disagreements with my approach, let me know. Perhaps I will agree with you, and change my document (you will get the credit).

2. If you have a suggestion for something to add to the document, send it to me. If I like it, I will put it into the document (and give you credit).

3. If you would like to offer your own set of naming conventions and coding standards to the world of PL/SQL developers, I will add it to the webpage (after you send it to me).

The URL for my standards document is:

www.ToadWorld.com/SF/standards

Why can't Dick Cheney just sink back into his "undisclosed location"?

How strange. When Dick Cheney was the Vice President and, many argue, the main force behind the Bush Administration's policies, he was largely invisible, holed up in an "undisclosed location" and acting is an un-democractic a fashion as seemed possible.

Then his party loses the election, in large part precisely because his policies had wrecked more than one country in the last eight years, including ours.

You'd think he'd show a little humility in the face of this rejection, but no.

Instead, he seems to have taken it upon himself to hit the airwaves and share his grim, foreboding, scolding, destructive perspectives on the Obama Administration with the world.

Please, Dick, stop being a dick. Just shut up and go back to reaping the many financial rewards of steering billions in government contracts to companies in which you have a stake or some really good friends. Surely that should be enough for the closest thing to a Darth Vadur we have in this country today.

New blog on Quest Code Tester

As you may know, besides writing about and playing with PL/SQL, I have helped create an automated testing tool for PL/SQL code name Quest Code Tester for Oracle. If you have any intention of methodically and repeatedly testing the code you write, Code Tester is without doubt the best option you have for doing this, since it generates almost all of your test code. Click here for more information on the product.

The point of this entry, however, is to make sure you are aware of a new blog at ToadWorld.com focusing specifically on the topic of automated testing of Oracle code named "Real Automated Code Testing for Oracle." Here's the URL:

http://toadworld.com/Community/Blogs/tabid/67/BlogID/32/Default.aspx

I co-author this blog with Finn Ellebaek Nielsen, a Danish consultant who has been working with Oracle technology for a long time and is one of the most knowledgeable and advanced users of Code Tester I have run across to date.

You will find at this blog my introductory entry announcing the blog, plus Finn's first contribution. I hope you like it. Please leave a comment!

Regards, Steven

Advice for dealing with ridiculous interview questions

I received an email last week with this question: "What is the maximum number of triggers that can be defined on a single table?"

My answer was: "Heck if I know. Check the Oracle documentation."

To which he replied: "Actually Oracle documentation does not mention anything about this. But this a favorite question asked during interviews for PL/SQL jobs in India."

A favorite interview question? How absurd! When I interview a person for a job as a PL/SQL developer (which I admit I have not done all that often). I am much more interested in:

Problem solving skills (MOST IMPORTANT): Can you think logically? If you are not well versed in symbolic logic (whether or not you know it as such), then it will be very difficult to solve your programming puzzles, debug your code, and understand other people's code.

Language familiarity (SECOND MOST IMPORTANT): Do you know about and have experience with critical, non-beginner features of the PL/SQL language, such as collections, FORALL, BULK COLLECT, AUTHID, autonomous transactions, etc.?

Awareness of limitations like the maximum number of triggers doesn't play any role in writing high quality code. In fact, one might argue that a brain filled with such arbitrary and irrelevant data is less likely to have a solid grasp of fundamentals and principles.

But if you really want to know the answer, the best way to check/prove the limit on the number of triggers you can define on a table is to test it with code (documentation can always be wrong, but the code is...the code...the "reality" within this particular chunk of cyberspace). Here's a script you can use to do just that:

SET SERVEROUTPUT ON

CREATE TABLE limits_table (n NUMBER)
/

DECLARE
  n   PLS_INTEGER := 1;
BEGIN
  LOOP
     EXECUTE IMMEDIATE 'create or replace trigger limits_table'
                     || n ||
                     ' before insert on limits_table for each row begin null; end;';
     DBMS_OUTPUT.put_line ('Created ' || n || ' triggers!');
     n := n + 1;
  END LOOP;
END;
/

SELECT COUNT ( * )
 FROM user_triggers
WHERE trigger_name LIKE 'LIMITS_TABLE%'
/

BEGIN
  FOR rec IN (SELECT *
                FROM user_triggers
               WHERE trigger_name LIKE 'LIMITS_TABLE%')
  LOOP
     EXECUTE IMMEDIATE 'drop trigger ' || rec.trigger_name;
  END LOOP;
END;
/

The result on Oracle Database 11g Release 1 was interesting: I ran this script while flying from Chicago down to Florida for Collaborate09. I started this script and many minutes later, I had to turn off the laptop since we were landing. By that time, over 5000 triggers had been created on the same table. Maybe I will run this later and let it run overnight, but really what's the point? No one is ever going to create that many triggers on a single table. Perhaps there is a lower, hard limit like 12 on Oracle Database 10g or earlier versions. Why don't you run this script on your database and let me know what you get?

To conclude, I suggest that if your interviewer asks you silly questions like this one, you should answer as follows:

"Why do you think it matters if I know this information? How will it help me be more successful on your team? And how do you know you've even got the right answer? Let's build a script to prove that the answer is right!"

Then whip out your laptop, throw together a script and show what a good problem solver you are. I guarantee you will have a much better shot at your job with this kind of answer.