Differences

This shows you the differences between two versions of the page.

Link to this comparison view

cs-142:approachtoprogrammingdetail [2015/01/07 16:18] (current)
ryancha created
Line 1: Line 1:
 +===A little more detail===
  
 +1. Understand the problem and create test cases
 +* If you don't do the test cases first, you risk having to completely rewrite your code when you discover that it only works for a few of the possible inputs.
 +* Good test cases explore an example from all the possible "​classes"​ of inputs. For example, if your program asks for the user to input a string, how does it handle a string of length 1? A string with spaces? A string with numbers? You need to thoroughly consider what the input ''​could be''​. As you do this, it will help generalize your solution to encompass all of the possible test case inputs. Again a test cases is a ''​specific example''​ from the class of inputs that it represents, not a description of the class of inputs.
 +2. Think about how you as a human would solve the problem. Break your solution down into small, unambiguous,​ steps in plain English. Write those steps in plain English in comments in the body of your main method
 +* Dr. Seppi'​s example of providing instructions to write his name on the whiteboard might seem tedious, but this is exactly the level of detail that you need to be thinking at for a computer.
 +* If you can't write it down in English, you probably don't understand the problem well enough
 +* Writing comments before you code is an extremely helpful technique for organizing how you approach your implementation.
 +3. Identify logic structures, data types and structures, and functions (Have to know the structures and types)
 +* Most of this class is aimed at helping you understand the tools that you have at your disposition. It is just as important to know ''​when''​ to use a tool as it is to know ''​how''​ to use a tool.
 +* Perhaps try thinking backwards: instead of saying how can I use a loop to do this, say, "I can use a loop to do x, can I make my problem solution look like x?"
 +4. Code incrementally (based on specification)
 +* Build the simplest functioning program ("​Hello TA") and then use the Lab requirements (or other small checkpoints) to add functionality,​ testing that it still works at each step.
 +5. Use correct formatting and proper naming
 +* Formatting is not just so that it looks good. It makes the logical flow of your program painstakingly obvious. Many of the errors observed in CS 142 could be avoided simply by proper indentation,​ brackets on every ''​if''​ and ''​else'',​ and using variable names that are easy to understand.
cs-142/approachtoprogrammingdetail.txt ยท Last modified: 2015/01/07 16:18 by ryancha
Back to top
CC Attribution-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0