General Style Deductions
Students in CSE142 are expected to demonstrate good programming style in
their homework solutions. Every homework assignment will describe specific
style requirements and expectations that students should keep in mind when
writing their solutions. This page lists general style issues that are
likely to be relevant to multiple assignments. This list includes common
style mistakes but does not list every possible style mistake.
TAs provide feedback on graded homework assignments and often give a "-0"
warning to indicate a style issue that is not being penalized but might be in
a future assignment. The list below indicates general style issues that will
not be graded as "-0". Homework assignments are listed in reverse order
because once a style issue is included for one homework, it is included for
all future homeworks. The list is not meant to be exhaustive, although it
includes the most common style issues. Students should as their TA to
explain any of these style categories that are not clear.
- Homework 7: Personality
- method errors:
- unnecessary return from a method
- data structure errors:
- extra data structures that aren't necessary
- bad usage of arrays (e.g., funky/incorrect indexing/usage)
- Homework 6: Baby Names
- control structure errors:
- bad use of if/else (e.g., empty branch, unnecessary tests,
redundant branches that can be combined with logical or)
- Homework 5: Guessing Game
- commenting errors:
- method header does not describe the purpose of each parameter or
does not describe the meaning of the return value of a non-void
method
- control structure errors:
- including code in a loop that should be executed once either
before or after the loop
- method errors:
- miscellaneous errors:
- unnecessarily inefficient code (e.g., constructing a new object
on every iteration of a loop when it could have been constructed
once before the loop or including an unnecessary test in a
conditional)
- Homework 4: Admissions
- readability errors:
- nondescriptive variable names
- control structure errors:
- using incorrect if/else structure
- failing to factor out redundant code in if/else structures
- miscellaneous errors:
- incorrect use of type (e.g., double instead of int, int instead
of boolean, String instead of char for a value known to be exactly
one character)
- using \n with print/println or to produce more than one line of
output with a single printf
- not combining print/print, print/println statements when
possible
- constructing more than one Scanner for console input
- Homework 3: Cafe Wall
- readability errors:
- not following Java naming conventions (e.g., not using camel
case, not using uppercase letters and word-separating underscores
for constants)
- inconsistent or nonexistent spacing within expressions (we
suggest one space on either side of an operator)
- not including a blank line between methods
- method errors:
- unused parameters or passing a constant as a parameter
- Homework 2: Rocketship
- readability errors:
- method header missing or does not adequately describe what the
method does
- bad indentation
- lines over 100 characters
- control structure errors:
- bad use of loops (e.g., 1 to 1 loops, including an unnecessary
check before a loop that repeats the loop test)
- method errors:
- nondescriptive method names
- class design errors:
- incorrect constant declaration (e.g., not public, not final, not
static)
- Homework 1: Song
- commenting errors:
- class header missing or doesn't describe both student and
program
- readability errors:
- miscellaneous errors:
- use of advanced material or forbidden constructs (\n and
System.out.print are not allowed for homework 1)
note: "e.g." should be read as "for example" and "i.e." should be read as "in
other words"
In general, once a class has been discussed, it is available for use by
students. For example, once the String class is introduced, you may assume
that you can call any of the available String methods in future homework
assignments without asking permission. Student should realize, however, that
saying that you are not forbidden from using a certain construct is not the
same thing as saying that it is a good idea to use a certain construct. We
don't give advice to students about which constructs to use. You have to use
your best judgment to decide and you might lose style points if you make a
poor choice. In addition, there are some constructs that you are not allowed
to use, as described in the next paragraph.
Java has grown to be a complex language with many features. We don't have
time to teach all of these features in CSE142. We have a general rule that
students should not use "advanced" material that we have not covered in
class. In addition, we have identified several Java features that we do not
want students to use. It is not bad style to use these features, but we want
to have a level playing field for all students. For any one of these
features, we prefer that either everyone in the class knows about it and can
use it or nobody is allowed to use it. The following features should not be
used in CSE142 homework or exam solutions:
- break, continue, return from a void method
- try/catch, annotations
- the var keyword
- Java 8 features (e.g., lambdas, streams, method references)
- toArray, clone
- StringBuilder, StringBuffer, StringJoiner, StringTokenizer, and String
methods toCharArray, join, matches
- Arrays.asList, Arrays.copyOf, Arrays.copyOfRange, Arrays.sort
- Collections.copy, Collections.sort
- package declarations
- System.console()
Many students find themselves wondering, "What is that feature you are
describing?" If you don't recognize it, then you're unlikely to use it, so
the best answer is, "Something that we have decided not to teach you in this
class so that we will be able to focus on the really important concepts you
need to learn."