Una regla general efectiva:nunca use std::move ni std::forward y nunca escriba cast a una referencia rvalue (o universal). Si nunca se mueve de una variable o una referencia, entonces no puede cometer el error de usarla después. Este enfoque obviamente tiene un inconveniente, ya que esas utilidades son útiles en algunos casos para convertir una copia en un movimiento cuando el movimiento es suficiente; por no hablar de los casos en los que es necesario.
Enfoque para sus propios tipos:agregue aserciones en funciones miembro que verifiquen si la instancia se ha movido y confíe en que se activen durante la prueba. El estado "movido" deberá almacenarse como miembro. Las aserciones y el miembro se pueden eliminar en la compilación de versión. Un inconveniente es que esto agrega un texto repetitivo innecesario a cada función miembro.
Un enfoque adicional:use una herramienta de análisis estático que intente detectar el error potencial.
Una regla general razonable:mantenga sus funciones breves. Cuando la función es corta, un uso estará cerca del movimiento y, por lo tanto, el error potencial es más fácil de detectar.
Entonces, el problema realmente es "leer" después del movimiento. Creo que estoy de acuerdo en que cualquier uso de std::move debe revisarse como un riesgo potencial. Si std::move está al final de una función con un valor local o parámetro de valor, todo bien.
Cualquier otra cosa necesita escrutinio, y se debe prestar atención a cualquier uso de la variable después del movimiento. Supongo que darle a la variable un sufijo "_movable" también ayudará con la revisión del código.
Los pocos casos de escritura tras movimiento, como el intercambio, solo tendrán que defenderse durante la revisión.
Personalmente, sigo tratando std::move como un olor en el código, como si fuera un molde.
No estoy seguro de ninguna regla de pelusa que imponga este patrón, pero estoy seguro de que son fáciles de escribir :-)