declare
    type t_steps is table of varchar2(100) index by pls_integer;
    l_steps t_steps := new t_steps(
        'think',
        'outline','draft','test',
        'refactor','edit','test', 
        'review','edit','test',
        '...');
begin
    for i in indices of l_steps loop
        dbms_output.put_line(l_steps(i));
    end loop;
end;
/

Once you have started to absorb the fact that there are many ways to accomplish a given programming task, you should find yourself asking questions like the following. What is the best way to do this? Are there rules and standards for writing code properly? Is the fact that the code works now any sort of guarantee that it will keep working in the future? Will future developers be able to understand the nuances that make this code function properly? Will changes in the data landscape make this solution into a future performance problem?

One of my favorite discussions on the subject of coding standards can be found on Oracle’s Ask Tom site. If the link to the archive changes, do a search for ’10 Commandments’ and you should be able to find it easily…

The 10 (Oracle Development) Commandments

As you work your way through the discussion you will realize that group consensus is nowhere to be found in the development community… In reading this I felt a need to contribute my own personal viewpoint….these thought were true in 2005 and they are completely relevant today. While the reply to my comment agrees that it is good advice for the expert, there is disagreement over whether these guidelines can help a beginner. I feel that the approach of ‘responsible authorship’ can be usefule for anyone, from the novice to the seasoned expert. Here is the complete text of my reply to the posting:

Writing Quality Code: Following commandments or responsibly authoring it

Anthony Harper, December 11, 2005 – 9:48 pm UTC

These ‘commandments’ seem to be actually too specific, in so doing they may miss the mark if the purpose is to help the organization raise awareness about writing better code. Since most of the followup to this list ended up as a discussion of the merits of comments and an interpretation of a ‘school’ of thought perhaps these ‘commandments’ did fail to raise awareness of how to write good, maintainable code for the current requirements and for future programmers to maintain.
In thinking about this issue to help the organization that I am working at currently (and the future developers at that company) I always return to that old slogan ‘THINK’…..and my interpretation of it:

Think about how the code should be written to fulfill the business requirements you have been given.
Write the code to fulfill your design.
Review what you’ve written.
Refactor what you’ve written.
Review the code to see if it actually functions as you expected it to.
Repeat the process from the beginning, using your first attempt as a draft.

This could also be simplified as the following:

Write code that clearly illustrates the business process.
Review and refactor the code until it actually performs as expected.
Review, revise and refactor the code until it is clear enough to have another developer understand it without additional verbal explanation.

Too often programmers dont take the time to review their own code from the top to the bottom. By the time you have finished a particular piece of code you will have a new perspective from which to review it. This new perspective in turn will help you to refactor the code to make it more clear and more reusable.

If we take the time to ‘author’ the code, we take on a responsibility to review, revise, refactor and edit the code. This time is significantly less than the amount of time it will take a future developer to rewrite the code in order to understand it for the purposes of making changes. If we take the time to review and revise the code when first writing it, we will have added comments, structure and explanations as needed to let the text ‘speak for itself’, or else we couldn’t quite follow it during review.

If you are extremely dedicated to the ‘Profession’ of writing quality code: review, revise and refactor the code again until it is clear enough for a manager (ie, non programmer) to understand it without further ado. Part of the beauty of Oracle SQL and Oracle PL/SQL is the fact that it is written in clear English. This can be leveraged to make the code comprehensible to a non technical audience….if you can do this then you can ‘kiss’ the code goodbye, and leave it to fulfill its purpose until someone needs to revisit it again when its original purposes have changed.

I’m not sure we need to have ‘commandments’ that must be dogmatically adhered to, or ‘schools of thought’ (ie XP) that use a currently popular style or metaphor to drive our development processes. I am sure that we all need to take the extra time to ‘author’ the code so that it is something to be proud of, and so that it is something that could serve as a textbook example of the business process that the code has been written to carry out. The ‘ROI’ on this extra editing and review time up front will always outweigh the costs of future maintenance.

Another successful strategy is to remind developers to write code that will be understandable and clear when debugging at 6:30 pm on Friday when there is a production problem. If the code is not clear, if it is not clearly structured and broken into unit testable components, you will not get out of the office until 9 pm. When the heat is on and you are stepping through the code, you will thank yourself and your predecessors for taking the time to make the code clear and easy to understand.

PS. I did review this letter three times and I am sure I have missed something and it will not be entirely clear to everyone. Please help to make it a better review with your feedback.

https://asktom.oracle.com/pls/apex/asktom.search?tag=the-10-oracle-development-commandments

Best Regards,

Anthony Harper

declare
    cursor c is
    with base (publish_ts, publish_type) as
    (
        values 
            (cast(date '2023-05-20' as timestamp),'reprint'), 
            (cast(date '2005-12-11' as timestamp),'original'),
            (cast(date '3333-03-03' as timestamp),'expiry')
    ), pivoted as
    (
        select original, reprint, expiry, (reprint - original) year to month as how_long
        from 
            base
            pivot (
                max(publish_ts) for publish_type in (
                    'reprint' as reprint,
                    'original' as original,
                    'expiry' as expiry
                )
            )
    )
    select 
        to_char(original,'fmMonth DD, YYYY') as first_published, 
        to_char(reprint,'fmMonth DD, YYYY') as reprinted,
        extract(year from how_long) as years_later,
        case 
            when reprint < expiry then 'still valid' 
            else 'outdated concept' end 
        as validity
    from pivoted;

    r c%rowtype;
    lf constant varchar2(1) := chr(10);
begin

    open c;
    fetch c into r;
    close c;
    dbms_output.put_line(
        'First published ' || r.first_published || lf
        || 'Reprinted ' || r.reprinted || lf
        || r.years_later || ' years later and ' || r.validity);
    dbms_output.put_line('Some things are timeless');
end;
/