Handling variable length commands with pauses in transmission
Unless you're doing something particularly time-critical, then you should probably wait until all of the command bytes are received before trying to processing them.
This obviously requires that your system knows how many bytes the command contains.

There are different ways to achieve this. One perfectly valid way is as you've already thought - to make all of your command packets the same length (typically by padding out short ones with extra bytes).
This is probably the simplest way, but could become problematic in some situations.
It could mean that you need to send lots of pad bytes for an otherwise simple command and it also means that there could be unnecessary delays depending on how long it takes to transfer all of the bytes over your comms link.

An alternative method would be to encode the size of the command into the command itself - either by adding a 'length' byte at or near the beginning of the command packet, or by giving your embedded system a lookup table to be able to check how many bytes to expect for each command.
This way it knows how many bytes the command should contain before the transfer of the command is complete and you can then decide how long it should wait for the remaining bytes before timing out and ignoring the unfinished command and/or sending back an error message or whatever is appropriate for your system.  

There are lots and lots of 'gotchas' in writing you own comms protocols (like what happens if you 'miss' the start of your packet and then interpret bytes incorrectly), checking the packet integrity with checksums or CRCs, special markers &amp; byte/bit-stuffing, etc ... But the requirements of your system will dictate how much of this sort of thing you need to worry about.