I split g_ variables into

a_ for package variables
o_ for package body variables

because I find the difference very significant.

(I seldom use a_ variables ... - I'm more and more using get/set procedures and functions)

Well, obviously the first character won't make much difference.

As an alternative I find this the most intuitive choice. I know it's very personal. But if I see o_ I immediately know it's a package body. The O is singing at me: 'Boooddyyy'.


But this is the answer:

p A ckage
package b O dy

I misgrowned with b_ as cursor parameters from a standard I had to follow in previous Jobs '(I'm hired by Oracle Netherlands for their Health Insurance Application eZorg).

I suppose they wanted to distinct between procedure parameters (p_) and cursor parameters (b_ from bind I suppose).

So no b_ for me.

I read all about binds on your site.
I know (we all do, don't we...) that in pl/sql binding is implicit (not talking about -wrongly implemented- dynamic stuff here - execute immediate followed by literals...etc.)


I had to change to b_ because of Oracle Netherlands!!


But it isn't too bad. Let's proceed on this tasty topic.
Let's give some small, concise ( ;) )examples to show it's use (oh, and it's also an hypothetical one).
The changes might look subtle, non-relevant. However, I think that they're not.

What follows now are four procedures. Pick out the best:

1.
create or replace procedure without_b_1
(p_name_selection in varchar2)
is
cursor c_obj
is
select object_name
from user_objects
where object_name like p_name_selection
;
begin
for r_obj in c_obj
loop
dbms_output.put_line (r_obj.object_name);
end loop;
end without_b_1;

2.
create or replace procedure without_b_2
(p_name_selection in varchar2)
is
cursor c_obj (p_name_selection in varchar2)
is
select object_name
from user_objects
where object_name like p_name_selection
;
begin
for r_obj in c_obj (p_name_selection => p_name_selection)
loop
dbms_output.put_line (r_obj.object_name);
end loop;
end without_b_2;

3.
create or replace procedure without_b_3
(p_name_selection in varchar2)
is
cursor c_obj (p_name_selection in varchar2)
is
select object_name
from user_objects
where object_name like c_obj.p_name_selection
;
begin
for r_obj in c_obj (p_name_selection => without_b_3.p_name_selection)
loop
dbms_output.put_line (r_obj.object_name);
end loop;
end without_b_3;


4.
create or replace procedure with_b_4
(p_name_selection in varchar2)
is
cursor c_obj (b_name_selection in varchar2)
is
select object_name
from user_objects
where object_name like b_name_selection
;
begin
for r_obj in c_obj (b_name_selection => p_name_selection)
loop
dbms_output.put_line (r_obj.object_name);
end loop;
end with_b_4;
/

The fourth is my personal favorite NOW (might change). The third, well, on arguments maybe second-best, but feels very unnatural. I am sure most people have to take a second look on that one ;)
The second is obscure. Very prone to errors. Scoping issues here. Happens often with package/package body variables AND local variables in procedures (ran into some in real life). The first is ok, but as a rule (of thumb ;) ) I prefer passing data to show input/output - very important! This applies to cursors as well (although parameters are always 'in' parameters)

I didn't mention another alternative, namely changing the NAME completely. It's big enough now.

I didn't invent it, I accustomed to this standard. I had to even if I didn't like it, but sometimes you don't like something first, and after a while you start seeing the advantages. Before b_, I personally used cp_ (cursorparameter), not bad either -even better maybe-.

(I don't use (+) anymore - it took a while but I think it's ugly to use (+) nowadays, I can't read code without parameternaming (=>), etc. ).

Or you just get used to it and stick with it even without seeing advantages.