Labs

General

The labs make up a significant portion of both your final grades. You must complete each one (even for zero credit) to pass the course. A disciplined approach to design, implementation, and testing are key to your success! Wiring and coding the entire lab and then trying to figure out why it doesn't work (they almost never do) can be incredibly painful and time-consuming. Our experience shows that students who get behind on the labs need to catch up immediately, else the burden of uncompleted labs builds to inescapable levels.

Lab Notebooks

Lab notebooks are heavily emphasized in this course and constitute a large portion of lab grades. The lab notebook is maintained as a journal of your lab experience and should allow you, or any knowledgeable engineer, to recreate your project. For this course, your notebook should contain at least the following (as applicable to the particular lab):

• Descriptive title
• Objectives or purpose
• Prelab
• Preliminary design
• Software flow chart / algorithms
• Hardware schematic
• Well-formatted code
• Debugging
• Testing methodology / results
• Observations and Conclusions
• Documentation

The actual format is flexible, so don't be afraid to add something later. All lab reports must stand up to the "hit by a bus" standard. Should you die, another engineer must be able to continue your work without trouble.

You are expected to keep your lab notebooks current as you work on a lab. You will lose substantial points if sections of the lab notebook which should be part of your documentation before the demonstration (such as prelab, approach, flowcharts, testing, debugging, etc.) are entered afterwards. Your conclusion section, lessons learned, and your final formatted code are not required before your demo.

Electronic Lab Notebooks

In this class, we will use an electronic lab notebook. We'll be using the version control software git and your code must be hosted on Bitbucket. Here is the directory structure that must be used if you have more than one code file or more than one image file to be uploaded for a single lab:

• /LabX (Project Folder for Lab, Homework, or Lecture)
  • /code (Do not create a code folder in the project folder. It is easier to create your Git repo in the same folder you keep your code projects)
    • Leave the code where the IDE puts it within the project folder and don't move the code around.
  • /images
    • Include all images you use in your notebook here
  • /docs
    • Include this if you are adding other documents to your project
  • README.md
    • Lab notes not included in your git commit history
    • If you name the file README.md it will be previewed in the git folder when looking at the code.

CSCE 436 Lab Notebook Example - https://github.com/jfalkinburg/CSCE_436_Lab_Ex

Your commit history will be used as verification that you've been keeping your lab notebook up to date as you progress. You should commit early and often.

You'll still need to hand in certain assignments online on Canvas so I will know your achieved functionality and can record grades and feedback for you.

Coding Standards

General

You are expected to use the same structured programming techniques that you were taught in CS155.

You must comment your code where appropriate. This doesn't mean commenting every line you write - that's distracting and unproductive. Comments should be used to convey the general purpose of a block of code or explain a section that may be unclear. You can assume the reader is a knowledgeable engineer.

Use meaningful, readable variable names - variable1 or var1 or loop1 or L1 are unacceptable.

Don't repeat yourself! If you find yourself using the same code over and over, you should abstract it into a subroutine or function.

Code Headers

For each coding file submitted in your lab notebook, ensure you have a header that includes your name, the date, the assignment, a brief purpose of the code, documentation for that specific file, and the academic statement.

For each subroutine you use, include a header just above the subroutine's location. Ensure the author, function, inputs, outputs, and destroyed registers for that subroutine are included in the subroutine header.

--------------------------------------------------------------------
-- Name:	<Your Name>
-- Date:	<The date you stated working on the file>
-- Course:	<The course's name>
-- File:	<This file's name>
-- HW:		<HW# and name>
--
-- Purp:A brief description of what this program does and 
--	the general solution strategy. 
--
-- Doc:	<list the names of the people who you helped>
-- 	<list the names of the people who assisted you>
--
-- Academic Integrity Statement: I certify that, while others may have 
-- assisted me in brain storming, debugging and validating this program, 
-- the program itself is my own work. I understand that submitting code 
-- which is the work of other individuals is a violation of the honor   
-- code.  I also understand that if I knowingly give my original work to 
-- another individual is also a violation of the honor code. 
-------------------------------------------------------------------------