TRM900@PSUVM.BITNET (Tony R. Marasco) (10/01/89)
As you know, any good programmer will indent Pascal source inside
every loop, Begin-End structure, etc. A colleague who is grading
freshman Pascal was instructed to deduct 1 letter grade for non-
indentation. However, one student submitted the following code:
BEGIN
WRITELN;
.
.
WHILE (A <> 0) DO
BEGIN
IF COUNT <> 0 THEN
BEGIN
AVG := TOTAL / COUNT;
END;
.
.
END;
Notice how the BEGIN's and END's are not indented, but the code within
is. Now, I have written programs in Pascal for several instructors and
never had points deducted for the above style (which this other person
used, also). My question is this: Is this a judgement call? I know
books I've read indent the BEGIN's and END's also. Which is correct?
I really don't think there's an exact answer to that question.
Personally, I think the book's versions are more confusing to me.
I was there when he was grading the programs & he brought the problem
to my attention. I told him there was nothing wrong IMHO, but he decided to
take 1/3 of a letter grade off for incorrect indentation.
I'd appreciate anyone's comments via e-mail on this subject...
-------
+-------------------------------------------------------------------------+
| Tony Marasco | UUCP: psuvax1!psuvm!trm900 |
| Penn State University | BITNET: trm900@psuvm.BITNET |
| Schuylkill Haven Highway | - or - |
| Schuylkill Haven, PA 17976 | trm900%psuvm.psu.edu@CUNYVM.CUNY.EDU |
| "Questions are a burden for others. Answers are a prison for oneself." |
| -- The Prisoner |
+-------------------------------------------------------------------------+TBC101@PSUVM.BITNET (Thomas B. Collins, Jr.) (10/01/89)
I think the method of indenting should be up to the student, and the instructor should only deduct points if a standard form isn't followed. In your example: In article <89273.161831TRM900@PSUVM.BITNET>, Tony R. Marasco <TRM900@PSUVM.BITNET> says: >BEGIN > WRITELN; > . > . > WHILE (A <> 0) DO > BEGIN > IF COUNT <> 0 THEN > BEGIN > AVG := TOTAL / COUNT; > END; > . > . > END; I would of taken off points for not using lowercase text (a pet peeve of mine), and also for the fact that a begin and end bracket a single statement (after the IF). Then again, this is my opinion, and if your teacher is adamant about the form you should follow, I'd say conform to their form, but revert to yours when you've finished the class. ------- Tom "Shark" Collins Since ICS is comprised of 2 people, my views tbc101@psuvm.psu.edu are the opinion of at least 50% of the company.
lihan@walt.cc.utexas.edu (Bruce Bostwick) (10/01/89)
In article <89273.185750TBC101@PSUVM.BITNET> TBC101@PSUVM.BITNET (Thomas B. Collins, Jr.) writes: >I would of taken off points for not using lowercase text (a pet peeve of >mine), and also for the fact that a begin and end bracket a single >statement (after the IF). Then again, this is my opinion, and if your >teacher is adamant about the form you should follow, I'd say conform to >their form, but revert to yours when you've finished the class. I never have liked to use uppercase -- reminds me too much of my BASIC days. I also have never included my begin's and end's in the indentation, though this is purely a stylistic point. For anyone who's interested, and those who might want to put forth a standard for this sort of thing, I use the following rules for indentation: 1) Everything that's either between begin and end or dependent on an if gets indented three spaces 2) All the stuff included in a record goes three spaces RIGHT of the start of the word 'record' and its 'end' is aligned with it 3) var, type, and const declarations all line up with the first declaration in the category, i.e.: var noid:integer; dfile:file; scrunge:record a,b,c:string[32]; end; begin statement(x,y); end. I use some others too but can't remember them offhand and don't wish to hog bandwidth trying to recall them. They seem to make the program quite easy to read, and I haven't had to make an exception yet. ======================================================================= Internet:lihan@walt.cc.utexas.edu Disclaimer: My employer doesn't MaBellNet:(512)459-1602 even know UseNet exists, let SlowNet:varies chaotically, alone that I'm on it and ex- e-mail for current value pressing opinions ... +---------------------------------------------------------------------+ (-: a.k.a. BB/CIV :-) =======================================================================
amull@Morgan.COM (Andrew P. Mullhaupt) (10/01/89)
Recently, a thread about upper case = ugly and 'how is good form for source ahieved through indenting?'. 1. Modula-2 (Pascal's younger brother) has the awful case sensitivity disease, so that keywords MUST be capitalized. 2. Modula-2 has done away with some of Pascal's begins, so a slightly different style of indenting prevails. 3. There are at least three sensible indenting conventions, and a good discussion of indenting can be found in David Gries' excellent book: 'The Science of Computer Programming'. Given these facts, do we really want to insist on one style for our students? What if they have already learned Modula-2? It's not the same as if they've been blighted by C, and forcing them to conform to an arbitrary restriction will make them think less of Pascal progrmmers. It seems to me that the philosophy of Pascal is to use what seems to be a set of restrictive rules about code as a springboard to inferences about the semantics of the code. (What you see is what it will do, sort of...). Unless one can show that one indenting practice is more powerful than another, the apllication of grades should really be left to the perception of a consistent indenting method, rather than blindly following a single given. Finally: Never insist on lower case. (I always use it, and prefer it), but there are people who cannot read lower case, due to their visual impairment. It is so trivial to convert from upper to lower case that no instructor should ever use this point for grades. Later, Andrew Mullhaupt P.S. I was a Mathematics Professor for enough years to be in sympathy with someone who wants to uniformize the homework he has to grade, but fair is fair. Anything less will lose you respect.
bkottman@wright.EDU (Brett Kottmann) (10/02/89)
in article <89273.161831TRM900@PSUVM.BITNET>, TRM900@PSUVM.BITNET (Tony R. Marasco) says:
deleted stuff
Code style is usually a judgement call.
I've had points taken off for writing code the same way as K&R did in
their C manual. (Interesting attempt by grader to justify it :) )
BEGIN/END can be taken as:
Code the same level as previous statements, enclosing code to be
further indented
Or
The delimiters for indented code (indented like the code in
between)
For my classes, either one is okay.
It's kind of like the argument for THEN on the same line as
the IF or on the next line. (Which has proponents for both styles)
IMHO the grader should give back the points, unless it was
specifically stated that BEGIN/END pairs should be indented otherwise.
Brett Kottmann
Wright State U.
=========================================================================
It's too bad we don't teach our students how to teach themselves.
=========================================================================bkottman@wright.EDU (Brett Kottmann) (10/02/89)
in article <89273.185750TBC101@PSUVM.BITNET>, TBC101@PSUVM.BITNET (Thomas B. Collins, Jr.) says: > >> IF COUNT <> 0 THEN >> BEGIN >> AVG := TOTAL / COUNT; >> END; >> . > mine), and also for the fact that a begin and end bracket a single > statement (after the IF). Then again, this is my opinion, and if your > I teach this as GOOD programming style. Especially for software engineering. An addition to the BEGIN/END bracketed code consists of just adding the new code, and not inserting a BEGIN, END, and checking for semicolons on the pre-existing code. As you said, this is largely an opinion call, but I really feel it reduces errors when new statements are added. Brett Kottmann Wright State U ======================================================================== A mistake a day helps keep arrogance away. ========================================================================
mlw@pyr.gatech.EDU (Michael Williams) (10/02/89)
Anyone who deducts points for formatting inconsistent with the preferred
method of the instructor should be forced to write FORTRAN code, where
silly obstacles such as column numbers make a difference. This is one of
the advantages of pascal. There shouldn't be a standard; it should be a
matter of personal preference. In fact, I have the following preference:
for i := 1 to 10 do begin
x := a[i];
b[i+1] := x + 10;
end;
The "begin" does not waste a line on my screen, allowing me to see more of
my program. The "end" lines up with the "if", "for", or "while" statements,
allowing quick and easy alignments of scope.
When I first saw this style, I didn't like it; however, I now prefer it.
It's a matter of choice ... do it your way, but don't force others to.
--
Michael Williams
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!mlw
ARPA: mlw@pyr.gatech.educonan@vax1.acs.udel.EDU (Robert B Carroll) (10/02/89)
In article <9253@pyr.gatech.EDU> mlw@pyr.UUCP (Michael Williams) writes: > >my program. The "end" lines up with the "if", "for", or "while" statements, >allowing quick and easy alignments of scope. >When I first saw this style, I didn't like it; however, I now prefer it. >It's a matter of choice ... do it your way, but don't force others to. >-- >Michael Williams Thats nice. There are 5 people in my group at work. We have to write code that will eventually be used by perhaps 3 other groups(about 13 more people). The total size of the program is about half a million lines of code. Each one of the five people in our group are going to indent the way we feel it should be done instead of be necessarily the same. Am i'm going to deal with debugging this crap? nahh, there shouldn't be any standard. Maybe your not talking about a 'real' world situation though. Ah well...... -- conan@vax1.acs.udel.edu OR conan@192.5.57.1 ********************************************************************** ****The Hardest Disc Golf courses are in the world are in delaware**** **********************************************************************
synful@drycas.club.cc.cmu.edu (Marc Shannon) (10/02/89)
In article <89273.185750TBC101@PSUVM.BITNET>, TBC101@PSUVM.BITNET (Thomas B. Collins, Jr.) writes: > I think the method of indenting should be up to the student, and the > instructor should only deduct points if a standard form isn't followed. > In your example: > > [ Pascal code segment intentionally left blank. :-) ] I think that it would be better to say `reasonable' form rather than standard. Suggesting a standard form makes it seem like there might be a distinction between indenting Begin...End blocks and not or even the number of spaces (or tabs!) for each level of indenting. > I would of taken off points for not using lowercase text (a pet peeve of Do you mean if the entire program is uppercase only or just in general? Many people find that it suits them to put Pascal keywords (and special predefined routines) in uppercase to separate them from the programmer-created identifiers. > mine), and also for the fact that a begin and end bracket a single > statement (after the IF). Then again, this is my opinion, and if your > teacher is adamant about the form you should follow, I'd say conform to > their form, but revert to yours when you've finished the class. Sometimes, a Begin...End statement is required after an If statement, especially when there is another If statement inside. Example: . . If TablePtr <> Nil Then Begin If TablePtr^.Name = SearchString Then Writeln('Found entry with ID #', TablePtr^.IDNum:0) End Else Writeln('ERROR: Argument has Nil value'); . . Note that because there is an `Else' clause to the first If statement, the Begin...End block is used to delineate to which If it belongs. The only reasons I can understand for deduction of points are when the code is unreadable or ambiguous and when comments are either absent, not indicative of actual function, or superfluous (how many times have you seen "I := I + 1; { increment counter I }"? :-) ). --Marc -- +-----------------------------------------------------------------------------+ | Marc Shannon Internet Address (Bitnet name) | | VAX Systems Programmer SYNFUL@DRYCAS.CLUB.CC.CMU.EDU (DRYCAS) | | Carnegie-Mellon University R602MS5U@VB.CC.CMU.EDU (CMCCVB) | | (412) 268-6290 "I mean, really, what could possibly go wrong?" | +-----------------------------------------------------------------------------+
swh@hpcupt1.HP.COM (Steve Harrold) (10/03/89)
Re: Indent style The submitted style of indentation is neither right nor wrong, as long as the style remains consistent throughout the program. In industry, with programming teams, it is important that coding styles among various members of a team be similar, so that code can be interchanged without shifting style gears. In many teams, a style is agreed to, by consensus, or company policy. Regardless of an individual's opinions about its "quality", his success as a team player will be enhanced if he adheres to it. Indeed, his performance reviews may well include this as a factor. Getting back to the student's submission, there are two lessons to be applied. First, that a consistent style is important, which he demonstrated, and second, that it has to be an agreed-to style, which he did not. Since all this borders on religious fervor, the best overall solution, is to provide a formatting tool that will translate personal styles to project/team styles. Then we can all have our cakes and eat them. And before this kicks off a "my style is best" debate, let me point out the example of the printing industry. Regardless of who writes the magazine article or book section, it gets printed in the "look and feel" layout that the editor/publisher has dictated. It works well! Let's learn! -- --------------------- Steve Harrold swh@hpda.hp.com ...hplabs!hpda!swh HPG200/11 (408) 447-5580 ---------------------
R1TMARG%AKRONVM.BITNET@cornellc.cit.cornell.edu (Tim Margush) (10/03/89)
In article <89273.161831TRM900@PSUVM.BITNET>, Tony R. Marasco <TRM900@PSUVM.BITNET> says: >BEGIN > WRITELN; > . > . > WHILE (A <> 0) DO > BEGIN > IF COUNT <> 0 THEN > BEGIN > AVG := TOTAL / COUNT; > END; > . > . > END; What about the unnecessary semi-colons? I believe these indicate a basic lack of understanding of the syntax requirements of the language. Regarding the indentation conventions and upper/lower case usage, these are simply style issues. If the instructor has definite requirements in this area, the student is required to oblige (the same holds in industry when certain documentation requirements must be followed). I personally see no problem with the style used. The indentation seems to indicate that the student understands the semantics of these statements. The semi-colon issue is another thing indeed! --------------------------------------------------------------------- Tim Margush R1TMARG@AKRONVM.BITNET Department of Mathematical Sciences R1TMARG@VM1.CC.UAKRON.EDU University Of Akron R1TMARG@AKRONVM.UAKRON.EDU Akron, OH 44325 (216) 375-7109
rang@cs.wisc.edu (Anton Rang) (10/03/89)
In article <21024@adm.BRL.MIL> R1TMARG%AKRONVM.BITNET@cornellc.cit.cornell.edu (Tim Margush) writes: >What about the unnecessary semi-colons? I believe these indicate a basic >lack of understanding of the syntax requirements of the language. No, I don't think so. Personally, I usually avoid redundant semicolons, but there is a good reason to put them there: it means that lines within a block may be independently modified. If I have some code without the extra semicolon: begin i := 1; j := 2 end and want to add another statement, k := 3, I get: begin i := 1; j := 2 k := 3 (maybe with a semicolon) end and I need to change the previous line. This is counterintuitive; I don't think that using the extra semicolons or not really makes much of a difference one way or the other. (Of course, when you're making a change, you should always look at the surrounding lines anyway :-) It makes sense to use the semicolon as a statement terminator, especially if you consider an "IF" not to be terminated when the "ELSE" comes along. The distinction between terminator and separator isn't really critical, IMHO. +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+
leonard@bucket.UUCP (Leonard Erickson) (10/03/89)
conan@vax1.acs.udel.EDU (Robert B Carroll) writes:
<Thats nice. There are 5 people in my group at work. We have to write
<code that will eventually be used by perhaps 3 other groups(about 13
<more people). The total size of the program is about half a million
<lines of code. Each one of the five people in our group are going to
<indent the way we feel it should be done instead of be necessarily
<the same. Am i'm going to deal with debugging this crap?
<nahh, there shouldn't be any standard. Maybe your not talking about
<a 'real' world situation though. Ah well......
I have to maintain that much code on my own (880k of source files last time
I checked). After wading the the previous programmer's inconsistent
formatting, I now run all the source code thru a formatting program after
set of changes. This also makes it easier when comparing old versions
to the current version. Less "noise" in the diffs.
Someday I'll have time to go thru and rewrite the last guy's *monster*
procedures into something more reasonable. Would you believe procedures
that run to 12 *pages*? And case statements where the individual cases
are:
13: {20 to 100 lines of code}
17: (another page or so}
Yech!
I guess it wasn't *too* bad for a COBOL programmer writing his first
large Pascal program... (no, I'm *not* kiidding!)
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortlins@Apple.COM (Chuck Lins) (10/03/89)
In article <10595@claris.com> drc@claris.com (Dennis Cohen) writes: >mlw@pyr.gatech.EDU (Michael Williams) writes: >> ... >>matter of personal preference. In fact, I have the following preference: > >> for i := 1 to 10 do begin >> x := a[i]; >> b[i+1] := x + 10; >> end; > >>The "begin" does not waste a line on my screen, allowing me to see more of I also prefer this style. IMHO, the BEGINs of Pascal are a syntactic extra. IHMO, I personally prefer the Modula-2 constructs where END is used to complete such statements as FOR, WHILE, etc. >The thing I really don't understand is what the fuss is about this whole >subject. From the early days of Pascal, one of the most popular "utility" >programs was the source reformatter. These reformatters are extremely I agree that the MPW tool PasMat is extremely useful. Unfortunately, it wants syntactically correct Pascal programs and so it won't format Modula-2 programs (sigh). In an educational environment, perhaps the students should work in small teams to write a formatter. -- Chuck Lins | "Exit left to funway." Apple Computer, Inc. | Internet: lins@apple.com 20525 Mariani Avenue | AppleLink: LINS Mail Stop 41-K | Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" I speak for myself and no one else.
R1TMARG%AKRONVM.BITNET@cornellc.cit.cornell.edu (Tim Margush) (10/04/89)
> No, I don't think so. Personally, I usually avoid redundant >semicolons, but there is a good reason to put them there: it means >that lines within a block may be independently modified. > If I have some code without the extra semicolon: > > begin > i := 1; > j := 2 > end > > and want to add another statement, k := 3, I get: > Here is what I get... begin i:=1; j:=2; k:=3 end and if I want to temporarily insert a debug statement: begin i:=1; j:=2 ;writeln('the value of j is',j) end Since the writeln is intended for debugging purposes, the semicolon in front helps me to spot it quickly. If I was going to modify the code permanently, I would put the semi where it belongs. There is no reason that code modification ought to be "easy!" We all know that we must take into consideration surrounding code when making changes. Adding the semi here is part of that "reasonable" task. I still believe that using the semicolon as a statement terminator is a wrong concept to teach any beginning student. It will always make the if then else structure more difficult as there is no way that you can say that x:=x+1 is a statement one place but not another! x:=x+1; if x>5 then x:=x+1; else ... If statements need terminated, and x:=x+1 is a statement (assignment), then this ought to be correct syntax... No... make the semicolon a separator as it was intended. Encourage your students to practice this until you are sure they understand the concept! I consider the NULL statement a topic for "advanced" pascal programmers. Regarding the question of how other languages do it... If you are programming in Pascal.. you ought to program in Pascal.. it should not look like a C or modula-2 program!
wayne@cs.odu.edu (C Wayne Huling) (10/04/89)
In article <21041@adm.BRL.MIL> R1TMARG%AKRONVM.BITNET@cornellc.cit.cornell.edu (Tim Margush) writes: >Since the writeln is intended for debugging purposes, the semicolon in front >helps me to spot it quickly. If I was going to modify the code permanently, >I would put the semi where it belongs. There is no reason that code >modification ought to be "easy!" We all know that we must take into >consideration surrounding code when making changes. Adding the semi here is >part of that "reasonable" task. I still believe that using the semicolon >as a statement terminator is a wrong concept to teach any beginning >student. It will always make the if then else structure more difficult >as there is no way that you can say that x:=x+1 is a statement one place >but not another! > When I learned pascal, we were taught no way to structure the code in the editor, we just were given suggestions. Of the 13 of of we all had similar ways of programming indetion and such but each person was unique. Hence, the indenting should be left up to the individual, no one can convince me that their way is better than mine, but if you want to know I will show you how I do my indenting and such. This uniqueness makes each programer's program personalized. I like to hear how other people do format it however. Wayne wayne@cs.odu.edu
wyoung@ksuvax1.cis.ksu.edu (William J. Young) (10/05/89)
In article <9253@pyr.gatech.EDU> mlw@pyr.UUCP (Michael Williams) writes: > > Anyone who deducts points for formatting inconsistent with the preferred >method of the instructor should be forced to write FORTRAN code, where >silly obstacles such as column numbers make a difference. This is one of >the advantages of pascal. There shouldn't be a standard; it should be a >matter of personal preference. In fact, I have the following preference: > ... This "personal preference" is OK for experienced programmers. But what about the student who has never written any code, or who has written only code preceeded by line numbers (small jab at unstructured BASIC :-). I have coded in FORTRAN, as well as BASIC and Pascal, and have taught Pascal for over two years. My approach was that the student should be consistent in the indentation style chosen, but I did give some pointers. Unfortunately, my experience is that nearly 50% of the students took advantage of neither my suggestions or their own consistent style (and I do not consider left justified consistent style :( ). I would like to continue this discussion, as a project I was working on about a year ago was to write a pretty printer for Pascal. Many problems with this. Everyone had another "feature" they wanted. -- Bill -- ---------------------------- Bill Young Internet: wyoung@ksuvax1.cis.ksu.edu, wyoung%ksuvax1@harris.cis.ksu.edu BITNET: wyoung@ksuvax1.bitnet, wyoung%ksuvax1.bitnet@cunyvm.cuny.edu
JZEM%MARIST.BITNET@cunyvm.cuny.edu (William J. Joel) (10/05/89)
I've been listening to this discussion for about a week and I think I can boil down the reasons for good indenting to one concept: Source code should be readable! What this means is that the structures inhearant (sp?) in the code should be readily apparent. One should not need to work through the code to figure out what's there. Techniques to improve readability include indenting as well as comments, line spacing, breaking up of variable declaerations to create variable tables, etc. The point for students is not to force them to learn a single method of indenting but to make sure that they learn how to make their source code readable. +--------------------------------------------------------------------------+ + The proofs are easy. It's the theorems that are hard! + +--------------------------------------------------------------------------+ Bill Joel jzem@marist.bitnet