Date: Mon, 6 Nov 2023 11:37:17 -0500
On Mon, Nov 6, 2023 at 11:25 AM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I'm not sure if someone's already mentioned this, but is there anything wrong with making this into a "while"?
> To increment, or not to increment? That is the question.
> Every text processing loop I've ever written has been a "while" loop for this reason.
> Sometimes you just need to check the next character without consuming it, and sometimes you need to take a step larger than one character.
>
> Try something like making a LineInput class with a PushBack( c ) that returns "true" if it detected an EOL condition.
>
> Then your loop might be:
>
> while( Serial.available() )
> {
> if( line.PushBack( Serial.read() ) )
> {
> // We have a complete line, parse it.
> if( ! ProcessCommand( line.GetPtr() ) ){ break; }// Break if the command met a terminal condition
> }
> }
>
> I'm aware of the limitations of embedded environments like an Arduino, and so understandably there should really be more error handling to do with the buffer filling up and other things.
> However, this is just one challenge in dealing with unconstrained serial communications; QoS issues being the much more difficult set of problems.
> It pays to have layered code that can separate QoS issues from actual behavioral implementation, and something like a LineInput can help with that.
>
> I've often found myself in need of some way to break out of nested loops, or break from a loop within a switch statement, but then later found it could be refactored into something more readable.
That's kind of the point. Structured programming boiled goto-hell down
into a small set of extremely commonly used looping patterns. The
small set of structures we have, with a very few out-clauses (break
and continue), are what we have because they work. They represent the
most common use cases, and we have many ways of rearranging code to
fit those use cases.
And because everyone understands those common looping structures, we
can easily read and understand code that fits into them. Outlier cases
have `goto` where needed, but for the most part, looping is easily
understood via a few key constructs.
The more constructs you add, the more stuff people have to remember
and learn, and thus the harder it is to figure out what is actually
going on in any given code. Outlier cases exist, but the existing
systems can handle them adequately, and when they can't, we have
`goto`. But outlier cases are *outliers*.
<std-proposals_at_[hidden]> wrote:
>
> I'm not sure if someone's already mentioned this, but is there anything wrong with making this into a "while"?
> To increment, or not to increment? That is the question.
> Every text processing loop I've ever written has been a "while" loop for this reason.
> Sometimes you just need to check the next character without consuming it, and sometimes you need to take a step larger than one character.
>
> Try something like making a LineInput class with a PushBack( c ) that returns "true" if it detected an EOL condition.
>
> Then your loop might be:
>
> while( Serial.available() )
> {
> if( line.PushBack( Serial.read() ) )
> {
> // We have a complete line, parse it.
> if( ! ProcessCommand( line.GetPtr() ) ){ break; }// Break if the command met a terminal condition
> }
> }
>
> I'm aware of the limitations of embedded environments like an Arduino, and so understandably there should really be more error handling to do with the buffer filling up and other things.
> However, this is just one challenge in dealing with unconstrained serial communications; QoS issues being the much more difficult set of problems.
> It pays to have layered code that can separate QoS issues from actual behavioral implementation, and something like a LineInput can help with that.
>
> I've often found myself in need of some way to break out of nested loops, or break from a loop within a switch statement, but then later found it could be refactored into something more readable.
That's kind of the point. Structured programming boiled goto-hell down
into a small set of extremely commonly used looping patterns. The
small set of structures we have, with a very few out-clauses (break
and continue), are what we have because they work. They represent the
most common use cases, and we have many ways of rearranging code to
fit those use cases.
And because everyone understands those common looping structures, we
can easily read and understand code that fits into them. Outlier cases
have `goto` where needed, but for the most part, looping is easily
understood via a few key constructs.
The more constructs you add, the more stuff people have to remember
and learn, and thus the harder it is to figure out what is actually
going on in any given code. Outlier cases exist, but the existing
systems can handle them adequately, and when they can't, we have
`goto`. But outlier cases are *outliers*.
Received on 2023-11-06 16:37:29