✁ � ✄ � � � ✄ ✄ ✂ ✁ CSC 181F Lecture Notes CSC181F Introduction to Computer Programming Instructor: Ray Ortigas These lecture notes are provided for the personal use of students taking CSC181F in the Fall term 2000/2001 at the Lectures: R11 in GB119, F12 in GB220, T12 in RS211 University of Toronto Tutorial: M12 in GB405, HA403 Practical: W4-6 in SF1106, SF1012 Copying for purposes other than this use and all forms of Office Hours: T2-4, F11 in SF3207 distribution are expressly prohibited. E-mail: rayo@dgp.toronto.edu ut.ecf.csc181 News group: www.dgp.toronto.edu/people/rayo/csc181/ c David B. Wortman, 1995, 1996, 1998, 1999 Web Page: c Hiroshi Hayashi, 1997 c Ray Ortigas, 2000 0 1 CSC180F & CSC181F What’s Important Writing and Communication Skills CSC180F CSC181F no previous experience assumes previous experience Writing and Communication Skills no previous programming assumes previous programming Mathematical Skills covers introductory C covers more (advanced) C Computer Skills covers C++ A typical commercial software project involves creating more than 20 kinds of basic programming skills covers advanced material paper documents on such items as requirements and functional, logic, and data specifications. For civilian projects, at least 100 English words are produced for more emphasis on technique and style every source code statement in the software. For military software, about 400 teaches effective programming words are produced for every source code statement. Many new software professionals are surprised when they spend more time producing words than code. FinalAverage( CSC180F ) FinalAverage( CSC181F ) Capers Jones, Gaps in programming education , IEEE Computer Magazine, pp. 70–71, April 1995 2 3
☎ ☎ ☎ ☎ ☎ ☎ Books for CSC181F Reading Assignment Required Text Books – K.N. King, C Programming: A Modern Approach, Norton, 1996 Recommended Text Books K.N. King, Chapter 1 – S.P Harbison and G.L. Steele Jr., C A Reference Manual, Prentice Hall, 4th edition, 1995 Supplemental reading – S. McConnell, Code Complete - A Practical Handbook of Software Construction, Microsoft Press, 1993 S. McConnell Chapters 1 to 3 Reference Texts – E. Roberts, The Art and Science of C, Addison-Wesley, 1995 – E. Roberts, Programming Abstractions in C, Addison-Wesley, 1998 – B.W. Kernighan & D.M. Ritchie, The C Programming Language (ANSI edition), Prentice-Hall, 1988 – B.W. Kernighan and R. Pike, The Practice of Programming, Addison-Wesley, 1999 4 5 Grading Scheme Assignments and Tests Assignments are due at the START of lecture on the due date. Assignment 1 Due 26 Sep 4% Assignment 2 Due 10 Oct 4% Assignments may be handed in early to the instructor. Term Test 1 TBA (Week of 16 Oct) 20% Late assignments will NOT be accepted except in case of documented illness Assignment 3 Due 31 Oct 4% or family problems. Similarly, midterms may not be missed except in case of documented illness or family problems. Consult the instructor if you need Assignment 4 Due 14 Nov 4% special consideration. Term Test 2 TBA (Week of 20 Nov) 20% Assignment 5 Due 5 Dec 4% The test and exam are closed book, but a single page (8.5 by 11 inch, both sides) Final Exam TBA (December) 40% aid and non-programmable calculators will be allowed. 6 7
☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ Plagiarism and Cheating Guidelines for Avoiding Plagiarism Plagiarism is a kind of fraud: passing off someone else’s work or ideas as your own in You may discuss assignments with friends and classmates, but only up to a point: You may order to get a higher mark. discuss and compare general approaches and also how to get around particular difficulties, but you should not leave such a discussion with any written material. You should not look Plagiarism is a serious offense at U of T. It will not be ignored. at another student’s solution to an assignment on paper or on the computer screen, even in We have programs to compare students’ programs for evidence of similar code. We shall draft form. The actual coding of your programs, analysis of results, and writing of reports ask you to submit electronic versions of all of your assignments, and we shall run our must be done individually. programs on these. Due to the way programs work, it does not help to change comments, If you do talk with anyone about an assignment, please state this in your assignment and variable names or even code organization. state the extent of your discussion. You can really screw up your career at U of T AND YOUR FUTURE by committing an Note that it is also a serious offense to help someone commit plagiarism. Do not lend your act of plagiarism. printouts, reports or diskettes, and do not let others copy or read them. To protect yourself The assignments you hand in must be your own and must not contain anyone else’s against people copying your work without your knowledge, retain all of your old printouts ideas. and draft notes until the assignments have been graded and returned to you. If you Refer to Appendix A in the U of T Code of Behavior on Academic Matters for a more suspect that someone has stolen a printout or diskette, contact your instructor immediately. detailed description of plagiarism. 8 9 Helping Each Other Program Construction Although you must not solve your assignments with the help of others, there are Understand the Problem!!!! still many ways in which students can help each other. Design Algorithms and Data Structures For instance, you can go over difficult lecture or tutorial material, work through Design to Program exercises, or help each other understand an assignment handout. Write the program You can ask the tutors to explain material that you are having difficulty with. Inspect the program for errors This sort of course collaboration can be done in study groups or through the newsgroup. Compile and Debug the Program Test the program thoroughly Document the program 10 11
☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ Important Considerations Knowing a Programming Language Correctness Syntax The form of legal constructs Correctness Semantics Correctness The meaning of legal constructs Program maintainability and modifiability Technique Program’s efficiency How to use the language effectively and efficiently Programmer’s efficiency 12 13 Program Development Program Development Stepwise refinement Requirements Choose data structures Specification Choose algorithms Design Think before programming Implementation KISS - K eep I t S imple S tupid Debugging & Testing Solve most general instance of problem, minimize special cases 14 15
☎ � ☎ � ☎ � ☎ ☎ � � ☎ � ☎ ☎ ☎ Requirements & Specification Program Design Understand the problem The Designer’s Palette General case Data Structures Special cases Algorithms Boundary conditions Programming Language Errors & Exceptions Design Goals Requirements Always correctness What the user needs Time or space efficiency Often described informally Development time Maintainability Specification Formal & Precise description of Problem Designer’s Resources Describe problem not the solution Experience Books and articles on algorithms and design 16 17 Design Techniques Problem Analysis What are the inputs? Top Down domain & range? special cases? Stepwise refinement What are the outputs? Bottom Up domain & range? special cases? Yo-yo, Chaotic How are outputs related to inputs? BAD - leads to rotten programs What is the general case of the problem? Program design should be systematic and methodical! Have I solved this problem or a similar problem before? Has someone solved this problem or a similar problem before? 18 19
� � ✓ ✔✕ ✞ ✔ � ☎ ✖ � � ✒ ☎ � � � ✁ � ☎ � ✍ ✎ � ☞ ✆✝ ✞ ✟ ✠ ✝ ✟ ✡ ☛ ✌ ✑ ☞ � ☎ ☎ � ✍ ✎ ✏ � Design Technique Problem Analysis Data structures then algorithms Analogy, Conditions Decomposition & Recombination Algorithms then data structures Use all the problem description? Try to find efficient method for the most general case Minimize special cases and exceptions Solve subproblem & generalize? Induction, work backwards? Iterate on design more efficient or more general Identify intermediate results KISS - Keep It Simple Stupid Check the results? Simplicity is the virtue Iterate on simplifying solution G. Polya, How to Solve It , Princeton University Press 20 21 Design by Stepwise Refinement Stepwise Refinement Example Start with the whole problem Problem: Solve quadratic equations Subdivide problem into several separate subparts e.g. input, compute, output Decide how to represent data and carry it between subparts Analysis Subdivide each subpart into simpler subsubparts Continue subdividing until sub * parts are small general case 2 real or imaginary roots special cases a, b and/or c = 0.0 Combine sub * parts to make complete program Applicable algorithm 22 23
Recommend
More recommend