Delay Necessary in Empty While Loops? (and more...)

Is there anything wrong with:

while (digitalRead(someButton)) {}

I use these a lot in my code but I usually throw a "delay(2);" inside the loop. Is this delay necessary?

If there is a use for this delay, is there an alternatively recommended method (as it seems everyone hates delay() around here)? (If the answer is to use millis() then I understand)

Thanks

*Also, is it way more efficient to just use bytes instead of ints when concerning a variable that only ever has the value 0 or 1?

That works.
I have got into he habit of using the Bounce library and use it to check for the button HIGH condition.

Also, if there is nothing in the while loop you can terminate with a semi-colon instead of curlies. Using bytes versus ints isn't a lot faster, but will save a byte of precious SRAM.

but I usually throw a "delay(2);" inside the loop. Is this delay necessary?

LarryD is correct, you should have a debounce function call instead of the raw hardware connection. If properly debounced, delay is not desirable.

Is this delay necessary?

No, and it makes your detection of the button less responsive.

is it way more efficient to just use bytes instead of ints when concerning a variable that only ever has the value 0 or 1?

For small values it will save space (and often processor time) to use char or unsigned char data types, particularly for arrays of values.

If you use the 'boolean' type it will take up the same space as a character and will also make sure the value is constrained to 0 or 1.

*Also, is it way more efficient to just use bytes instead of ints when concerning a variable that only ever has the value 0 or 1?

Yes, boolean x;
You can also use each bit in the byte as 8 flags.

So simply using boolean is the best option here in terms of space and speed?

Also, is there not a better way to invert a boolean other than "test = !test"

cypherrage:
So simply using boolean is the best option here in terms of space and speed?

Also, is there not a better way to invert a boolean other than "test = !test"

Sometimes you see "test = 1-test", but using the ! (not operator) is preferred. NB false = 0 and and non 0 value is considered true.

Optimizing for both speed and space simultaneously is often conflicting.
What are your requirements in detail?
Do you need the optimization for either speed/space/both?
Why? What is the goal of your project?

robtillaart:

cypherrage:
So simply using boolean is the best option here in terms of space and speed?

Also, is there not a better way to invert a boolean other than "test = !test"

Sometimes you see "test = 1-test", but using the ! (not operator) is preferred. NB false = 0 and and non 0 value is considered true.

Optimizing for both speed and space simultaneously is often conflicting.
What are your requirements in detail?
Do you need the optimization for either speed/space/both?
Why? What is the goal of your project?

I would prefer speed then, as I am using an Arduino Mega, space shouldn't be nearly as large an issue.

I'm designing a control mechanism that has to manage a large amount of inputs and outputs at the same time and so speed would be the largest factor here.

Go for Direct Port Manipulation to speed up the checking of pins. There are implementations of digitalReadFast() and digitalWriteFast().
There is also the pin class which do all the addressing once, making it much faster that the generic digitalRead().
Also worth is looking at the PinChangeInterrupt, which enables monitoring multiple pins at once.

Learn to do bit math properly. Check out the book - Hackers Delight - to see freaky code.

And the ultimate speed asks for assembly, but it is not for the faint of heart. Beating the compiler is far from trivial and is an art in itself.

Stay away from the String class and floats if possible, and use baudrates of 1000000 as the Arduino can be far faster than 9600 baud.
I recently worked with the Teensy2.0 again and several of its core libs are faster than the standard UNO. (it is the same uProc)

Having a delay() (or similar) inside the loop would make your code more portable to various forms of multitasking operating systems.
Tight loops waiting for things that happen on human time-scales are one of the things that made porting microcomputer games to "real computers" a real PITA.