Skip to main content

Java/CS1 Cheat Sheet

Posted by cayhorstmann on October 6, 2009 at 8:31 PM PDT

The next edition of my CS1/Java book is going to print soon. At the last minute, we decided to put the real estate of the inside covers to good use and include a “cheat sheet” with the most important Java control structures and libraries. Since it would be particularly embarrassing to have a typo here, I am hoping to enlist the aid of the community.

PDFs for the inside covers are here and here. If you spot a typo, please let me know in the blog comments. (But don't tell me about s.length—which should be s.length()—in the String Operations section. That is the only one I managed to spot.)

If you have other comments about what should be included/excluded in the cheat sheet, please let me know too. Your suggestions may not make it into this edition, but I do keep track for the next edition...which always comes sooner than I think. (But don't tell me that the switch statement must be included. Not only would it chew up a lot of real estate, but it is also something that one can do without in CS1. Students are supposed to learn computer science, not language minutiae.)

Thanks for your help! When the book goes into print, I'll update the cheat sheet links with the final versions so you can point the Java learners among your friends and family to them.

covers.png89.36 KB


Thanks to everyone who

Thanks to everyone who replied! The PDF links now point to the final version, with those suggestions that we were able to accommodate. Feel free to point any Java learners to them.



Typeface and annotations

Nice work, Doctor. The most confusing thing I noticed is the choice of typeface for annotations - it seems somewhat consistent, but in code, what is the difference between the occasions in which "cursive" font is used, and those in which a plain serif font is used? Perhaps this can be made more uniform (I would recommend converting the serif portions since they are not as immediately distinguishable from the code as the cursive font). The section on Conditional loops seems quite confusing after the first block; what is optional is not clear for the else-if and the else blocks... also, a bracket could be used to show that the entire contents of if (...) is the condition, not just the comparison operator, as the line may indicate. Perhaps it was the intent that the student actually read the book and use this only as a cheat sheet; if the student was not already familiar with the material, I suppose the cheat sheet is not intended to instruct. Also, the "foreach" construct appears on both pages... both are arguably relevant, but still redundant. The method declaration section labels everything but the method name... same argument as for labeling the conditionals.

Consistent comment

Cay, Not a typo, but it would make comments more consistent if in the Linked Lists, Sets, and Iterators (should you really use the comma before "and"?) section you changed "Adds to set" to "Adds to set if not present". That would be consistent with your next comment for deletion from the set.

Tag "final" in "final double" declaration

In the "Variable and Constant Declarations" section (, would it be useful to tag "final" as a modifier? Otherwise it just sits there, potentially leaving readers to wonder if "final double" is some special type, or something equally confusing.

do...while and subtyping

Hi Cay,
In the do .... while example, 'input' is not declared.

In the second page, you use
It seems there is no example of size() on a collection.

Moreover, this page is not coherent,
You use interface for Set and Map but not for List.

ArrayList a = new ArrayList();
Set s = new HashSet();
Map m = new HashMap();

Is it because you think that having a common supertype for ArrayList and
LinkedList is a mistake. By example you can write a foor loop
to get all elements of an linked list using an index ?


It was deliberate not to use

It was deliberate not to use interfaces for array lists and linked lists. The Java List interface does not bring happiness to the CS1 instructor. We like to talk about efficiency of operations, but with a List you can only assume that linear traversal and insertion at the end is O(1). Sure, there is the RandomAccess marker interface, but that's a kludge.

This is not a typo, but it

This is not a typo, but it might be worth changing: if (u.equals("HELLO")) to: if ("HELLO".equals(u)) to get rid of those pesky NPEs. - Bob

Not a typo again

Not a typo, but instead of declaring an ArrayList names = ... and LinkedList names = ..., maybe consider declaring those vars as List. - Bob

variable 'in' is defined twice

You declare 'Scanner in' twice with two different input sources... it won't compile and you'll confuse your students :)

do loop

The do loop in Cover2.pdf isn't wrong, but its prompt and condition are contrary to what I'd expect. The prompt asks for a positive number, but a positive number terminates the loop. I was expecting a non-positive number to be the sentinel value. Ack. Nevermind. You're cycling until valid input.