Communicating in Code: Commenting Programming Studio Spring 2009 Note: several examples in this lecture taken from The Practice of Programming by Kernighan.

Slides:



Advertisements
Similar presentations
Introduction to Programming
Advertisements

Communicating in Code: Layout and Style Programming Studio Spring 2012 Note: several examples in this lecture taken from The Practice of Programming by.
Chapter 29: Integration Jacob Harper. The Integration Approach The order of adding components to a system is crucial Benefits to careful integration –
Week 5: Loops 1.  Repetition is the ability to do something over and over again  With repetition in the mix, we can solve practically any problem that.
Chapter 8Java: an Introduction to Computer Science & Programming - Walter Savitch 1 Chapter 8 l Basic Exception Handling »the mechanics of exceptions l.
Internal Documentation Conventions. Kinds of comments javadoc (“doc”) comments describe the user interface: –What the classes, interfaces, fields and.
Coding Practices. Why do we care? Good code is more than just functionality Other people will read your code You will forget what you code does Debugging.
Revealing the Secrets of Self-Documenting Code Svetlin Nakov Telerik Corporation
Communicating in Code: Layout and Style Programming Studio Spring 2009 Note: several examples in this lecture taken from The Practice of Programming by.
Documentation 1 Comprehending the present – Investing in the future.
C Programming - Lecture 7 This lecture we will learn: –How to write documentation. Internal docs. External docs. User docs. (But not much about this).
CSC1016 Coursework Clarification Derek Mortimer March 2010.
Mrs. Chapman. Tabs (Block Categories) Commands Available to use Script Area where you type your code Sprite Stage All sprites in this project.
Coding Practices. What are Coding Practices ? Coding practices are a set of informal rules that the software development community has learned over time.
CS 898N – Advanced World Wide Web Technologies Lecture 8: PERL Chin-Chih Chang
Bellevue University CIS 205: Introduction to Programming Using C++ Lecture 3: Primitive Data Types.
Computer Programming and Basic Software Engineering 4. Basic Software Engineering 1 Writing a Good Program 4. Basic Software Engineering 3 October 2007.
CSE1301 Computer Programming: Lecture 13 Documentation.
Computer Science 1620 Programming & Problem Solving.
Mr. Wortzman. Tabs (Block Categories) Available Blocks Script Area Sprite Stage All sprites in this project.
Group practice in problem design and problem solving
What is RobotC?!?! Team 2425 Hydra. Overview What is RobotC What is RobotC used for What you need to program a robot How a robot program works Framework.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
สาขาวิชาเทคโนโลยี สารสนเทศ คณะเทคโนโลยีสารสนเทศ และการสื่อสาร.
Design-Making Projects Work (Chapter7) n Large Projects u Design often distinct from analysis or coding u Project takes weeks, months or years to create.
Introduction to Python
Chapter 5: Control Structures II (Repetition)
CHAPTER 5: CONTROL STRUCTURES II INSTRUCTOR: MOHAMMAD MOJADDAM.
General Programming Introduction to Computing Science and Programming I.
CS 325: Software Engineering March 24, 2015 Implementation Considerations Coding Standards Pair Programming Test-Driven Development.
1 CSC 221: Computer Programming I Spring 2010 interaction & design  modular design: roulette game  constants, static fields  % operator, string equals.
Software Construction and Evolution - CSSE 375 Software Documentation 2 Shawn & Steve Left – Ideally, online documents would let you comment and highlight,
Python Programming Chapter 6: Iteration Saad Bani Mohammad Department of Computer Science Al al-Bayt University 1 st 2011/2012.
IT253: Computer Organization Lecture 3: Memory and Bit Operations Tonga Institute of Higher Education.
1 ENERGY 211 / CME 211 Lecture 26 November 19, 2008.
Programming for Beginners Martin Nelson Elizabeth FitzGerald Lecture 5: Software Design & Testing; Revision Session.
Agile Planning. The problem with documentation Argument: “Heavy” documentation too much for most business-style projects.
Chapter 5: Control Structures II (Repetition). Objectives In this chapter, you will: – Learn about repetition (looping) control structures – Learn how.
Current Assignments Homework 2 is available and is due in three days (June 19th). Project 1 due in 6 days (June 23 rd ) Write a binomial root solver using.
CPS120: Introduction to Computer Science Lecture 14 Functions.
CMPSC 16 Problem Solving with Computers I Spring 2014 Instructor: Lucas Bang Lecture 5: Introduction to C: More Control Flow.
Self-Documenting Code Chapter 32. Kinds of Comments  Repeat of code  Explanation of code  Marker in code  Summary of code  Description of code’s.
Loops (cont.). Loop Statements  while statement  do statement  for statement while ( condition ) statement; do { statement list; } while ( condition.
_______________________________________________________________________________________________________________ PHP Bible, 2 nd Edition1  Wiley and the.
CS161 Topic #16 1 Today in CS161 Lecture #16 Prepare for the Final Reviewing all Topics this term Variables If Statements Loops (do while, while, for)
Computer Programming with JAVA Chapter 8. Exception Handling Basic Exception Handling the mechanics of exceptions Defining and Using Exceptions some "simple"
Revealing the Secrets of Self-Documenting Code Svetlin Nakov Telerik Corporation
Matlab tutorial course Lesson 4: Writing your own functions: programming constructs
M1G Introduction to Programming 2 3. Creating Classes: Room and Item.
Fast SLAM Simultaneous Localization And Mapping using Particle Filter A geometric approach (as opposed to discretization approach)‏ Subhrajit Bhattacharya.
Searching CSE 103 Lecture 20 Wednesday, October 16, 2002 prepared by Doug Hogan.
Efficiently Solving Computer Programming Problems Doncho Minkov Telerik Corporation Technical Trainer.
BIT 115: Introduction To Programming Professor: Dr. Baba Kofi Weusijana (say Doc-tor Way-oo-see-jah-nah, Doc-tor, or Bah-bah)
Memory Management Chapter 5 Advanced Operating System.
Announcements Assignment 2 Out Today Quiz today - so I need to shut up at 4:25 1.
Today… Modularity, or Writing Functions. Winter 2016CISC101 - Prof. McLeod1.
Implementation Topics Describe –Characteristics of good implementations –Best practices to achieve them Understand role of comments Learn debugging techniques.
Introduction to Computing Science and Programming I
C++ coding standard suggestion… Separate reasoning from action, in every block. Hi, this talk is to suggest a rule (or guideline) to simplify C++ code.
Communicating in Code: Commenting
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
Optimizing Malloc and Free
Communicating in Code: Layout and Style
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
Communicating in Code: Commenting
Coding Concepts (Basics)
Maintaining a Program In today’s lesson we will look at:
Subject:Object oriented programming
Chapter 9: Implementation
Presentation transcript:

Communicating in Code: Commenting Programming Studio Spring 2009 Note: several examples in this lecture taken from The Practice of Programming by Kernighan and Pike

Comments An internal documentation mechanism –Documentation of the code stays with and close to the code Comments should complement good coding style, not replace it –The better written your code, the fewer comments you will need Poor commenting is a waste of time and sometimes harmful.

What Comments are Not Design documents

What Comments are Not Design documents API references

What Comments are Not Design documents API references Specifications

What Comments are Not Design documents API references Specifications Padding to increase your “lines of code”

What Comments are Not Design documents API references Specifications Padding to increase your “lines of code” Places to tell jokes to future programmers

Types of Comments Repeat of the Code –Repeating what code does or stating the obvious is useless //loop through all Teams for(i=0;i<NumTeams;i++) //add that team’s players to total TotalPlayers += Team[i].NumPlayers;

Types of Comments Repeat of the Code –Repeating what code does or stating the obvious is useless //Find total number of players in league for(i=0;i<NumTeams;i++) TotalPlayers += Team[i].NumPlayers;

Types of Comments Explanation of the code –Can be a sign that the code is difficult to understand –Don’t comment bad code – rewrite it –If the explanation is too long, code should be rewritten /* Update the attenuation due to multiple scattering whenever there is a valid layer hit. The next intersection layer hit will be skipped over and the intersection point will generate a new vector and the last vector created will be stored */ for(i=IntersectLayer-1;i<NumLayersHit;i++) { if (isValidHit(r)) { Attenuation.Update(Layer[i++].HitPoint(genVector(r))); }

Types of Comments Marker in the Code –Used as notes to the developer //***** FIX THIS ROUTINE Often have key phrases to search on –Used to visually separate code blocks As a style element, e.g. function header blocks

Types of Comments Summary of the code –Short statement summarizing several lines of code. –Useful for quick scanning over code to find areas where things are happening –Provides a global “map” to the code

Types of Comments Description of the code’s intent –Best type – explains the why, not the how –Comments should add something that is not immediately evident from the code –Understanding the intent of code is usually the issue – it’s much easier to tell exactly what the code is doing.

Things to Comment Functions Global variables –Can be tough to keep track of Code that is truly complicated –Might require lots of explanation, references to algorithms

Maintaining Comments Comments need to be maintained as code is edited! –Conflicts between comments and code cause tremendous difficulty –Commenting styles can assist with maintenance /*************************/ /* */ /* My comments */ /* */ /*************************/

Maintaining Comments Comments need to be maintained as code is edited! –Conflicts between comments and code cause tremendous difficulty –Commenting styles can assist with maintenance /************************* * * * My comments * * * *************************/

Maintaining Comments Comments need to be maintained as code is edited! –Conflicts between comments and code cause tremendous difficulty –Commenting styles can assist with maintenance /************************ * * My comments * ************************/

Maintaining Comments Comments need to be maintained as code is edited! –Conflicts between comments and code cause tremendous difficulty –Commenting styles can assist with maintenance /************************ My comments ************************/

Maintaining Comments Comments need to be maintained as code is edited! –Conflicts between comments and code cause tremendous difficulty –Commenting styles can assist with maintenance Blocks of comments Lining up comments

Maintaining Comments Difficulty lining up comments: int Capacity; // Number of cats we could keep int NumCats; // Number of cats in the house float CatFood; // Monthly cost of cat food

Maintaining Comments Difficulty lining up comments: int Capacity; // Number of cats we could keep int NumCats; // Number of cats in the house float CatFood; // Monthly cost of cat food float BoardingCosts; // Cost to board cats per day

Maintaining Comments Difficulty lining up comments: –Difficult to maintain over time, so tend to degrade with modification –Leaving enough space often leads to short comments

Maintaining Comments Comments often last –Don’t use comments you don’t want others to see –Don’t expect comments to really be “temporary” –If markers are left in code, be sure they will be found

More Commenting “DON’Ts” Don’t include useless comments MOV AX, 723h ; R.I.P.L.V.B

More Commenting “DON’Ts” Don’t include useless comments MOV AX, 723h ; R.I.P.L.V.B (Beethoven died in 1827 = 723h)

More Commenting “DON’Ts” Don’t include useless comments Avoid endline comments –For one line of code, tend to be repetitive not much to say about one line of code –For multiple lines of code, tend to be difficult to match Which lines does the comment “belong” to? –Difficult to say too much Not much room

More Commenting “DON’Ts” Don’t include useless comments Avoid endline comments Don’t use too many comments –Can actually obscure the code itself! –No set “ideal”, but one comment about every 10 lines or so is probably right.

Commenting “DOs” Write code at the level of intent /* Check each character in “inputstring” until a dollar sign is found or all characters have been checked */ done = false; maxLen = inputString.length(); i = 0; while ( !done && (i<maxLen) ) { if ( inputString[i] == ‘$’ ) { done = true; } else { i++; }

Commenting “DOs” Write code at the level of intent /* Find ‘$’ in inputString */ done = false; maxLen = inputString.length(); i = 0; while ( !done && (i<maxLen) ) { if ( inputString[i] == ‘$’ ) { done = true; } else { i++; }

Commenting “DOs” Write code at the level of intent /* Find the command-word terminator ($) */ done = false; maxLen = inputString.length(); i = 0; while ( !done && (i<maxLen) ) { if ( inputString[i] == ‘$’ ) { done = true; } else { i++; }

Commenting “DOs” Write code at the level of intent Use comments to prepare the reader for what is to follow –May not understand why things are being set up in one area for later use –Comments should precede statements they comment on.

Commenting “DOs” Write code at the level of intent Use comments to prepare the reader for what is to follow Document surprises not obvious in the code for(element=0; element < elementCount; element++) { // Use right shift to divide by two. Substituting // right-shift operation cuts loop time by 75% elementList[element] = elementList[element] >> 1; }

Commenting “DOs” Write code at the level of intent Use comments to prepare the reader for what is to follow Document surprises not obvious in the code Avd crypt stats. and abbr.

Commenting “DOs” Write code at the level of intent Use comments to prepare the reader for what is to follow Document surprises not obvious in the code Avoid cryptic statements and abbreviations

Commenting “DOs” Write code at the level of intent Use comments to prepare the reader for what is to follow Document surprises not obvious in the code Avoid cryptic statements and abbreviations Comment about anything that is used to avoid an error or an undocumented feature –Prevents that code from being accidentally deleted!

Other Commenting Suggestions Comment units for numeric data Comment ranges of allowable values Comment limitations on input data Document flags to the bit level Be sure comments stay associated with what they comment –avoid separating comments about a variable from the variable

Commenting Control Structures Comments before loops and large blocks are natural Comment to identify the end of control structures, especially when end is far separated from beginning

Commenting Functions Input required –Restrictions/ranges Output produced Side effects and global effects Limitations of the routine Sources for algorithms implemented