ENGR 2110 - Principles of Engineering

Profs. Millner, Faas, Minch & Reifel

Fall 2018

Lab Report Style Guide


The following guidelines are strong suggestions for formatting your lab reports. Should you find that another way of reporting conveys the information better, you have flexibility to discuss such approaches with the instructor and/or NINJAs. However, it is worth noting that in grading your lab, we refer to these guidelines.

In general, a good lab report should document what you did to complete the lab and should stand on its own. It should not be necessary for the reader to know the details of the assignment in order to make sense of what you’ve written. Using only your report, a hypothetical Olin student with a skillset similar to yours should be able to reproduce your work and understand why you made the design decisions you did. The report should be both well written (e.g., free of grammatical errors and of spelling mistakes) and concise.  It should include a brief narrative description of what you actually did (e.g., the procedure that you followed, any difficulties you encountered along with steps you took to remedy them).  Source code and a schematic should also be included.  Finally, your report should include a brief reflection on your experience in doing the lab.

Including Source Code

Your report should include a listing of the commented source code along with a brief description of what the code does as it executes and how it works. Sometimes the formatting of source code can make it difficult to read. There are a number of “code beautifiers” out there that can help like the Pretty Printer or Uncrustify. Pasting your Arduino source into the window and selecting your formatting options will generate tidy code with syntax highlighting and line numbers for convenient reference in the rest of your text.

Including Circuit Diagrams

Your report should include a schematic for your circuit along with a brief explanation of any specific decisions you made. One very useful, online, browser-based tool for making circuit diagrams is Digi-Key’s Scheme-it.


Each lab team should submit a single joint report that has been prepared collaboratively, with contributions from all members of the team.  Labs should be submitted electronically via email to the email address poe.submit@gmail.com by the date and time specified. Please submit the report as a pdf file attached to the email, to make it easier for the NINJAs to return it with comments. The subject line of your email should indicate your section number, the lab number, and your team members’ names, eg. “Section , Lab 1- Amon and Daniela.”


We encourage you to use both first-person pronouns and the active voice in your reports. For example, you should say “we built the circuit in a solderless breadboard as shown in Fig. 1.2 in the lab handout” rather than “the circuit was built as shown in Fig. 1.2 in the lab handout”.  You should never mix the active and passive voices in the same sentence, which many people consider to be a grammatical error. For example, you should not say “Using the schematic provided in Fig. 1.2 of the lab handout, the circuit was built”, which effectively mixes the active and passive voices.  Figures should be floating bodies with proper captions that include a number and you should refer to them in the text by that number rather than by adjectives that describe where the figure is relative to where the text appears that describes it. For example, rather than saying the circuit is shown below you should say something like the circuit is shown in Figure X. Relatively short code listings can be treated as displays/block quotes or as floating bodies, whichever you prefer. Longer code listings should be included in appendices at the end of your report.