DATA STRUCTURES

1
DATA STRUCTURES

• CS 122
• Washington State University
• Spring 2009
• Dr. Sarah Mocas

2
Lecture 1

• Now is the time to learn to write GOOD code!
• Programs will be graded down for bad style.

http//www.flickr.com/photos/davesag/8519770/
3
Lecture 1

• Start now and avoid a lot of hassle later
• Avoiding the high cost of bad code
• too many developers involved in a project, may
  not be around later to maintain the code they
  wrote
• "The further along a project gets, the harder it
  is to understand what the original intent was,"
• "Developers often don't know how the entire
  system is supposed to be organized or how parts
  of the system should depend on other parts of the
  system,"
• "In general, less than 40 percent of software
  projects meet the desired goals that were set
  out,"
• http//www.infoworld.com/article/09/01/07/01NF-cod
  e-management_1.html

http//www.flickr.com/photos/davesag/8519770/
4
Lecture 1

• Why Is So Much Code So Bad?
• I've been in the position to read a lot of code
  written by many different developers. And most of
  it is terrible.
• 1) There are sloppy and lazy programmers out
  there who are just bored or otherwise
  uninterested in there jobs. Why can some
  mechanics fix that noise when others can't? 2)
  MANAGERS and unreasonable DEADLINES. I don't know
  about any of you but I am never done with a
  project. I am picking through code up until the
  very end, and even then it is never done to my
  liking!  
• http//weblogs.asp.net/wallen/archive/2003/12/11/
  42935.aspx

http//www.flickr.com/photos/davesag/8519770/
5
Lecture 1

• Why Is So Much Code So Bad?
• Most people write bad code for several reasons --
  be it a bad design, insufficient knowledge,
  boredom, or plain simple stupidity. However, from
  what I have seen, programmers who think through
  the problem before writing even a single line of
  code, code better on an average. Also,
  programmers who can think of programming without
  associating it with a language do write better
  code. These are the folks that think in terms of
  algorithms before thinking in terms of code.
• http//weblogs.asp.net/wallen/archive/2003/12/11/
  42935.aspx

http//www.flickr.com/photos/davesag/8519770/
6
Lecture 1

• Why Is So Much Code So Bad?
• Honestly, here goes.  People skip the basics.  Do
  they learn programming logic first?  If not do
  they go back and pick up a book on generic logic?
   I know many programmers that have years of skill
  sets and projects completed, that all say...I
  would have done that so different, or been
  faster, made less mistakes if only I learned or
  read this years ago.  Also the advent of the
  script kiddy.  "This looks good, so lets copy and
  paste"  It was not honestly good, you just did
  not know any better.
• Programmers and coders also need to start looking
  at the bigger picture more often.  Security is
  not a check box.  
• http//weblogs.asp.net/wallen/archive/2003/12/11/4
  2935.aspx

http//www.flickr.com/photos/davesag/8519770/
7
Lecture 1

• C Code Style Guidelines
• Tia Newhall, Associate Professor, Swarthmore
  College
• Use good modular design.
• Think about what functions and data structures
  you need before you start writing code.
• Use good error detection and handling.
• Always check return values from functions.
• Handle errors appropriately
• SEGFAULT is not appropriate error handling

http//www.flickr.com/photos/amandavivan/229729721
3/
8
Lecture 1

• Every time you dynamically allocate memory (e.g.
  call malloc), you should have code to free this
  memory at some other point in your program.
• General guide, no function should be longer than
  one page.
• Exceptions should truly be the exception.

9
Lecture 1

• Use descriptive names for variables, functions,
  and constants
• Don't use long names, but they should be
  descriptive
• for a function that returns the radius of a
  circle
• use "getRadius" or "get_radius"
• rather than "foo"
• Stick with C-style naming conventions
• i and j for loop counter variables

10
Lecture 1

• Pick a capitalization style for function names,
  local variable names, global variable names, and
  stick with it.
• For example, for function names do
• "square_the_biggest" or
• "squareTheBiggest" or
• "SquareTheBiggest"

11
Lecture 1

• Define Constants and use them in your program
  rather than numerical values.
• Makes your code readable, and easier to change
• Example If MAX should be 100 instead of 50, just
  change the constant definition rather than
  finding all uses of 50 in your program.
• Do this
• define MAX 50
• int bufMAX
• if( i
• Not this
• int buf50
• if( i

12
Lecture 1

• Avoid using global variables instead, pass
  variables by reference to functions that change
  their value.
• The main function should not contain low-level
  details. It should be a high-level overview of
  your solution (remember top-down design).

13
Lecture 1

• Use good indentation
• Bodies of functions, loops, if-else stmts, etc.
  should be indented
• Statements within the same body-level should be
  indented the same amount
• int blah(int x, int y)
• stmt1
• while (...)
• stmt2
• if(...)
• stmt3
• else
• stmt4

14
Lecture 1

• Line Length your source code should not contain
  lines that are longer than 80 characters long.
• If you have a long line, break it up into
  multiple lines.
• Comment your code!
• File Comments Every .h and .c file should have a
  high-level comment at the top describing the
  file's contents, including your name(s) and the
  date.

15
Lecture 1

• Function Comments Every function (in .h and .c
  files) needs comments describing
• what function does
• its parameter values
• its return values (including values to indicate
  errors).
• Header files - function comments for the
  interface user
• Source file - function comments for the
  implementation of the function.
• If a function implements a complicated algorithm
  - describe the main steps of the algorithm.

16
Lecture 1

• Some steps in software development process
• Goals and Requirements
• Specification
• Implementation
• Testing

http//www.flickr.com/photos/eggplant/4492334/
17
Lecture 1

• Specification is driven by goals requirements
• Must spell out desired behavior, user interface
• Implementation is driven by specification
• Program structure should reflect problem
  structure
• Testing is critical part of software development
• Test suite is set of test cases designed to
  exercise all parts of program
• Pay special attention to extreme cases