And there I was a couple of days ago telling somebody to use the “conventional form” of a for loop. That for loop has to deviate from the conventional form, using <= or putting the ++ operator in an unusual place or some other strangeness (not all strangenesses at once, though). Not only is that code detailed, but it is also error‑prone in case of out‑by‑one errors.Jason Bullers wrote: . . . There are a lot of details in that code that I had to think about, such as the loop . . .
Jason Bullers wrote:Extending or changing existing code follows the same thinking: what is the code trying to accomplish? Can you take all of those detailed how steps and express the problem as a series of declarative operations instead of very detailed procedural ones?
Hope that helps a bit!
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jason Bullers wrote:Thanks for the cows guys! Happy I could help.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
If someone were to ask you to mail some letters with the instruction “repeat the following action: if you have any more letters, take the next one in alphabetical order of addressee’s surname and put it in the mailbox,” your kindest thought would probably be that they have overspecified the task. You would know that ordering doesn’t matter in this task, and neither does the mode—sequential or parallel—of execution, yet it would seem you aren’t allowed to ignore them.