Text preview for : 19770705_Final_Draft_of_Programming_Conventions.pdf part of xerox 19770705 Final Draft of Programming Conventions xerox sdd memos_1977 19770705_Final_Draft_of_Programming_Conventions.pdf



Back to : 19770705_Final_Draft_of_P | Home

liller-Office Memorandum

To Wendell Shultz. David Liddl.e Date July 5. 1977


From Charles Irby location Palo Alto


Subject Final Draft of Programming Conventions Organization SDD/Sd
(hopefully)
XIROX SDD AROHIVES
XEROX I have read and understood
Pages_________ To ___________
Reviewer Date_____
Filed on: PC-Cover..b~avo
# of Pages' Ref .,ZZSAA - e:2 00

Attached. please find the final draft (hopefully) of the Programming Conventions section.
of tlte
SDO Policies and Procedures. I apologize for the long delay -- 1 was forced to give
highe~ priority to other activities.

In the reviews of this set of conventions, several things came lip that are not properUy part
of the conventions section but do require management attention. They are:

o The Mesa Source Formatter should be developed as soon as possible. Much
of the effect of these conventions will not be realized until the formatter
exists. Many bad habits and much improperly formatted code may result if
the formatter is delayed. (I regret having introduced an additional delay by
failing to publish these conventions sooner.)

o An improved version of Bravo is being developed. However, maintenance of
this central tool is still uncertain, I recommend that the Tools Group
accept maintenance responsibility ror Bravo 7.0 for SDO (and no one
else!). Also, a program should be developed that will print Bravo files of
thc stylized form we will be using directly from Maxc, the Alto exec, or the
Program Librarian. This program should be released along with the Source
Formatter. Again. 1 recommend that the Tools Group undertake this
development.

o Individual software projects arc being allowed the priviledge of specifying
their own naming conventions and othcr specialized cOllventions. In return.
each such project should publish the naming and other special conventions
it is using -- and keep this liP to date. Both the Diamond and Tools
Groups havc published slIch conventions. SOD Cv1anagcmenl will h:lve to
see to it that this is done with all projects. It has been suggested {hat either
the Source Formatter or another program check the naming lIsed within
programs against the associated naming dictionary for the project. I think
this warrents investigation.

o To give the Source Formatter the ability to treat COllllllents ~lIld blank lin~s
rcason:tbly. it may be necessary to add a unique right COmI1H.'nt ddimiter to
Mcs formatter is underw~y. This. of necessity. is 3 pure addition to the Mesa
language.

o A separate "Guidelines for Producing Efficient DO/Mesa Cede" document
should be pubiished by the Mes:. Group. ;\f; new perform~lI1ce parameters
Finul Draft ~f Programming Conventions (hopefully) 2

are discovered or old ones changed. the document should be updated and
re-distributed to. our progmmmers. I do not mean to imply that our
programmers should sidestep Mesu and super-optimize their code.
Ho~ever, ir we know that, for exam pit!. passing more than N words. of .
parameters to procedures causes significantly slower procedure calls. we
may be able to structure interfaces to avoid this perrormance problem.

o Management should seek out "good" coding examples and distribute them to
the programmers. In particular. examples showing good use of Mesa types
and signals would be very helpful and would contribute to the long-term
maintenance of our software.

o An option to the cross reference program that reports possible signals that
can result from calling a procedure should be developed.



c:.;