Question: How similar is the code for the KnowFlow and the RIFFLE data loggers?

I'd guess that there could be a lot of commonality in cases where you want to set up the same sensor on either device (or any Arduino). It could be really helpful for each team to clearly mark the sensor-specific code so that it can easily be re-used across!

Teams? There are going to be teams? Will they have T-shirts?

I'm still not sure overlapping code is relevant. If you have a working sketch for a KnowFlow and you want to start programming a Riffle, you don't start with the KnowFlow sketch. You find your friend's sketch for the Riffle and change what needs to be changed (hardware libraries, hardware initiations, hardware reads, sampling interval, variable names, pin assignments) depending on how your friend's hardware and goals differ from yours. If your Riffle uses the same sensor or RTC as your KnowFlow, you might be able to borrow a few lines of code.

Hey Chris - yep, the different groups developing these projects; i'd love to design t-shirts!

Modularizing and annotating code can go a very long way to ensuring reusability across platforms. If each team keeps their sensor-specific code clearly separated from the data-logging code, reusability should be possible.

I'm happy to help with this -- some approaches are:

• use comment lines to mark sensor-specific sections of code: // -------- start conductivity probe code ---------- //
• group code by purpose, and maintain a consistent API (say, wrap code in a function with named parameters) so that copying it into another file is easier, and you don't have to disentangle board-specific bits, so instead of a series of interleaved statements, you can use a standard function like getConductivityData()
• you can separate code out into different files, which adds a little complexity in one sense, but helps maintain modularity and makes copying much easier

If we can list the different code examples we're working with here, i'm happy to suggest (and contribute pull requests for!) ways of modularizing!

Well-commented code is always helpful. At the novice level at which I work, good comments are sometimes hard to come by. I have often stolen uncommented code from the internet that works perfectly and I have no idea what it does.

One behavior to encourage is to include a URL for the libraries your sketch needs. People fork libraries all the time and often don't change the name. Some of my sketches use libraries which I would be hard-pressed to find again on the internet because there are several with the same name. Here is the library section of a sketch for the Nano Data Logger.

#include <SdFat.h> // https://github.com/greiman/SdFat
#include <SPI.h> // https://www.arduino.cc/en/Reference/Libraries
#include <Wire.h> // https://www.arduino.cc/en/Reference/Libraries
#include <RTClib.h> // https://github.com/adafruit/RTClib
#include <Adafruit_BME280.h> // https://github.com/adafruit/Adafruit_BME280_Library
#include <mlx90615.h> // https://github.com/skiselev/MLX90615/archive/master.zip
#include <LiquidCrystal_I2C.h> // https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads

Great suggestions, Chris. Also:

I have often stolen uncommented code from the internet that works perfectly and I have no idea what it does.

This is more or less the idea behind a stable API -- you don't have to know how it works inside the box, as long as you can rely on it working the same way. If you were relying on a library in this way, and the author changed what it did, they'd be breaking the API, rendering your "downstream" code useless.

Some of the best comments can clearly delineate what a block of code does as it's "external interface" without having to go through explaining every line. Then anything inside that block could be changed, as long as it fulfills that external promise.

Cool. We'll have to get a third answer or Gretchen won't know what to think.

OMG, the image layout is horrible from my laptop, help needed @warren

:-) sorry, i'll push a new change which will fix this in a bit!

Fixed! Thanks for finding this issue!

Thanks!!!!!

the pic is great. crystal!