The Dreaded delay() Function

So, it seems that literally every day a new person posts on the forum asking for help with a project that uses the delay() function when it shouldn’t be. The diligent newbies have looked over the simplest examples that come with the IDE and have attempted to expand there functionality using the flawed delay() model that they first came across.

Invariably, there is a chorus of responses: “Don’t use delay!”, “Use millis()!”, “See blink-without-delay!”, etc.

So, I was just wondering, is there any way to ask the folks up in the Arduino development hierarchy to please remove those flawed examples and provide ones that start the newbie along the path of doing things the “Arduino Way”?

Just a thought.

Good idea, but alas it won't happen.

Maybe a sticky that says "Never use delay() and here is why", but alas that won't work.

.

Delay has its time and place. That time and place is in introductory lessons and simple projects.

As hard of a time as people seem to have with the idea of using a clock that only shows milliseconds, I think we should get them at least able to write blink and upload it before we hit them with that.

Although it might be nice to put a disclaimer there describing the issues with delay.

I was just wondering, is there any way to ask the folks up in the Arduino development hierarchy to please remove those flawed examples and provide ones that start the newbie along the path of doing things the “Arduino Way”?

While we are at it, perhaps all of the examples should be removed because it is possible to use any function in an inappropriate way. Shall we ask for the pins labelled SDA and SCL to be removed from Rev 3 Uno boards because they are actually shared with other pins and what about those dratted Tx and Rx pins that can sometimes be used a GPIO pins, but not always ?

The Blink example using delay() does exactly what is intended. The program has one purpose, to blink an LED, which it does perfectly. If someone asked me to write a program whose sole purpose was to blink an LED then I would use delay(). What would you use and why ?

If newcomers will not even take the trouble to read this before posting a programming question then there is little or no hope of them getting started with millis() and for the delay() function to be banished into darkness.

The Blink example could certainly be expanded with comments explaining why delay() is not always appropriate but do you honestly think that most people will take any notice ?

While we are at it, perhaps all of the examples should be removed because it is possible to use any function in an inappropriate way. Shall we ask for the pins labelled SDA and SCL to be removed from Rev 3 Uno boards because they are actually shared with other pins and what about those dratted Tx and Rx pins that can sometimes be used a GPIO pins, but not always ?

Reductio ad Absurdum.

If someone asked me to write a program whose sole purpose was to blink an LED then I would use delay(). What would you use and why ?

An ElapsedMillis Variable. Because the "sole purpose" would inevitably be expanded to additional functionality. AKA Feature Creep :slight_smile:

gfvalvo:
An ElapsedMillis Variable. Because the "sole purpose" would inevitably be expanded to additional functionality.

Not true. The last two projects I did for someone did a bit of LED blinking and servo moving all using delays. And the "customer" is really happy with them.

Some things really are simple and there's no value in complicating them just because you can.

Steve

Because the “sole purpose” would inevitably be expanded to additional functionality

Only if you let it. An important step in any programming project is to have a specification in order that a solution that meets it can be delivered.

In the commercial world there would be written specification of both the hardware and software and what it should do, and an agreed timescale against which the program would be delivered. Part of the process of determining the specification is to probe the client’s requirements for the program to ensure that what is being delivered meets their stated needs and possible extended requirements for the future.

Of course, what often happens with hobby projects is that people dive in and start writing code that meets what they currently want to do with no thought of future requirements. The code becomes more and more complex trying to meet newly discovered requirements and there is a reluctance to start again.

There is nothing dreaded about it, and it is entirely appropriate for introductory projects - and can be fine with even quite complex ones. Progressing to "blink without delay", if and when one needs to, is just part of the learning process.

INTP:
Delay has its time and place. That time and place is in introductory lessons and simple projects.

Meh - depends on the application. If you are using a state machine that switches some relays, and you want to give the relays a couple of millis to switch, a delay is reasonable and far simpler than writing a state for the transition.