Color coding |
conventions | Program conventions
| E-mail conventions
Time information is often color-coded. These colors mean these things:
||The past, or due in the past. No need to worry unless
you didn't do this item.
||Today, or the nearest class, or due now, or distributed
already and still due.
||In the next few days or in the nearest class.
||The far future, or this day will never come.
You must type all homework assignments except for diagrams, which can be
Homeworks are expected to be submitted by class-time on the day of the
deadline. You can print and turn in your homework assignment in class.
Homework not in my box by then will be considered late.
Homeworks requiring substantial programming will require electronic
submission as well. These homework will be clearly identified in class.
The electronic submission is in addition to submitting a printed
version of your solution. The programs should be submitted electronically
using the form located HERE.
Each submission will be acknowledged by the TA. If you do not
receive any acknowledgement within 1 working day from your submission you
should assume that something went wrong.
You may construct and test your programs on any platform you desire, but
be aware that programming assignments will be graded on the department's
Unix system. It is your obligation to ensure that your program does
indeed work on the department's system. You are expected to be familiar
with the Unix operating system. Together with your programs you are
required to submit a report describing the overall structure of the software,
the code organization, the algorithms used, and the meaning of each component.
You must submit electronic versions of your programs. E-mail your programs.
Be aware that you should not use tabs in your text. Instead use spaces
Always recall that you are not writing programs for yourself. A human
being will read your code and comments to determine a grade for your project.
your code is at least as important as running your program. Get in
the habit of making your programs readable now, so you can get good grades
now and also succeed in the future. Readability is enhanced by
Documenting each function or module -- purpose, inputs, and outputs.
Making your code self-documenting by using full, specific identifiers that
describe how the identifier contributes to the function's purpose. No abbreviations
or single letters please.
Using simple and straightforward algorithms. Efficiency is just not a concern
here. Don't be too "clever by half."
The primary purpose of E-mail is communication, and without the
usual non-verbal clues in normal human communication, the burden is on
the composer to ensure good communication. This means that the composer
has to be aware of:
These guidelines result in boring E-mailings that seem business-like. Exactly.
Readers of your E-mail may be reading lot of messages a day (as I do).
Your job is to make sure your message gets read exactly as you want it
to when your recipient does not have the time (or inclination) to go over
your message several times to comprehend its meaning.
Ambiguity. Reread your message to make sure you want all possible
interpretations. Please put in details. Instead of "Is homework nine really
due on Wednesday?" try "All the homework assignments except number nine
are due on Fridays. Did you mean for homework nine to be due on Wednesday,
or is this a typographical mistake?" Avoid humor or irony that is not completely
understandable as humor or irony.
Overload. Come to the point. If you use quoted material from other
E-mail, cut it to the minimum necessary to make your point.
Confusion. Be active and simple and straightforward. Make your sentences
as simple as possibly and easy to read. Use active voice. Avoid cascading
Distraction. Try to keep typos to a minimum. If your E-mail program
has a spelling checker, use it. Use standard capitalization and punctuation.
The primary characteristic of E-mail to keep in mind is that
E-mail is not treated the same by (a) E-mail send and
pop protocol programs nor by (b) E-mail reader programs.
This characteristic will not affect you if you and your E-mail recipients
stick to one E-mail program within a single system. But that is not the
case in this course. I, for one, use an ISP to read E-mail at home, and
your E-mail to me may travel throughout the world through many sites to
reach me. Furthermore, I use an E-mail program at home that few of you
have access to (and I change programs as better ones become available).
This means that differences in both (a) and (b) above are possible.
Here is how to minimize E-mail problems and make your text to me as
readable as it is when you compose it:
Press the return (or enter) key at the end of each line. Why? While your
E-mail composer may automatically wrap lines for you and while your E-mail
reader may also wrap lines for you, some E-mail readers do not. When unwrapped,
each paragraph will be read as just one long line, causing back-and-forth
horizontal scrolling line-by-line. A real pain.
Make your lines no more than seventy characters in length, preferable sixty
characters. Why? Some programs will truncate or wrap lines longer than
seventy-two characters (an old IBM convention). So seventy is a safe length.
In addition, quoted E-mail selections, starting with "> " or other typographical
conventions, increase the length of a line, so sixty is an even safer length.
If you use a larger length, your recipient's E-mail program may wrap at
a different length from yours, resulting in a hard-to-read long line, short
line, long line, short line, ..., pattern.
Don't use non-ASCII characters. This is especially true of characters like
curly quotes or em dashes. Some E-mail pop and send programs and reader
programs convert everything to ASCII (seven bit characters) by ignoring
the eight bit. Would you rather read "this" with regular double quotes
or RthisS with mistranslated curly quotes?
Don't use tabs. One problem with tabs is that some readers do not support
them at all, converting a tab to a single space. But the main problem is
that your recipient may not be using the same tab size as you are using.
In both cases, the stuff you so carefully lined up may end up as a formatting
nightmare, a mishmash of text all over the place.
Don't use enclosures or inserts. Not everyone has the same MIME-compliant
helper applications you do. Furthermore, sometimes MIME attachments are
just discarded, either in transit or by the recipient's E-mail reader.
Instead, put the text you want directly in the E-mail message. Every E-mail
program I know of allows you to read a text file directly into the message.
||August 1998, E-mail: epontell AT cs.nmsu.edu