|
|
Programming
Standards
Every program turned
in to CSC 171 will be graded according to these standards. Programming
standards are like style in natural languages, and like style in natural
languages, the best way to learn it is to start by following strict guidelines.
The intention behind both standards and style is to make reading easier.
Since the programmer is the person who reads their code most, one of the
biggest benefits of good programming standards is it makes errors easier
to find. So, when writing a program, make sure that the program always
follows the standards.
- To
Be Determined. Stay Tuned
- All readme
files must be in text format. This means no Word files!!!
- Your readme file
should be named readme.txt, not Readme.txt not README.TXT
and not p3readme1st.txt
- Make your readme
easy to read. For example, don't print it out in a way that letters
just wrap around in between words.
- Readme files are
for the TA's benefit, so they don't have to figure out how to use your
code and what or what not to expect from it. The better you tell us
this, the less time it will take us to grade your project, and the happier
we will be... thus the higher your grade will be! :-)
- Make your readme
files complete, short and concise
- Readme files should
contain the following explicitly marked in sections
- Name, troi
login name, section, project#, etc.
- If your readme
does not have your troi login name we will not grade
your project!!! This is the only way we can identify where your
electronically turned-in code is!
- Which parts
of the project you did do
- Which parts
you didn't do
- Known bugs
(if we find bugs in your code that you did not report, we
will assume you didn't test your code well enough to find the bug)
- Extra credit
- what you did for extra credit (you will only get points for what
you mention in this section
- How to run
the code on troi (name of main class, command line parameters,
runtime commands, etc.)
sample
readme.txt
- There will be no
turn in of hard copy for this class unless previously specified.
The 40% of your grade that is classified as "documentation" is actually
broken down into 2 parts of 20% each: documentation and organization.
Organization deals with how you choose to break up your project into classes,
methods, etc.
Since organization is 20% of your project grade, it's a good idea to follow
some tips.
- I can't believe
I have to say this but modularize your code!!!! This is a very
very very serious problem. If you don't understand modularization
or need help please come see a TA before it's too late! You will
not survive Computer Science writing code like that, much less
get a decent job afterwards. This may seem harsh, but it really is for
your own good.
- Practice good
object oriented style.
Documentation is another
20% of your grade. Documentation deals with things like naming of variables,
methods, and classes, comments, and general program readability.
Documentation is really boring and annoying when you are coding a small
assignment for class. When you work for a company that is writing a huge
project with lots of people, it's absolutely necessary. Someday, someone
will need to go in and look at your code and figure out what the heck
it's trying to do. Please try to make their life easy. Companies want
more than just someone who can code. They want someone who can code usable
code. And, you never know, the person going back in 2 years and looking
at your code may even be you. And trust me, even you will not have a clue
what you were thinking at the time.
|