CIS 255 (CS1) Programming Methods: Java

decorative pic of computer

Instructor

Dave Harden
Email: harden.classes@gmail.com
Response Times: I almost always respond to emails and discussion posts within 24 weekday hours, always within 48 weekday hours.

Please use the class discussions for all questions whenever possible. For private questions that are not appropriate for the class discussion, email me at harden.classes@gmail.com and include "CIS 255" in the subject. Please do not use Canvas messaging (or "inbox").

Four Most Important Announcements!

You must post an introduction in the "introductions" topic of the class forum by Thursday, June 12, or I am required to drop you from the class. When you begin working your way through the modules, you'll see that this is the first task for week 1.
Absolutely no assignments will be accepted for any reason after Tuesday, July 29.
In the rare event that I grant an extension (due to prolonged illness, for example), it will always be via email. If you do not have an email from me stating clearly that I am giving you an extension, you do not have an extension. I do not give extensions verbally.
Please do not submit code that you find online or is generated by AI. I will identify it, and you will receive a 0 and an Academic Dishonesty Report. This occurs many times every semester. Also, it is imperative that you read the Academic Dishonesty Policy carefully!

Textbook

We're using an interactive etextbook published by zyBooks. The first time you click on a link in Canvas that leads to the zyBook, you will need to subscribe to the text for $20. (You can also purchase an access code in the bookstore, if you prefer.) I think you're going to find that this is a great way to learn computer programming!

Schedule

Assignments are due at 11:59pm on the date indicated in this schedule. Be sure to check the late policy for more information.

Module	Topic	Text Reading	Suggested Start Date	Assignment Due Date
1	Introduction: Java	ch 1	Monday, June 9	Thursday, June 12
2	Variables/Assignments	ch 2	Thursday, June 12	Sunday, June 15
3	Branches	ch 3	Sunday, June 15	Wednesday, June 18
4	Loops	ch 4	Wednesday, June 18	Saturday, June 21
5	Arrays	ch 5	Saturday, June 21	Tuesday, June 24
6	User-Defined Methods	ch 6	Tuesday, June 24	Friday, June 27
7	Objects & Classes 1	ch 7.1 - 7.23	Friday, June 27	Monday, June 30
8	Objects & Classes 2	ch 7 remainder	Monday, June 30	Thursday, July 3
9	Inheritance 1	ch 8.1 - 8.6, 8.14, 8.15	Thursday, July 3	Sunday, July 6
Midterm	Through Objects/Classes	ch. 1 - 7	Sunday, July 6	Sunday, July 6
10	Inheritance 2	ch 8 remainder	Sunday, July 6	Wednesday, July 9
11	Exceptions	ch 9	Wednesday, July 9	Saturday, July 12
12	Generics	ch 10	Saturday, July 12	Tuesday, July 15
13	Mem Mngmnt & I/O	ch 11 - 12	Tuesday, July 15	Friday, July 18
14	Recursion	ch 13	Friday, July 18	Monday, July 21
15	Searching/Sorting	ch 14	Monday, July 21	Thursday, July 24
16	JavaFX	ch 15	Thursday, July 24	Sunday, July 27
Final		ch 8 - 15	Friday, Aug 1	Friday, Aug 1

Final Grades

Your final score will be made up of the following components.

decorative pic of computer

Component	points each	points total
Assignments (16)	50	800
Discussions (16)	5	80
Midterm	40	40
Final	80	80
total		1000

Grades will be assigned as follows: 900 points for an "A", 800 points for a "B", 700 points for a "C", 600 points for a "D". Grades of + and - are not given

Discussions (80 points)

You will be required to make one substantive post in a discussion each week. Each discussion is worth 5 points. To be confident that you'll get the 5 points, you should typically expect your post to be around 30 words or more. Posts with fewer words can, of course, be considered substantive, especially if it is a serious question about the content or a serious response to another student's question about the content.

Assignments (800 points)

Submissions that use concepts that have not been covered in class may receive a score of 0.

Assignments will include participation activities, challenge activities, and LABs.

Assignments will be scored automatically in zyBooks. Note that it is very common for incorrect code to run fine on one compiler and then fail on another. Your code must run correctly on every compiler. Don't be surprised if your code works for you but doesn't pass all of the tests the first time you submit to the grading system.

In addition, the LABs will also be checked manually to ensure that all requirements have been met and that the Style Conventions have been adhered to. You could lose up to 20% of the points for each LAB due to style issues.

Exams (120 points)

