210 likes | 402 Views
The Power of Names. Steven Feuerstein steven.feuerstein@software.dell.com PL/SQL Evangelist, Dell. What's In a Name?. A name is an abstraction , a symbol that is associated with an underlying set of data.
E N D
The Power of Names Steven Feuersteinsteven.feuerstein@software.dell.comPL/SQL Evangelist, Dell
What's In a Name? • A name is an abstraction, a symbol that is associated with an underlying set of data. • A common concept in history is: knowing the "true name"of something or someone gives one power over that thing. • Le Guin'sEarthsea cycle a classic example • Let's not forget about Rumplestiltskin. • And if you know God's true name…wow! • Names exist in a hierarchy of abstraction. • Human -> Woman -> Mother -> Joan Feuerstein
What's in a brain? • Humans constantly seek models to describe how the brain works. • Most have failed dismally. Where art thou, AI? • Most would agree that the brain identifies and stores data, which can be referenced by name. • Seems fairly clear that our brain is a big pattern analysis engine, sorting through all the data our senses provide. • Build plans of action based on those patterns. • One interesting consequence: stereotyping/prejudice unavoidable feature of "being human"? • Check out: numenta.org and On Intelligence.
Pattern Analysis and Abstraction • Or to bring it back to our favorite species…. Everyone knows you're a person
Names in Software • Names are crucial to human efforts to transform our world to make it more convenient and more comfortable. • But what do they do for software? • Names are used in software in two key ways…. • 1. Hide information: avoid information overload! • 2. Improve maintainability: make it easier to read and understand code.
Hide Information • Information hiding: a key principle of software generally and object orientation in particular. • Human brains can handle only so much data. • We live in an age of information overload (internet, 24 hour TV, etc.). • This is certainly true of complex software. • The closest humans come to "world creators." • So we hide details that are not needed at this moment behind a name.
Improve Maintainability of Code • Arguably the most important (and most neglected) aspect of software. • Factors in maintainability include: • Self-documentation: comments are bad. :-) • Single point of definition: repetitionis bad. • Ease (and associated low cost) of change over time: spaghetti code is bad. • Let's take a look at features of PL/SQL that relate to names.
Where Names Are Found in PL/SQL • Where are they not found? • Software without names is, well, blobby. • Tables, views, columns • Program units and their subprograms • Types…and subtypes • Variables, constants and cursors • Labels for "unnamed" sections of code
Guidelines for An Excellent PL/SQL Name • Has no more than 30 characters. Bummer! • And finds a nice balance between length and clarity • Does not rely on CamelNotation. • Don't fight case insensitivity of SQL-PL/SQL! • Reflects the information hidden behind the name. • A misleading name makes reading code extremely difficult. • Standardize the structure of the name. • Prefixes, suffixes, singular vs. plural get_the_name_right.sql
Program Units and Names • The starting point (leaving aside tables and views) for all PL/SQL developers. • Start with package names, then subprogram names, then nested subprogram names. • Package names: define an area of functionality, into which are collected multiple procedures and functions. • Subprogram names: procs do things, functions return things. Don't put "get" in function name!
Nested Subprograms "extreme" modularization -> high readability • You can declare a procedure or function in any declaration section. • An anonymous block • Another procedure or function • Nested subprograms offer tremendous power to improve readability through information hiding. "table of contents" for subprogram
Types and Subtypes • Oracle defines lots of "generic" types for us to use (NUMBER, VARCHAR2, DBMS_SQL.NUMBER_TABLE, etc.). • We can also create our own types, as well as the simple but powerful SUBTYPE. • Declare types in package specs so they can be re-used easily. • Subtypes give application-specific names for commonly-used declaration types. plsql_limits.pks string_tracker3.*
About SUBTYPEs • You can't always use %TYPE or %ROWTYPE in your declaration. • You can, however, always define a "subtype" or subset of an existing type with the SUBTYPE statement. SUBTYPE benefits: • Avoid exposing and repeating constraints. • Give application-specific names to types. Critical when working with complex structures like collections of records, and nested collections. • Apply constraints, such as numeric ranges, to the variable declared with the subtype.
Applying SUBTYPEs • Two key scenarios: • Whenever you are about to write a VARCHAR2(N) or other constrained declaration, define a subtype instead, preferably in a package specification. • Instead of writing a comment explaining a declaration, put the explanation into a subtype. DECLARE l_full_name VARCHAR2(100); l_big_string VARCHAR2(32767); Instead of this: Writethis: DECLARE l_full_nameemployees_rp.full_name_t; l_big_string plsql_limits.maxvarchar2; fullname.pks plsql_limits.pks string_tracker3.*
Variables, Constants and Cursors • As with program units, make sure your names reflect the content/usage of your variable. • Use constants to hide literal values, providing a single point of definition. • You can also declare a cursor in a package specification (a named query, in essence). • But watch out! The cursor will persist in your session - you must close it explicitly when done. hardcoding.sql no_more_hardcoding.sql pkgcur.pkg
Labels for "Unnamed" Code Sections • Nested blocks are "anonymous". • Loops are "anonymous." • But you can give them names with labels! • But I recommend that you make them nested subprograms instead. • Use Toad's Refactoring tool to make sure you "do it right." BEGIN <<per_month_report>> FOR indx IN 1 .. 12 LOOP ... END LOOP per_month_report; <<close_orders>> DECLARE l_new_local_var NUMBER := 100; BEGIN ... END close_orders;
The Power of Names • Names contain an enormous amount of explanatory and manipulative power. • With great power, comes great responsibility. • Thanks, Spiderman! • So first maximize opportunities to replace complexity with a name. • Next, choose your names with care. • The result? Sparkling clear software that will be given the name: "Excellent Stuff"
Visit and Use… • A portal for Toad users specifically and Oracle technologists generally. • OK, and not just Oracle! • An overload of information (blogs, whitepapers, forums, utilities, etc.) carefully hidden behind lots of names. • PL/SQL Obsession: toadworld.com/SF, my cyberhome for all things PL/SQL!
Other Resources for PL/SQL Developers www.plsqlchallenge.comDaily PL/SQL quiz, weekly SQL, APEX and logic quizzes. Prizes! www.plsqlchannel.com 27+ hours of detailed video training on Oracle PL/SQL www.stevenfeuerstein.com Sign up for monthly PL/SQL newsletter