Esta es una especie de respuesta indirecta, pero esta pregunta me hizo pensar en la lógica detrás de ella, y pensé que valdría la pena compartirla.
Como han dicho todos los demás, usa un do ... while
bucle cuando desea ejecutar el cuerpo al menos una vez. Pero, ¿bajo qué circunstancias le gustaría hacer eso?
Bueno, la clase de situaciones más obvia en la que puedo pensar sería cuando el valor inicial ("sin cebar") de la condición de verificación es el mismo que cuando desea salir . Esto significa que debe ejecutar el cuerpo del bucle una vez para cebar la condición a un valor no existente y luego realizar la repetición real basada en esa condición. Con los programadores siendo tan vagos, alguien decidió envolver esto en una estructura de control.
Entonces, por ejemplo, leer caracteres desde un puerto serie con un tiempo de espera podría tomar la forma (en Python):
response_buffer = []
char_read = port.read(1)
while char_read:
response_buffer.append(char_read)
char_read = port.read(1)
# When there's nothing to read after 1s, there is no more data
response = ''.join(response_buffer)
Tenga en cuenta la duplicación de código: char_read = port.read(1)
. Si Python tuviera un do ... while
bucle, podría haber usado:
do:
char_read = port.read(1)
response_buffer.append(char_read)
while char_read
El beneficio adicional para los lenguajes que crean un nuevo alcance para los bucles: char_read
no contamina el espacio de nombres de la función. Pero tenga en cuenta también que hay una mejor manera de hacer esto, y es utilizando el None
valor de Python :
response_buffer = []
char_read = None
while char_read != '':
char_read = port.read(1)
response_buffer.append(char_read)
response = ''.join(response_buffer)
Así que aquí está el quid de mi punto: en los lenguajes con tipos que aceptan valores NULL, la situación initial_value == exit_value
surge con mucha menos frecuencia y es posible que esa sea la razón por la que no la encuentre. No digo que nunca suceda, porque todavía hay momentos en los que una función volveráNone
a significar una condición válida. Pero en mi opinión apresurada y brevemente considerada, esto sucedería mucho más si los lenguajes que utilizó no permitieran un valor que signifique: esta variable aún no se ha inicializado.
Este no es un razonamiento perfecto: en realidad, ahora que los valores nulos son comunes, simplemente forman un elemento más del conjunto de valores válidos que puede tomar una variable. Pero prácticamente, los programadores tienen una forma de distinguir entre una variable que está en estado sensible, que puede incluir el estado de salida del bucle, y que está en un estado no inicializado.