There will be a midterm and a final. Both rely heavily on the textbook reading assignments. Both exams are taken online, and you can take each exam at any time of your choosing during day on which it is scheduled (see the schedule). They are due at 11:59pm. Once you start, each exam must be completed within one hour, without exception, so make sure to ensure that you will not be interrupted once you begin. Both exams are multiple choice. The coverage of each exam is given in the schedule. Of course, on the final, you will need to know a few things from earlier in the course.

You will take the exams on the honor code. The tests are available for one full day for your convenience, but the validity of the tests relies heavily on your academic integrity. Don't take advantage of the flexibility by sharing questions with students who have not taken the test.

You are expected to simulate a class environment when you take the exams. The exams are open book and open notes, and you may even use your compiler, but you cannot receive any help from another person. The rules are summarized below. Email me if you have any questions:

Allowed: Textbook
Allowed: Notes
Allowed: Past assignments
Allowed: Compiling your answers
Not Allowed: AI
Not Allowed: Browsing non-class websites
Not Allowed: Accepting assistance from another person.
Not Allowed: Sharing questions with other students after the test.

Late Policy

This late policy is for assignments and discussions only. Late exams are not accepted.

Assignments are due at 11:59pm on the date indicated in the schedule. However, assignments may be submitted up to 72 hours late with no penalty. This is the "final deadline". This does not mean that the due date is extended! For example, if your assignment is not done by the original due date, and you get severely ill between the due date and the final deadline, so that you cannot complete your assignment by the final deadline, it will be considered late. In addition, failing to complete projects by the original due date will put you behind in the class, and may delay the grading of your assignment significantly. You should make every effort to complete the assignment by the original due date.

For technical reasons, the due dates shown in zyBooks are the final deadlines rather than the due dates.

Beyond the final deadline, assignments will be accepted until 1 week1 after the original due date (except that no assignments will be accepted after Tuesday, July 29). They will be considered late and will receive a 50% deduction, with no exceptions. Assignments are not accepted more than 1 week late.

In order to get partial credit for an assignment that is submitted after the "final deadline" you must submit it in zyBooks and then email me to let me know.

Note that nothing in this Late Policy is intended to imply that you may resubmit an assignment once it has been graded.

To repeat: absolutely no assignments will be accepted for any reason after Tuesday, July 29.

Academic Dishonesty

All work that you submit must be your own work.

You are free to work together with and get help from your classmates. This should be limited to discussing the assignment. It should not, for example, require you to view each others' code (with one exception noted below). You are free to research topics online (although I don't advise this), provided that the work you submit is completely your own. In this class, these guidelines will be enforced as follows:

Any such collaboration must be cited near the top of the documentation for your submitted code.
Any such collaboration must not result in code that is so similar to another student's code or to code found online that I am able to detect the collaboration.

I understand that point #2 may be hard for you to determine. Therefore, (1) If you are not sure whether your collaboration crosses this line, PLEASE CHECK WITH ME. Also, (2) you will receive one warning. There will be no consequence for a first violation of this policy, provided you have cited the collaboration.

I suggest that in order to avoid any questions, you get all of the information you need for the course from the text and lessons. If you need help, ask in the discussion, email me, or get help from official tutors from the college.

Further guidelines for using online help:

