Adventures in Science: Arduino Conditional Statements

Amazing and cool information. Thanks for sharing.

I think you've hit many of the core ideas. As a software engineer, a few things I find will help reduce bugs in code:

• As mentioned elsewhere, putting constants on the left side of your conditional can help catch some errors (for instance, 7 = a rather than a = 7). This is more obvious to a human eye and compilers can flag this error.

• Put the shorter condition block first. Rather than:

  if (condition) {
      // Really
      // Long
      // Complex
      // Block
      // Of
      // Code
  } else {
      // Short block
  }
  

  Instead do:

  if (!condition) {
      // Short block of code
  } else {
      // Really
      // Long
      // Complex
      // Block
      // Of
      // Code
  }
  

• I have watched new programmers learn conditionals, exercises are crucial to this process. In other words, definitely yes to the home works.

I wanted to let you know that I am using your videos as part of the summer classes that I am doing for a High School First Robotics team. So keep churning them out :)

What I am doing with this summer session is using the Arduino as a simple hard to mess up C++ programming environment. So I am going to do doing lessons on Pointer,Classes and, Algorithms and such. I hope to get the students to produced more structured programs, with the thought in mind that from an education point of view a FRC robot could implemented with an Arduinio controlling each of various subsystem (ball pick up, shooter, etc) but to do that we need to get a lot more kids up to speed on programming.

A few things from my experiences:

1. When compilers convert the C/C++ to ASM, they will do things to optimize the pipeline of the instruction set. As an example, if you do if ( A == B) {..}, the compiler might actually do if (B != A) {...). (If you haven't guessed, they're the OPPOSITE of each other). This helps save on the JMP commands used (waiting a few clock cycles to go from one point of the ASM to another).
2. Always have an "else" statement. This goes along my digital logic background that it creates latches if you don't have a "default" conditional, and if you don't have one, that means your conditionals have to handle ALL possible conditions, and if you don't know the conditions of the data, have an else there to save you the headache of losing data, and possibly having improper data print out.
3. If you have far too many if-statements in a row, you should look into using a switch/case to simplify your code (and helps the compiler optimize it).

My biggest issue with the homework of online classes is they do not show you the bigger picture of when to use certain key features of the language. Why use an if-statement, when a unary/ternary statement can do the same thing? The times I learned a language the best was when I was given a practical application in which to code. This helps teach the specific aspects of the syntax you want to teach, but also teaches the students to test their code. Plus, as they get more familiar with the code and application, they can start doing coding optimizations themselves to meet certain specifications of the design.

I think a playlist with a companion set of 'homework' problems would be nice. It's always easier for me to learn by doing. Perhaps a basic set of problems and one 'extra credit' challenge per video would work. You could discuss the solutions on the next video in the series.

A small critique on the video: prior to discussing the operators, there were a few seconds of blank screen, and I had to check to make sure my video was still playing. Perhaps a background image could be used instead of a blank, black screen.

Overall I think the videos are worth continuing. Good job!