user70516: I am actually wondering if there's a way to efficiently do this block of code. There are two things in my specifications and these are:

Four IR Sensors that detects blockage. Basically just to trigger it HIGH or LOW
Once one of the sensors got tripped/triggered, it sends a Serial output

In order to do that, I made this code. Basically just stuffing digitalRead and their if conditions in the loop. Is there any way to make the code shorter all the while make it faster for the Serial to get sent?
#define IRSignal1 2
#define IRSignal2 3
#define IRSignal3 4
#define IRSignal4 5

int IRVal1;
int IRVal2;
int IRVal3;
int IRVal4;

void setup() {
  // put your setup code here, to run once:
  pinMode(IRSignal1, INPUT);
  pinMode(IRSignal2, INPUT);
  pinMode(IRSignal3, INPUT);
  pinMode(IRSignal4, INPUT);

  Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
  IRVal1 = digitalRead(IRSignal1);
  IRVal2 = digitalRead(IRSignal2);
  IRVal3 = digitalRead(IRSignal3);
  IRVal4 = digitalRead(IRSignal4);

  if (IRVal1 == LOW) {
    Serial.print('1');
  }
  if (IRVal2 == LOW) {
    Serial.print('2');
  }
  if (IRVal3 == LOW) {
    Serial.print('3');
  }
  if (IRVal4 == LOW) {
    Serial.print('4');
  }
}

If you have tips, or a go-to resource for efficient coding practices that also helps with memory allocation, shorter code, and speed, I would also love to hear them if that's alright with you.
I use both arduino mega and uno in case this information is useful.

user7508: As others have noticed, this code will be more than fast enough for
its intended purpose, so you should not feel obliged to optimize it
further. That being said, I do see an inefficiency that you may be
interested in hearing about, hence this answer.
If an IR sensor turns LOW and stays LOW, the program will send the
appropriate message repeatedly, as fast as it can. Since the code runs
way faster than the serial port, this will soon fill up the serial
port's output buffer. When this happens, Serial.print() will not be
able to put its message into that buffer anymore. Facing this situation,
it will switch from its regular non-blocking more of operation to a
different, blocking mode. In this mode, it will block the program
while waiting for the serial port to make some room in the buffer, and
only then will it put its message there and return. The end result is
that the program will be slowed down and match the speed of the serial
port: only 960 executions of the loop() function per second.
An interesting side effect of this situation is that, when the sensor
stops detecting some blockage, the Arduino will nevertheless continue
sending the messages that say that a blockage is detected. It will
continue doing so for about 66 ms: the time needed to empty the
63-byte serial output buffer.
If you are concerned about this issue, an easy way to alleviate it would
be to increase the baud rate. This will not change the qualitative
behavior, but it will make these things happen faster. I suggest you
consider to instead change the communication protocol you have defined
for the Arduino: instead of repeatedly sending information about the
current state of the sensors, it could send information about the state
changes. That is: one message is sent when a detector turns HIGH, and
a different message is sent when it turns LOW. Alternatively, it could
send the full state information (what sensors are LOW or HIGH)
periodically, or every time that state changes, or a combination of
both. I do not know what you are doing with this information on the
other side of the serial link, so I cannot say which option may be the
more appropriate for you.
You wrote in a comment that you may consider in the future driving a
motor instead of sending serial messages. If you go this way, you will
definitely have to work on state changes. In order to run
continuously, a motor does not require you to repeatedly press the “ON”
button a thousand times per second, and it will not turn off all by
itself just because you stopped turning it on. Instead, you turn it on
once and leave it alone, and it will stay on. When you want it to stop,
you have to actively turn it off. The turn on/turn off actions are
required only to change the state of the motor, not to keep the
current state.

