📄 oracle pl-sql programming, 2nd edition chapter 3_ effective coding style.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0057)http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html -->
<HTML><HEAD><TITLE>Oracle PL/SQL Programming, 2nd Edition: Chapter 3. Effective Coding Style</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY text=#000000 vLink=#0000cc link=#990000 bgColor=#ffffff>
<TABLE cellSpacing=0 cellPadding=0 width="90%" border=0>
<TBODY>
<TR>
<TD colSpan=2><IMG height=37 alt="Search the Catalog" isMap
src="Oracle PL-SQL Programming, 2nd Edition Chapter 3_ Effective Coding Style_files/catalog_header_buttons.gif"
width=515 align=bottom useMap=#catalog_header_buttons border=0> <MAP
name=catalog_header_buttons><AREA shape=RECT coords=407,17,512,32
href="http://www.oreilly.com/catalog/search.html"><AREA shape=RECT
coords=431,3,512,18
href="http://www.oreilly.com/catalog/prdindex.html"></MAP></TD></TR>
<TR>
<TD vAlign=top width="25%"><A
href="http://www.oreilly.com/catalog/oraclep2/"><IMG
alt="Oracle PL/SQL Programming, 2nd Edition" hspace=10
src="Oracle PL-SQL Programming, 2nd Edition Chapter 3_ Effective Coding Style_files/oraclep2.s.gif"
align=left vspace=10 border=0 valign="top"> </A></TD>
<TD vAlign=top height=105><BR>
<H2>Oracle PL/SQL Programming, 2nd Edition</H2><FONT size=-1>By Steven
Feuerstein with Bill Pribyl<BR>2nd Edition September
1997<BR>1-56592-335-9, Order Number: 3359<BR>1028 pages, $46.95, Includes
diskette </FONT></TD></TR></TBODY></TABLE>
<HR noShade SIZE=1>
<!--sample chapter begins -->
<BLOCKQUOTE>
<H2 class=ChapterTitle>Chapter 3. <BR><A name=17354></A>Effective Coding
Style</H2>
<TABLE>
<TBODY>
<TR>
<TD><B class=|ChapterContentsStart>In this chapter:</B> <BR><A
class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#28739">Fundamentals
of Effective Layout</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#64385">Formatting
SQL Statements</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#61382">Formatting
Control Structures</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#65283">Formatting
PL/SQL Blocks</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#37208">Formatting
Packages</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#94685">Using
Comments Effectively</A> <BR><A class=XRef
href="http://www.oreilly.com/catalog/oraclep2/chapter/ch03.html#60935">Documenting
the Entire Package</A> <BR></TD></TR></TBODY></TABLE>
<P class=BodyStart>You can learn everything about a programming language--its
syntax, high-performance tips, and advanced features--and still write programs
that are virtually unreadable, hard to maintain, and devilishly difficult to
debug--even by you, the author. You can be very smart and very clever, and yet
develop applications that obscure your talent and accomplishments.</P>
<P class=Body>This chapter addresses the "look-and-feel" of your code--the
aesthetic aspect of programming. I am sure that you have all experienced the
pleasure of reading well-structured and well-formatted code. You have also
probably experienced a pang of jealousy at that programmer's style and effort,
wondering where she or he found the time to do it right. Developers always
experience a feeling of intense pride and satisfaction from carefully and
artfully designing the visual layout of their code. Yet few of us take the
time to develop a style and use it consistently in our work.</P>
<P class=Body>Of course, the impact of a coding style goes well beyond the
personal satisfaction of any individual. A consistent, predictable approach to
building programs makes it easier to debug and maintain that code. If everyone
takes her own approach to structuring, documenting, and naming her code, every
program becomes its own little pool of quicksand. It is virtually impossible
for another person to put in a foot and test the water (find the source of a
problem, analyze dependencies, etc.) without being pulled under.</P>
<P class=BodyKeep>I discuss the elements of an effective coding style in the
PL/SQL language at this juncture, before we get to any code, for two
reasons:</P>
<UL>
<LI class=ListBullet>To drive home the point that if you are going to adopt
a coding style which will improve the readability and maintainability of
your application, you need to do it at the beginning of your project.
Programming style involves an attention to detail that can be built only
during the construction process. You are not going to go back into existing
code and modify the indentation, case, and documentation format after the
project is done.
<P></P>
<LI class=ListBullet>To provide an explanation for the format and style
which I employ throughout the book. While I can't promise that every line of
code in the book will follow all of the guidelines in this chapter, I hope
that you will perceive a consistent style that is easy on the eye and
helpful in aiding comprehension.
<P></P></LI></UL>
<P class=Body>Views on effective coding style are often religious in nature
(similar to programmers' ideas on the use of GOTO)--that is, based largely on
faith instead of rationality. I don't expect you to agree with everything in
this chapter (actually, in a number of places I suggest several alternatives).
Such unanimity is unrealistic and unnecessary. Rather, I hope that this
chapter gets you thinking about the style in your own programming.</P>
<H2 class=HeadA><A name=28739></A>Fundamentals of Effective Layout</H2>
<P class=BodyKeep>There is really just one fundamental objective of code
layout:</P>
<BLOCKQUOTE class=ListSimple><EM class=Emphasis>Reveal and reinforce the
logical structure of your program</EM>.</BLOCKQUOTE>
<P class=Body>You could come up with ways of writing your code that are very
pleasing to the eye, but doing so is less important than choosing a format
that shows the structure and intent of the program.</P>
<P class=Body>It is easy to address the topic of effective code layout for
PL/SQL because it is such a well structured language. It benefits greatly from
Ada's block structure approach. Each control construct, such as IF and LOOP,
has its own terminator keyword, such as END IF and END LOOP. Each logical
block of code has an explicit beginning statement and an associated ending
statement. This consistent and natural block style lends itself easily and
naturally to standards for indentation and whitespace, which further expose
the structure of the code.</P>
<H3 class=HeadB>Revealing Logical Structure with Indentation</H3>
<P class=Body>Indentation is one of the most common and effective techniques
used to display a program's logic via format. As illustrated in the following
examples, programs that are indented are easier to read than those that are
not indented, although programs that use excessive indentation are not much
more readable than unindented programs. Here is an unindented IF
statement:</P><PRE><CODE class=Code>IF to_number(the_value) > 22</CODE>
<CODE class=Code>THEN</CODE>
<CODE class=Code>IF max_totals = 0</CODE>
<CODE class=Code>THEN</CODE>
<CODE class=Code>calc_totals;</CODE>
<CODE class=Code>ELSE</CODE>
<CODE class=Code>WHILE more_data</CODE>
<CODE class=Code>LOOP</CODE>
<CODE class=Code>analyze_results;</CODE>
<CODE class=Code>END LOOP;</CODE>
<CODE class=Code>END IF;</CODE>
<CODE class=Code>END IF;</CODE>
</PRE>
<P class=Body>The lack of indentation in this example makes it very difficult
to pick out the statements that go with each clause in the IF statement. Some
developers, unfortunately, go to the opposite extreme and use six or more
spaces for indentation. (This usually occurs by relying on the tab key, which
offers "logical" indentation--a tab can be equivalent to three spaces in one
editor and eight in another. I suggest avoiding the use of tabs
altogether.)</P>
<P class=Body>I have found that a three-space indentation not only adequately
reveals the logical structure of the code but also keeps the statements close
enough together to read comfortably. And, with deeply nested structures, you
won't run off the right margin as quickly! Here is the three-space indented
version of the previous nested IF statement:</P><PRE><CODE class=CodeIndent>IF to_number(the_value) > 22 </CODE>
<CODE class=CodeIndent>THEN </CODE>
<CODE class=CodeIndent> IF max_totals = 0</CODE>
<CODE class=CodeIndent> THEN</CODE>
<CODE class=CodeIndent> calc_totals;</CODE>
<CODE class=CodeIndent> ELSE</CODE>
<CODE class=CodeIndent> WHILE more_data</CODE>
<CODE class=CodeIndent> LOOP</CODE>
<CODE class=CodeIndent> analyze_results;</CODE>
<CODE class=CodeIndent> END LOOP;</CODE>
<CODE class=CodeIndent> END IF;</CODE>
<CODE class=CodeIndent>END IF;</CODE>
</PRE>
<P class=Body>The rest of this chapter presents specific techniques that I
have found to be essential in writing attractive, readable code that reveals
the logic of my programs.</P>
<H3 class=HeadB>Using Case to Aid Readability</H3>
<P class=Body>PL/SQL code is made up of many different components: variables,
form items, report fields, procedures, functions, loops, declarations, control
elements, etc. But they break down roughly into two types of text: reserved
words and application-specific names or identifiers. </P>
<P class=Body>Reserved words are those names of language elements that are
reserved by PL/SQL and have a special meaning for the compiler. Some examples
of reserved words in PL/SQL are:</P><PRE><CODE class=CodeIndent>WHILE</CODE>
<CODE class=CodeIndent>IF</CODE>
<CODE class=CodeIndent>BEGIN</CODE>
<CODE class=CodeIndent>TO_CHAR</CODE>
</PRE>
<P class=Body>Application-specific identifiers are the names that you, the
programmer, give to data and program structures that are specific to your
application and that vary from system to system. </P>
<P class=Body>The compiler treats these two kinds of text very differently.
You can improve the readability of your code greatly by reflecting this
difference in the way the text is displayed. Many developers make no
distinction between reserved words and application-specific identifiers.
Consider the following lines of code:</P><PRE><CODE class=CodeIndent>if to_number(the_value)>22 and num1 between lval and hval </CODE>
<CODE class=CodeIndent>then </CODE>
<CODE class=CodeIndent> newval := 100; </CODE>
<CODE class=CodeIndent>elsif to_number(the_value) < 1 </CODE>
<CODE class=CodeIndent>then </CODE>
<CODE class=CodeIndent> calc_tots(to_date('12-jan-95')); </CODE>
<CODE class=CodeIndent>else </CODE>
<CODE class=CodeIndent> clear_vals; </CODE>
<CODE class=CodeIndent>end if;</CODE>
</PRE>
<P class=Body>While the use of indentation makes it easier to follow the
logical flow of the IF statement, all the words in the statements tend to
blend together. It is difficult to separate the reserved words and the
application identifiers in this code. Changing entirely to uppercase also will
not improve matters. Indiscriminate, albeit consistent, use of upper- or
lowercase for your code reduces its readability. The distinction between
reserved words and application-specific identifiers is ignored in the
formatting. This translates into a loss of information and comprehension for a
developer. </P>
<H3 class=HeadB>The UPPER-lower Style</H3>
<P class=Body>You can easily solve this problem by adopting a guideline for
using a mix of upper- and lowercase to your code. I have recoded my previous
example below, this time using the UPPER-lower style: all reserved words are
written in UPPERCASE and all application names are kept in lowercase:</P><PRE><CODE class=CodeIndent>IF to_number(the_value) > 22 AND </CODE>
<CODE class=CodeIndent> num1 BETWEEN lval AND hval </CODE>
<CODE class=CodeIndent>THEN </CODE>
<CODE class=CodeIndent> newval := 100;</CODE>
<CODE class=CodeIndent>ELSIF TO_NUMBER (the_value) < 1</CODE>
<CODE class=CodeIndent>THEN </CODE>
<CODE class=CodeIndent> calc_tots (TO_DATE ('12-jan-95'));</CODE>
<CODE class=CodeIndent>ELSE </CODE>
<CODE class=CodeIndent> clear_vals;</CODE>
<CODE class=CodeIndent>END IF;</CODE>
</PRE>
<P class=Body>Using a mixture of upper- and lowercase words increases the
readability of the code by giving a sense of dimension to the code. The eye
can more easily cruise over the text and pick the different syntactical
elements of each statement. The uppercase words act as signposts directing the
activity in the code. You can focus quickly on the lowercase words for the
application-specific content. Consistent use of this method makes the program
listings more attractive and accessible at a glance. </P>
<H3 class=HeadB>Formatting Single Statements</H3>
<P class=Body>Most of your code consists of individual statements, such as
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -