This discussion is archived
1 2 3 Previous Next 35 Replies Latest reply: Mar 4, 2013 4:22 AM by javaMan2012 Go to original post RSS
  • 15. Re: Will the real PL/SQL language standards please stand up?
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    Since you've quoted many standards (including ADA) but not a PLSQL standard ..........


    Quoting Steven Feuerstein at http://www.toadworld.com/Portals/0/stevenf/Naming%20Conventions%20and%20Coding%20Standards.pdf

    Upper-case non-application identifiers (that is, elements of the base PL/SQL language and Oracle built-ins) and lower-case application-specific elements. Lots of people disagree with me on this, including Bryn Llewellyn, PL/SQL Product Manager. He feels like my code is shouting at him. Sorry, Bryn! I like this style because it gives some dimension to the code, makes it easier to pick out my stuff as opposed to the built-in Oracle stuff. Camel notation (maxSalary) is something to be avoided in case-insensitive PL/SQL. Auto-formatters will likely destroy all your hard and careful naming work.


    Hemant K Chitale
  • 16. Re: Will the real PL/SQL language standards please stand up?
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    STEVE IS WRONG.

    Or do you think that professors and doctors in computer science, and people who designed computer languages, and 100's of 1000's of programmers, all who collectively have established today's standards, over decades of gaining knowledge and experience on how best to engineer software, are all wrong? And Feuerstein alone is correct?

    Don't be ridiculous.

    Feuerstein has nothing to backup his twisted version of PL/SQL standards. The SAME usability and readability rules apply to the human brain, IRRESPECTIVE of the programming language being read.

    If the language was very uncommon, using very different syntax rules and language structures - then one can argue that different standards to be used.

    But PL/SQL is ADA plus SQL. It is like Pascal. IT IS NOT DIFFERENT!

    So the argument that PL/SQL is such a unique and special and different language, that common naming standards and coding styles do not apply, is without any merit.

    Steve is doing the entire PL/SQL developer community a disservice, by promoting standards that flies in the face of Ada, Pascal, Java, .Net and other language standards. And so are those here that support those idiotic "standards".

     
    +<nailing my colours clearly and firmly to the mast>+
  • 17. Re: Will the real PL/SQL language standards please stand up?
    Toon.Koppelaars2 Newbie
    Currently Being Moderated
    Hear, hear. Well said.
  • 18. Re: Will the real PL/SQL language standards please stand up?
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    All I am saying is : Some people do have different opinions.
    BTW, I don't have a standard style, but do tend to use UPPER CASE at times.


    ... aah ! forget it. I've just erased the PS I was adding. No point in getting into a war of words. ...

    Hemant K Chitale

    Edited by: Hemant K Chitale on Mar 1, 2013 3:10 PM
  • 19. Re: Will the real PL/SQL language standards please stand up?
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Hemant K Chitale wrote:
    All I am saying is : Some people do have different opinions.
    Agree.

    But it is not about opinion Hermant.

    It is about the science behind how the human brain reads and processes read information. Which is why I do not accept opinions in this case. I am interested in what science and behaviour responses are used to justify, for example, writing reserved words in upper case.

    In all the communication courses I've been on (used to write technical documentation extensively in the distant past), and specifically how a programmer needs to communicate algorithms and logic and process flow in code, there always have been sound reason, science and logic, behind what was taught. Not opinion.

    Which is why I get a bit cheesed off when people start arguing with me about programming standards and presenting opinion only - and opinion that flies in the face of programming standards and coding styles developed by very knowledgeable people over many decades now.

    For example, you posted the quote "+Camel notation (maxSalary) is something to be avoided in case-insensitive PL/SQL.+".

    Camelcase is not suddenly useless because a language is case-insensitive. Camelcase is about readability. It is about the human brain's pattern recognition abilities, and how that works. This does not change when the letters and words being read on the screen is PL/SQL code and not Ada code.

    I do not mind opinion. But mere opinion is not a valid counter argument to facts and science. Which makes Feuerstein's opinion meaningless when it comes to PL/SQL standards. Standards are not opinion-based.
  • 20. Re: Will the real PL/SQL language standards please stand up?
    Another_user Explorer
    Currently Being Moderated
    Yeah, opinions may or may not be helpful here, so I won't give any. And I suspect we mostly agree, so my intention is not to debate. I understand your well laid out point that this is not the best way to format code. My only point is that regardless of the science, the history, the facts, and the experts, uppercase reserved words are simply the industry standard in PL/SQL programming. Right or wrong, this is how most every major IDE, including the one from Oracle, formats code. This is largely how many of the non-wrapped SYS packages are formatted.
  • 21. Re: Will the real PL/SQL language standards please stand up?
    6363 Guru
    Currently Being Moderated
    Another_user wrote:
    My only point is that regardless of the science, the history, the facts, and the experts, uppercase reserved words are simply the industry standard in PL/SQL programming.
    No they are not. I will agree that a lot of brain dead IDE's along with other stupid features such as editing code in the database instead of from source control, have a similar broken default to allow lazy developers who don't know enough to format their own code to to turn it all to upper case. This does not make upper case an industry standard, it makes shoddy, slapdash unreadable code an almost de-facto industry standard unfortunately.
  • 22. Re: Will the real PL/SQL language standards please stand up?
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Another_user wrote:
    My only point is that regardless of the science, the history, the facts, and the experts, uppercase reserved words are simply the industry standard in PL/SQL programming. Right or wrong, this is how most every major IDE, including the one from Oracle, formats code. This is largely how many of the non-wrapped SYS packages are formatted.
    Many (usually dating back numerous versions). Not all.

    One can clearly see that there is no single set of standards applied by Oracle to DBMS code. The XMLTYPE for example, is clearly developed by those with Java or C as a background - as the implementation use Java/C standards.

    So I dispute that reserved-words-in-upper-case is an industry standard when it comes to PL/SQL. If it were, then it would have been applied consistently by Oracle (an enforced by Oracle's PL/SQL product manager). The fact is, the "standard" is not evenly applied, many in Oracle write code that do not follow this "standard" either, and to my knowledge, nor is it supported by Oracle's PL/SQL product manager.

    It is very much a case of the emperor not wearing any clothes - and pretending that the emperor is indeed finely clothed.

    And I will keep on attacking this idiotic standard and make people look at their reasons for defending it. It is simply ridiculous that in the 2nd decade of the 21st century, standards dating back 5 decades ago, part of the mainframe era of the previous century, are still being used in a monkey-see monkey-do fashion.
  • 23. Re: Stored Procedure
    tinku981 Newbie
    Currently Being Moderated
    Hi,

    I tried and it is working (without any error)

    Hope you have created invoices table!


    SQL> CREATE OR REPLACE PROCEDURE update_invoices_credit_total(invoice_number_param VARCHAR2,
    2 credit_total_param NUMBER)
    3
    4 AS
    5 BEGIN
    6 UPDATE invoices
    7 SET credit_total = credit_total_param
    8 WHERE invoice_number = invoice_number_param;
    9 COMMIT;
    10 EXCEPTION
    11 WHEN OTHERS THEN
    12 ROLLBACK;
    13 END;
    14 /

    Procedure created

    SQL> show errors
    No errors for PROCEDURE SYSTEM.UPDATE_INVOICES_CREDIT_TOTAL

    SQL> exec update_invoices_credit_total('367447', 300);

    PL/SQL procedure successfully completed

    SQL> call update_invoices_credit_total('367447', 300);

    Method called

    SQL>
  • 24. Re: Stored Procedure
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Sandeep98191 wrote:

    I tried and it is working (without any error)
    Of course. As all errors are SUPPRESSED in your code - pretending that whatever the error is, it never happens.

    Now how can you call that a robust solution?
  • 25. Re: Stored Procedure
    tinku981 Newbie
    Currently Being Moderated
    Billy  Verreynne  wrote:
    Sandeep98191 wrote:

    I tried and it is working (without any error)
    Of course. As all errors are SUPPRESSED in your code - pretending that whatever the error is, it never happens.

    Now how can you call that a robust solution?
    Sorry did not get what you mean?

    I thought post was that while making call to procedure an error is coming and not related to what is the best way to write the code!
  • 26. Re: Will the real PL/SQL language standards please stand up?
    APC Oracle ACE
    Currently Being Moderated
    First of all, I agree that:

    - Oracle code is case-insensitive
    - lower or mixed case is easier to read
    - there are proper IDEs and text editors which support syntax highlighting.

    All of which means UPPER CASE KEYWORDS are unnecessary and abominable.

    But you can't go around calling people monkeys just because they capitalize SELECT and FROM. Every single example in the Oracle documentation uses that convention. So while it is not actually a standard it certainly feels like a standard.


    Cheers, APC
  • 27. Re: Will the real PL/SQL language standards please stand up?
    Hemant K Chitale Oracle ACE
    Currently Being Moderated
    APC,

    Thank you for restoring the balance in the Universe.

    Either Billy hasn't read Oracle documentation for some time or he has made a conscious decision not to criticize the Oracle Documentation team here.



    Hemant K Chitale
  • 28. Re: Will the real PL/SQL language standards please stand up?
    Stew Ashton Expert
    Currently Being Moderated
    Billy,

    Can you provide a link to a site that proposes "standard sensible and de-facto programming and naming standards", and that are applicable to PL/SQL?

    Thanks in advance, Stew
  • 29. Re: Will the real PL/SQL language standards please stand up?
    rp0428 Guru
    Currently Being Moderated
    >
    Every single example in the Oracle documentation uses that convention. So while it is not actually a standard it certainly feels like a standard.
    >
    And there are very valid, and historical reasons, for documentation (Oracle's, books, articles, etc) to use UPPERCASE convention for reserved words.

    Such documentation is primarily for instructional purposes. It is used to explain the definition of the language elements as well as their use.

    The documentation will typically include a 'Conventions' section that explains what typographical conventions (e.g. bold, italic) are used and when they are used.

    Oracle's documentation also includes an appendix that explains the conventions used in their syntax diagrams. Here are three relevant excerpts from the SQL Language doc.
    http://docs.oracle.com/cd/B28359_01/server.111/b28286/ap_syntx.htm#SQLRF018
    >
    A How to Read Syntax DiagramsThis appendix describes how to read syntax diagrams.

    This reference presents Oracle SQL syntax in both graphic diagrams and in text (Backus-Naur Form—BNF). This appendix contains these sections:

    •Graphic Syntax Diagrams

    •Backus-Naur Form Syntax
    >
    The Graphic Syntax link
    >
    Graphic Syntax DiagramsSyntax diagrams are drawings that illustrate valid SQL syntax. To read a diagram, trace it from left to right, in the direction shown by the arrows.

    Commands and other keywords appear in UPPERCASE inside rectangles. Type them exactly as shown in the rectangles. Parameters appear in lowercase inside ovals. Variables are used for the parameters. Punctuation, operators, delimiters, and terminators appear inside circles.
    >
    Note that the word 'uppercase' is IN uppercase. And the reader is told to 'Type them exactly as shown in the rectangles'. Right or wrong that seems pretty clear to me where a new developer might get the idea to use UPPERCASE.

    And the Backup-Naur Form link
    >
    Backus-Naur Form SyntaxEach graphic syntax diagram in this reference is followed by a link to a text description of the graphic. The text descriptions consist of a simple variant of Backus-Naur Form (BNF) that includes the following symbols and conventions:

    Symbol or Convention Meaning

    [ ] Brackets enclose optional items.

    { } Braces enclose items only one of which is required.

    | A vertical bar separates alternatives within brackets or braces.

    ... Ellipsis points show that the preceding syntactic element can be repeated.

    delimiters Delimiters other than brackets, braces, vertical bars, and ellipses must be entered as shown.

    boldface Words appearing in boldface are keywords. They must be typed as shown. (Keywords are case-sensitive in some, but not all, operating systems.) Words that are not in boldface are placeholders for which you must substitute a name or value.
    >
    The 'Keywords are case-sensitive in some, but not all' is another indicator that the reader should be vigilant.

    It can be extremely effective when learning a new language to be able to easily identify the elements of that language in the documentation and examples that are used.

    So it seems to me that for documention, such as an example query in a book or article, use of uppercase for language elements is more than justified.
    SELECT EMPNO, ENAME, JOB FROM EMP WHERE DEPTNO = 20;
    Certainly there can be no uncertainty about what the column names are that are being used. What if the doc used this instead?
    SELECT Empno, ename, job FROM EMP WHERE deptno = 20;
    Is the first colum named EMPNO? Or is it really "Empno" but the enclosing quotes were erroneously omitted? Hopefully the first.

    For PL/SQL I think it is even more useful for both the documentation, and code itself to use UPPERCASE for structural elements. For example, this from the PL/SQL Language doc
    http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/controlstructures.htm#BABCEEEI
    Example 4-6 Simple CASE Statement
    
    SQL> DECLARE
      2    grade CHAR(1);
      3  BEGIN
      4    grade := 'B';
      5  
      6    CASE grade
      7      WHEN 'A' THEN DBMS_OUTPUT.PUT_LINE('Excellent');
      8      WHEN 'B' THEN DBMS_OUTPUT.PUT_LINE('Very Good');
      9      WHEN 'C' THEN DBMS_OUTPUT.PUT_LINE('Good');
     10      WHEN 'D' THEN DBMS_OUTPUT.PUT_LINE('Fair');
     11      WHEN 'F' THEN DBMS_OUTPUT.PUT_LINE('Poor');
     12      ELSE DBMS_OUTPUT.PUT_LINE('No such grade');
     13    END CASE;
     14  END;
     15  /
    I find it extremely helpful when reviewing code to have reserved words such as DECLARE, BEGIN, END in uppercase even though technically they don't need to be. It not only matches the syntax diagrams and documentation but it helps show the structure of the content much the way that indentation does.

    And when I see CASE the first thing my eyes try to find is the END CASE and it is MUCH (oops, used uppercase!) easier to spot in uppercase.

    When there is a WHEN I want to know where the ELSE is. Hmm, let me write that last sentence again and see if it reads a easily:
    >
    When there is a when I want to know where the else is.
    >
    And when you have a case where you need a case that can have a when or if desired can have more than one when or else can even have several whens and an else or else if won't have an else.

    I hope that the last sentence was perfectly clear to anyone. Although I tend to think it might have helped just a tad if it had been written:
    >
    And when you have a case where you need a CASE that can have a WHEN or if desired can have more than one WHEN or else can even have several WHENs and an ELSE or else if won't have an ELSE.
    >
    Personally I like use of UPPERCASE in the second version much better.

    For me, in PL/SQL code in particular I like to see the reserved words, particularly code constructs (LOOP, END LOOP, etc) in uppercase.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points