user313: There are always other ways to code something (at least if it's non-trivial). What does 'efficiency' mean to you, in this case? If speed is a concern, increase the baud rate. Whenever at least one sensor is HIGH for longer than one loop iteration, the serial output time will be controlling. Other ways to optimize speed would be to put your loop code in an infinite loop inside either the loop() function or the end of the setup() function, saving the call and and return and function entry code of the loop function. Likewise, you can read the input registers directly and save the four calls to digitalRead().
But either of your Arduinos is more than fast enough (i.e., way faster than the phenomena it would be tracking), that there's little point in optimizing.
Update:

As for my second statement under my code about efficient coding practices, its about memory allocation, speed, and shorter code because what if in the future there's going to be a dozen of IR Sensors there, sill it still maintain speeds?

Even your Uno is still fast enough, with enough memory, to manage a dozen such sensors to the level of processing demonstrated in your supplied code - and then some!
However, I would already be thinking ahead to processing multiple sensors without multiple repetitions of your code, which brings up another kind of efficiency: the best use of your time.
If you kept an array of sensor data and looped over it, processing each sensor in turn, one set of code that works correctly once, will work correctly 'n' times. It will be more easily read by someone else (or your future self who, if you're like me, has forgotten some of the details), and it will be easier to fix or expand if you only have to get it right in one place instead of 'n' places.
Want to change what the terminal output looks like when your project has grown to 12 or 14 sensors? It's easy, when you only have to get it right in one place!
I'd be thinking about an array of sensor data containing, for each sensor, its pin number, present state, and any information that might be relevant in the future - sensor location, for example.
Depending on how you expand your processing, you could conceivably run out of speed or memory, but based on your presented code, that day looks a ways off. And you did mention there is a Mega standing by ...  :-)

70516: <p>I am actually wondering if there's a way to efficiently do this block of code. There are two things in my specifications and these are:</p>
<ol>
<li>Four IR Sensors that detects blockage. Basically just to trigger it HIGH or LOW</li>
<li>Once one of the sensors got tripped/triggered, it sends a Serial output</li>
</ol>
<p>In order to do that, I made this code. Basically just stuffing digitalRead and their if conditions in the loop. Is there any way to make the code shorter all the while make it faster for the Serial to get sent?</p>
<pre><code>#define IRSignal1 2
#define IRSignal2 3
#define IRSignal3 4
#define IRSignal4 5

int IRVal1;
int IRVal2;
int IRVal3;
int IRVal4;

void setup() {
  // put your setup code here, to run once:
  pinMode(IRSignal1, INPUT);
  pinMode(IRSignal2, INPUT);
  pinMode(IRSignal3, INPUT);
  pinMode(IRSignal4, INPUT);

  Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
  IRVal1 = digitalRead(IRSignal1);
  IRVal2 = digitalRead(IRSignal2);
  IRVal3 = digitalRead(IRSignal3);
  IRVal4 = digitalRead(IRSignal4);

  if (IRVal1 == LOW) {
    Serial.print('1');
  }
  if (IRVal2 == LOW) {
    Serial.print('2');
  }
  if (IRVal3 == LOW) {
    Serial.print('3');
  }
  if (IRVal4 == LOW) {
    Serial.print('4');
  }
}
</code></pre>
<p>If you have tips, or a go-to resource for efficient coding practices that also helps with memory allocation, shorter code, and speed, I would also love to hear them if that's alright with you.</p>
<p>I use both arduino mega and uno in case this information is useful.</p>
 7508: <p>As others have noticed, this code will be more than fast enough for
its intended purpose, so you should not feel obliged to optimize it
further. That being said, I do see an inefficiency that you may be
interested in hearing about, hence this answer.</p>
<p>If an IR sensor turns LOW and <em>stays LOW</em>, the program will send the
appropriate message repeatedly, as fast as it can. Since the code runs
way faster than the serial port, this will soon fill up the serial
port's output buffer. When this happens, <code>Serial.print()</code> will not be
able to put its message into that buffer anymore. Facing this situation,
it will switch from its regular <em>non-blocking</em> more of operation to a
different, <em>blocking</em> mode. In this mode, it will block the program
while waiting for the serial port to make some room in the buffer, and
only then will it put its message there and return. The end result is
that the program will be slowed down and match the speed of the serial
port: only 960 executions of the <code>loop()</code> function per second.</p>
<p>An interesting side effect of this situation is that, when the sensor
stops detecting some blockage, the Arduino will nevertheless continue
sending the messages that say that a blockage is detected. It will
continue doing so for about 66 ms: the time needed to empty the
63-byte serial output buffer.</p>
<p>If you are concerned about this issue, an easy way to alleviate it would
be to increase the baud rate. This will not change the qualitative
behavior, but it will make these things happen faster. I suggest you
consider to instead change the communication protocol you have defined
for the Arduino: instead of repeatedly sending information about the
current state of the sensors, it could send information about the state
<em>changes</em>. That is: one message is sent when a detector turns HIGH, and
a different message is sent when it turns LOW. Alternatively, it could
send the full state information (what sensors are LOW or HIGH)
periodically, or every time that state changes, or a combination of
both. I do not know what you are doing with this information on the
other side of the serial link, so I cannot say which option may be the
more appropriate for you.</p>
<p>You wrote in a comment that you may consider in the future driving a
motor instead of sending serial messages. If you go this way, you will
definitely have to work on state <em>changes</em>. In order to run
continuously, a motor does not require you to repeatedly press the “ON”
button a thousand times per second, and it will not turn off all by
itself just because you stopped turning it on. Instead, you turn it on
once and leave it alone, and it will stay on. When you want it to stop,
you have to actively turn it off. The turn on/turn off actions are
required only to <em>change</em> the state of the motor, not to keep the
current state.</p>
 313: <p>There are always other ways to code something (at least if it's non-trivial). What does 'efficiency' mean to you, in this case? If speed is a concern, increase the baud rate. Whenever at least one sensor is HIGH for longer than one loop iteration, the serial output time will be controlling. Other ways to optimize speed would be to put your loop code in an infinite loop inside either the <code>loop()</code> function or the end of the <code>setup()</code> function, saving the call and and return and function entry code of the loop function. Likewise, you can read the input registers directly and save the four calls to <code>digitalRead()</code>.</p>
<p>But either of your Arduinos is more than fast enough (i.e., way faster than the phenomena it would be tracking), that there's little point in optimizing.</p>
<p>Update:</p>
<blockquote>
<p>As for my second statement under my code about efficient coding practices, its about memory allocation, speed, and shorter code because what if in the future there's going to be a dozen of IR Sensors there, sill it still maintain speeds?</p>
</blockquote>
<p>Even your Uno is still fast enough, with enough memory, to manage a dozen such sensors to the level of processing demonstrated in your supplied code - and then some!</p>
<p>However, I would already be thinking ahead to processing multiple sensors without multiple repetitions of your code, which brings up another kind of efficiency: the best use of your time.</p>
<p>If you kept an array of sensor data and looped over it, processing each sensor in turn, one set of code that works correctly once, will work correctly 'n' times. It will be more easily read by someone else (or your future self who, if you're like me, has forgotten some of the details), and it will be easier to fix or expand if you only have to get it right in one place instead of 'n' places.</p>
<p>Want to change what the terminal output looks like when your project has grown to 12 or 14 sensors? It's <em>easy</em>, when you only have to get it right in one place!</p>
<p>I'd be thinking about an array of sensor data containing, for each sensor, its pin number, present state, and any information that might be relevant in the future - sensor location, for example.</p>
<p>Depending on how you expand your processing, you could conceivably run out of speed or memory, but based on your presented code, that day looks a ways off. And you did mention there is a Mega standing by ...  :-)</p>
