Project submission checklist

 

---

1. Extended write-up with these parts:
   
   
   1. Title: A short title indicating the topic.
   2. Synopsis: up to 4 sentences telling what your project does. (you may reuse what you submitted for the project gallery.)
   3. Extended abstract: (<=300 words) The abstract should give a very clear brief high-level description of the problem you're addressing and how you solve it. Assume the audience is not an expert in your subject area. Use a spelling-checker! See examples.
   4. Pseudocode: Pseudocode for the problem described in the previous step. Use pseudocode keywords and keep level of detail broad.
   5. Acknowledgements: Acknowledge help received writing the code or any scripts you used which were authored by others (aside from course examples)
   6. Keywords: Comma separated list of keywords relating to the project. These should include topic area, data types, and tools. This is meant to help other students search for related project topics.
   7. Mapping: One or two sentences explaining how you used the mapping module and what is automatically added to the map.
   8. GUI: A screenshot of your graphical user interface and a table with a list of parameter (should have the same columns as in the revised proposal: Parameter, Data Type, Type (Required, optional, or derived), Direction, Filter. See the extended proposal instructions for an example.)
      
      
2. Presentation with two parts:
   1. Presentation 1: Explain the project(<= 5 minutes)
      --File should be named: unityID_Pres1
      --Describe the problem the code solves (screen recording with voiceover). Be clear, concise, and creative.
      --Include a checklist of the required components (see Code Evaluation part I below). List how the requirement was met --or why it was not.
      --If applicable, note any advanced funtionality Python that you used beyond the requirements or requiring the study of Python functionality beyond the course material.
      
   2. Presentation 2: Prerecorded demo (<=5 minutes)
      --File should be named: unityID_Pres2
      -- Introduce the project topic very briefly--give the project title and the goal of the project in 1-3 sentences (and a picture, if possible).
      -- Demonstrate how to run the code. During this video, run the code, starting with the GUI. Make sure to show the button (if applicable), the interface, and the results being added automatically to the map.
      -- Tell us about any extra functionality you've learned and implemented. This is your chance to brag.
      -- Both distance and traditional students prerecord a video.  Jing recommended for free video screen capture.
      
      
3. Map files, scripts, toolboxes, test data any other supporting files needed to test the code. Test data should not be massive. If the data is massive, please submit only a small dataset. Please indicate any privacy restrictions on the data, otherwise, it may be made publicly available.
   1. Set default values in the graphical user interfaces so that we can run your code without assistance.
   2. Check for portability (if I move it to another machine, does it break?)
      
      
4. Code checklist
   
   1. Implement instructor feedback from proposal (and extended proposal) submissions.
   2. Code components:
      Category I (Complete all of a-f for this category)
      
      
      1. Python geoprocessing (call arcpy tools).
         
         
      2. Python batch processing (FOR or WHILE loops)
         
         
      3. Code reuse: Define and call at least 3 user-defined reusable functions. Remember not to use functions presented as examples and not to create functions that are simply wrappers for geoprocessing tools.
         
         
      4. Code reuse: Define a class and instantiate and use an object of this type.
         
         
      5. Mapping: Automatically display geoprocessing output in the map. (If the output is better viewed outside of ArcMap, you must still display it automatically. But also show messages so that the user knows how to find and display the visual output in a more appropriate viewer.)
         
         
      6. GUI: Use Python script tools and script tool properties to generate an graphical interface.
      Category II  (Pick one or more)
      
      
      7. Reading and/or writing files with standard file objects or with cursors.
         
         
      8. Reading and/or writing HTML to automatically generate an output report.
         
         
      9. Reading and/or writing KML with BeautifulSoup.
         
         
      10. Downloading and uncompressing data from the web.
      
      

      Category III  (Pick one or more--these are easier and don't carry as much weight as Cat II)

      11. Use the tool validator to create dynamic behavior for the script tool.

      12. Provide a portable toolbar button to launch the script tool.

      13. Inform the user of progress, using messages.

      14. Add the arcpy progressor to present messages.

      15. In the script tool, use the parameter filter property, the paramater "obtained from" propery, the parameter symbology property, or the Schema property.
          
          
5. Programming style:
   1. Provide a valid usage example in the header comments.
   2. Use of variables instead of repeating string literals;
   3. Minimize hard-coding. File paths should not be hard-coded.
   4. Mulitiple lines of code that are invoked more than once with only slight variation should be put into a function with the variations passed in as parameters. In other words.
   5. Use conditional expressions efficiently (e.g., if foo.endswith("bla") instead of if foo.endswith("bla") == True)
   6. Use conditional blocks efficiently (e.g., use elif/else when they can be used instead of sequential if/if/if)
   7. Only import modules and packages that are being used.
   8. Use of data structures such as lists/dictionaries to streamline code (instead of long if/elif/elif/elif... blocks.)
      
   9. Lightly commented but also self-documenting (easy to guess what's happening)
   10. Use modules to group tightly related function facilitate reusability.
   11. Avoid use of 'magic numbers' -- hard-coded numbers unique values with unexplained meaning and/or multiple occurrence which could (preferably) be replaced with meaningfully named variables.
   12. Catch exceptions to avoid traceback exceptions in case of user input mistakes or data availability/corruption issues.
   13. Lines of code <=90-ish characters each. Achieve this by using variables to hold long string arguments and using line continuation symbols as needed.
   14. Use a docstring inside the start of each function and inside the start of each class.