CSCI 1060U Programming Workshop Professor: Dr. Jeremy S. Bradbury Phone: 905-721- 8668 ext. 3685 E- mail: jeremy.bradbury@uoit.ca Office hour: To be announced (UA4016), otherwise by appointment Teaching Assistants: Michael Miljanovic E- mail: michael.miljanovic@uoit.ca Office hour: during labs (J123A), otherwise by appointment J.S. Bradbury CSCI 1060U Lecture 1 Slide 1
Lectures: CSCI 1060U Programming Workshop Tues. 12:40pm 2:00pm (UA1220) Thur. 11:10am 12:30pm (UA1220) Laboratories: Wed. 11:10am 2:00am (J123A) Thurs. 12:40pm 3:30pm (J123A) Note: labs start next week. J.S. Bradbury CSCI 1060U Lecture 1 Slide 2
Aims of the Course: CSCI 1060U Programming Workshop The primary purpose of this course is to provide a strong foundation for programming practices and theory. This course will focus on object-oriented programming in C++. J.S. Bradbury CSCI 1060U Lecture 1 Slide 3
CSCI 1060U Programming Workshop Textbook: Bjarne Stroustrup, A Tour of C++ This book will be the primary course reference and is a good general C++ reference. J.S. Bradbury CSCI 1060U Lecture 1 Slide 4
Textbook: CSCI 1060U Programming Workshop Online Resources. Online articles and websites will be used to supplement the textbooks. Links to all online resources will be posted in the course website on WebCT. J.S. Bradbury CSCI 1060U Lecture 1 Slide 5
CSCI 1060U Programming Workshop Topics (include but are not limited to): Program Documentation Code Style & Program Refactoring Program Debugging Techniques & Assertions Advanced C++ (recursion, pointers and more ) Object-Oriented Design (inheritance, polymorphism, and more ) Templates & the Standard Template Library J.S. Bradbury CSCI 1060U Lecture 1 Slide 6
CSCI 1060U Programming Workshop Marking: Laboratories (weekly) 40% Term Tests (2) 20% Final Exam 40% Note: The schedule for tests is as follows: Test #1 Thursday, Feb. 26, 2015 Test #2 Tuesday, Apr. 7, 2015 J.S. Bradbury CSCI 1060U Lecture 1 Slide 7
CSCI 1060U Programming Workshop Laboratories This course will have weekly laboratories. Laboratories will allow students to practice the programming concepts and techniques that are covered in the lectures. All labs will be done individually Each lab may include in-lab and take-home problems. Laboratory Submissions Unless otherwise specified in the instructions, all laboratory work should be submitted using Blackboard. J.S. Bradbury CSCI 1060U Lecture 1 Slide 8
Code Style & Documentation I Overview The style of your code and the program documentation both have a significant affect on the readability, maintainability and testability of your programs Today we will look at: appropriate code style for C++ (and Java) program documentation guidelines for C++ (and Java) J.S. Bradbury CSCI 1060U Lecture 1 Slide 9
In Class Activity: Using C++ write a commented program that can take an array of characters and identify the first character that appears only once in the array. The input for the program should be a: abdrfgfrdag The output for the program should be: b If there is no character that appears only once the output should be: no instance found J.S. Bradbury CSCI 1060U Lecture 1 Slide 10
Program Style Indentation & White Space Can be used to help group lines of code Some general rules include: 1. Insert a blank line between distinct sections of statements 2. Indent statements that are within another statement (e.g., inside an if statement or a while statement) 3. Place closing braces on a distinct line. Place opening braces on a distinct line or at the end of the preceding line. J.S. Bradbury CSCI 1060U Lecture 1 Slide 11
Program Style Line Length In C++ it is usually advised to avoid lines that are longer than 80 characters. Why? Improved readability in terminals Typically avoids bad wrapping by printers What happens if our line is more than 80 characters? Need to wrap text! J.S. Bradbury CSCI 1060U Lecture 1 Slide 12
Program Style Line Length The following Java wrapping guidelines also work for C++: Break after a comma. Break before an operator. Prefer higher-level breaks to lower-level breaks. Align the new line with the beginning of the expression at the same level on the previous line. If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 8 spaces instead. 1 1 Source of guidelines is http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html J.S. Bradbury CSCI 1060U Lecture 1 Slide 13
Program Style Comments Comments are used in a program to increase the readability of the code Reasons for using comments include: Explanations of statements Description of usage of statements Etc. (We will learn more about comments when we talk about documentation) J.S. Bradbury CSCI 1060U Lecture 1 Slide 14
Program Style Comments In C++ comments can occur in two ways: // everything from start symbol to the end of line // is a comment or /* Everything between the start and end symbols is a comment. */ J.S. Bradbury CSCI 1060U Lecture 1 Slide 15
Program Style Naming Conventions In C++ there are general naming conventions for variables, constants and functions also for namespaces, etc. A company or a project may also have specific naming conventions J.S. Bradbury CSCI 1060U Lecture 1 Slide 16
Program Style C++ Naming Conventions Identifier Type File Names Type Names Variable Names Constant Names Function Names Rules for Naming should be all lowercase and can include underscores (_) or dashes (-) start with a capital letter and have a capital letter for each new word, with no underscores Types should be nouns. all lowercase, with underscores between words. Class member variables have trailing underscores. Variables should be nouns. Use a k followed by mixed case Regular functions have mixed case Examples a_file.cpp MyClass local_variable member_variable_ kmyconstant MyFunction(); Source: This table is based on the website http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#general_naming_rules J.S. Bradbury CSCI 1060U Lecture 1 Slide 17
Program Style Java Naming Conventions Identifier Type Packages Classes, Interfaces Methods Rules for Naming The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries Subsequent components of the package name vary should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive." Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Examples com.blah Class MyClass; Interface MyInterface; mymethod(); Method(); mylongmethod(); Source: This table is modified from the table at: http://www.oracle.com/technetwork/java/codeconventions-135099.html J.S. Bradbury CSCI 1060U Lecture 1 Slide 18
Program Style Java Naming Conventions Identifier Type Variables Constants Rules for Naming Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. should be all uppercase with words separated by underscores ("_") Examples int I; int size; int mysize; static final int A_CNST=1; Source: This table is modified from the table at: http://www.oracle.com/technetwork/java/codeconventions-135099.html J.S. Bradbury CSCI 1060U Lecture 1 Slide 19
Program Style File Structure Most programs will have many source files The organization of these files is also part of the program style In Java, the use of packages defines directory structure. In C++, the programmer has to decide on the appropriate directory structure (usually based on the conventions of the company or project) J.S. Bradbury CSCI 1060U Lecture 1 Slide 20
Documentation Comments are a form of in-program documentation When to comment and when not to comment comes with experience but there are some general rules! J.S. Bradbury CSCI 1060U Lecture 1 Slide 21
Documentation Rule 1: Comment at the beginning of the source file with the main method/function. These comments should include: the purpose of the program, how it should be executed, the expected input/output, the version number Any additional information that would be appropriate J.S. Bradbury CSCI 1060U Lecture 1 Slide 22
Documentation Rule 2: At the beginning of all files/classes provide comment about The copyright notice the author, revision history and a description of the class. Rule 2A: If functions or methods within a class have dependencies regarding their usage you should document these as well. Example: a stack class should include comments such as a push has to occur before a pop. J.S. Bradbury CSCI 1060U Lecture 1 Slide 23
Documentation Rule 3 (C++): For the function declaration include comments regarding the usage of the function. For the function definition include comments such as an explanation of how the function works, any parameters and return values. Rule 3 (Java): For each method include comments detailing the purpose of the method, how it works, any parameters and return values. J.S. Bradbury CSCI 1060U Lecture 1 Slide 24
Documentation Rule 4: Comment groups of statements the require explanation. These comments should be: Non-obvious Provide insight into subtleties in the algorithm Explain why the statements do what they do J.S. Bradbury CSCI 1060U Lecture 1 Slide 25
Documentation In-program documentation contained in the comments can also be used to generate other forms of documentation Often documentation generation tools are used Why? Example: API documentation Rewriting the document could lead to inconsistency between external and in-program documents Rewriting documents takes more time and resources J.S. Bradbury CSCI 1060U Lecture 1 Slide 26
Code Style & Documentation I Summary We ve discussed guidelines for appropriate code style and documentation Next time We will continue to talk about documentation by discussing Javadoc and Doxygen We will also continue to talk about program style in particular bad programming practices and how to fix them using code refactoring J.S. Bradbury CSCI 1060U Lecture 1 Slide 27
Code Style & Documentation I References Mozilla Developer Network Coding Style https://developer.mozilla.org/en/mozilla_coding_style_guide Google C++ Style Guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Code Conventions for the Java Programming Language http://www.oracle.com/technetwork/java/javase/documentation/ codeconvtoc-136057.html J.S. Bradbury CSCI 1060U Lecture 1 Slide 28