You should not use even one line of code that you find online, even if you modify it. You may use websites for reference purposes (for example: how does a particular language feature work?). But you should not get information specifically related to a problem you are trying to solve (for example: what's an algorithm for reducing a fraction?). In particular, Don't ask for help from online forums. They will almost invariably do the problem for you, or give you bad information.

Examples of specific actions that violate this policy:

Using chegg.com or coursehero.com or essaytaste.com or any AI for any reason
Using an online tutor
Looking at another student's code
Showing another student your code
Viewing or copying code online that is related to a course assignment

Exceptions:

You can look at another student's code onlyif it is in order to help that student. You must be confident that you won't use any of the other student's code in your own work.
You can show another student your code only if you need help from that student. You must be confident that that student will not use any of your code in their work.

Consequences

A first violation of this policy (with no citation, as described above) will result in a zero on the assignment and the submission of an Academic Dishonesty Report.
If you have received a warning, then a subsequent violation of this policy will result in a zero on the assignment and the submission of an Academic Dishonesty Report, even if there is a citation.
A subsequent violation following a violation that resulted in a zero on an assignment will result in an "F" in the class.

Student Learning Outcomes

Upon successful completion of this course, a student will meet the following outcomes: Demonstrate knowledge and understanding of programming paradigms and the principal object-oriented programming concepts.

Design, implement, and use classes, interfaces, and methods, employing standard naming conventions and advanced features including exception handling, 1/O, GUIs, and event handling.
Employ object-oriented methodology to design and effectively implement medium-sized computer programs using simple Unified Modeling Language (UML) notation.
Decompose a real-world problem and apply strategies for the reuse of existing components with inheritance and polymorphism.
Describe the concept of recursion, and implement, test, and debug simple recursive methods.
Explain and employ basic sorting and searching algorithms.
Use and create standard API documents to understand and document the use of classes and methods.
Demonstrate an understanding of professional codes of ethics, such as ACM and IEEE.

Style Conventions

In the real world, programmers usually work in teams and often the company that they work for has very precise rules for what kind of style to use when writing programs. For this reason, and also to encourage good programming style, we will be adopting the following style conventions for this class. This is not to say that these rules represent the only good style for writing computer programs (although in most cases they do). After you finish this class, you may decide that you prefer a different style than what is required here. However, in order to get good grades on your programming assignments in this class, you must follow these guidelines.

Documentation:
A. Initial File Comment [a2]: Your programs should be well-documented. Each program should begin with an initial file comment. This comment should start by indicating your name, class, date, instructor, name of file, etc. Next it should describe in detail what the program does and how the code works. Any input expected from the user and any output produced by the program should be described in detail. You should expect your initial file comment for the first few assignments to be at least 50 words, and by assignment 7 you should be seeing over 90 words.

Important local variables should be commented at their declaration. Aside from this, in most cases it should not be necessary to place comments in the body of a method. This usually clutters up your code and ends up making the method more difficult to read. If you find yourself needing to explain something in the middle of a method, perhaps you should look for a clearer way to write it!

B. General Advice [a2]: Your comments should be directed toward a reader who is an expert Java programmer. You should not explain features of the language!

C. Method Comments [a5]: Just above each of your method definitions you must provide a comment describing what the method does. A simple method might have a 15 word comment, while a more complex method should have a comment of at least 50 words. Make sure to explain the role of each parameter in your method comments, and refer to them by name.
Appearance:
A. General [a1]: Use lots of whitespace (blank lines and spaces) to separate the different parts of your program!! When I look at your program my first impression should not be a page crammed with code. Get rid of wraparound. Put a blank line between your declarations and your statements. Put a space before and after each operator. Make sure your lines aren't too long, no more than 80 or 90 characters.

B. With Methods [a5]: Put 6 blank lines between method definitions.
Identifier Names:
A. General [a1]: Choose your identifier names very carefully. Variable names should precisely represent what the variable is storing. Do not use abbreviations unless you feel the identifier name would otherwise be so long that it would hinder the readability of your program. Don’t use one letter variable names except, perhaps, as a counter in a for loop.

B. With Methods [a5]: Choose your method names so that as much as possible your program reads like English and the names describe precisely what the method does. Void method names should start with an action word (readString, getData, etc.).
Decomposition [a5]:
Any time there is a sequence of statements in your program that performs a specific, nameable sub-task, you should consider making that sequence of statements into a method. A nice length for methods is about 10 lines, although they can be longer if they are simple (for example, lots of output statements) or if there is just no logical way to break it up. Consider making complex methods (for example, nested loops) even shorter. A goal: when you are done with your program, I ought to be able to look at any particular method and have a general understanding of what is does and how just at a glance.

In this class you should rarely write a method longer than 10 lines.
Indentation [a1]:
Indents must be exactly 4 spaces.

You may follow the indentation scheme used in the textbook or you may use the scheme used in the lessons. No others. For example, every statement must appear on a line by itself, every close curly brace must appear as the first (or only) item on a line, and every open curly brace must appear as the last (or only) item on a line.
Simple Code/No Repeated Code [a1]:
Make sure that your code is as simple as possible and that there is no unnecessary repeated code.
Miscellaneous:
1. [a2] In most cases no numbers other than 1 or 0 should appear in your program. Other numbers should usually be declared as class constants using the "final" keyword. Names of constants should be all uppercase.
2. [a2]Do not use any class variables in your main class. These are variables that are declared in the main class but outside of any method definition. The exception to this rule is the Scanner variable. Violating this guideline may cost you a lot of points. (Note that this does not apply to final variables.)
3. [a4] Do not use break (except in a switch statement), return (except in a value-returning method), exit, or continue.
4. [a3] Don't mix up statements and expressions. For example, count++ should be used as a statement, not as an expression.
5. [a1] The characters "== true" or "== false" should never occur in your code.
6. [a3] You should never have
```
if (x) {
    return true;
} else {
    return false;
}
```
  or
```
if (x) {
    return true;
} 
return false;
```
  in your code (where x is any expression). These can be replaced with simply
```
return x;
```
7. [a1] Do not use a floating point variable to store a quantity that will always be an integer.