2010-11-09 9 views
8

Esas últimas semanas, me encontré usando un montón de const en todas partes. No solo en declaraciones de métodos o argumentos, sino incluso para variables temporales.¿Estoy abusando de const?

Déjenme ilustrarlo con una simple función.

solía escribir:

// A dummy function that sums some computation results 
unsigned int sum_results(const Operation& p1, const Operation& p2) 
{ 
    unsigned int result1 = p1.computeResult(); 
    unsigned int result2 = p2.computeResult(); 

    // Well this function could be in one single line but 
    // assume it does more complex operations 
    return result1 + result2; 
} 

pero ahora es más como:

// A dummy function that sums some computation results 
unsigned int sum_results(const Operation& p1, const Operation& p2) 
{ 
    const unsigned int result1 = p1.computeResult(); 
    const unsigned int result2 = p2.computeResult(); 

    // Well this function could be in one single line but 
    // assume it does more complex operations 
    return result1 + result2; 
} 

Este último tiene más sentido para mí y parece menos propenso a errores. (Admito que en este ejemplo, en realidad no importa) Sin embargo, he visto muy pocas muestras de código donde const se utilizó en variables temporales/locales. Y me gustaría entender por qué.

¿Hay alguna razón por la cual este no es un caso común? ¿Estoy abusando de mi uso de const? ¿O solo soy yo quien ha estado buscando muestras equivocadas?

Respuesta

21

El uso de const en variables locales mejora la claridad del código, por lo que es una buena idea. Ver const e inmediatamente sabe que la variable nunca se cambia más adelante en el alcance. Es de la misma serie que las funciones abreviadas y returning early.

Los desarrolladores son flojos: a menudo piensan que es una palabra inútil que no cambia nada. OMI están equivocados.

+3

+1. Poner const en variables locales que no van a cambiar (o no deberían cambiar) detecta errores antes de que ocurran (en tiempo de compilación) y muestra claramente su intención al siguiente programador que tiene que mirar su código. –

+1

Pero, ¿daría lugar a un mejor rendimiento o una mejor optimización por parte del compilador? – DumbCoder

+2

@DumbCoder: Tal vez, pero muy poco probable. Los compiladores modernos son muy buenos para optimizar el código. Si a uno realmente le importa, deberían probar ambos e inspeccionar el código de la máquina emitida. – sharptooth

5

De hecho, esta es la misma razón por la que las aserciones se utilizan con poca frecuencia. const en interfaces es obligatorio, const en la implementación es voluntaria. Los programadores son flojos.

Editar: por si acaso no está claro, su enfoque es mejor.

1

No hay nada malo con hacer eso, sino que utiliza const para alistar el compilador para ayudar a hacer cumplir una restricción, cuando se sabe que un objeto no debe ser modificados. Si no lo hace care si el objeto se modifica, entonces es superfluo.

+0

Incluso si este ejemplo ficticio, ni 'result1' o' result2' están destinados a ser modificados. Ellos tienen un valor que no debería cambiar. No me importa tener más teclas siempre que pueda hacer que mi código sea menos propenso a errores. – ereOn

+0

"ni result1 o result2 deben modificarse. Tienen un valor que no debería cambiar" Entonces deberían ser const. Mi punto es que lo haces por una razón, y si eres consciente de eso, no sentirás que estás abusando de nada. – Mud

1

En C++, este es un buen enfoque para construir variables si es posible. Pero una vez dicho esto, esto tiene más sentido en los casos en que una variable se pasa como un argumento o se comparte entre diferentes fragmentos de código (como las variables de clase). La idea principal es detener la modificación accidental de variables por otro código que no sabe que esta variable no debe cambiarse.

Por lo tanto, a la luz de lo anterior, para las variables locales de una función, confusarlas es una especie de exceso. Sin embargo, hacer esto no daña nada.

1

En mi humilde opinión, debe aprovechar el compilador de un lenguaje fuertemente tipado en cada oportunidad. Yo uso const para variables locales temporales, referencias inmutables, etc.

El Const Correctness C++ FAQ podría tener más información útil.

2

No creo que se trate simplemente de que los programadores sean flojos: la concisión también es una consideración.Algunas personas pueden encontrar int x; menos carga mental que "const int x;" al revisar las funciones: ese espacio extra de bit puede ayudarlos a encajar un comentario al lado. Menciono esto no como una recomendación, sino porque creo que es importante entender todos los "costos" que influyen en las actitudes de las personas, ya que es realmente confuso que las personas no usen constantemente const aquí.

También es interesante considerar que en algún momento del uso de una variable en una función, puede ser necesario modificarla. Por ejemplo, usted calcula algo, pero luego ingresa unas cuantas declaraciones y cosas, y hay algunos casos extremos en los que necesita eliminar un elemento final de una cadena, manejar un problema de uno por uno, borrar el valor, etc. Si inicialmente había creado la variable const, entonces su flujo de trabajo se interrumpe más para volver y eliminar const de la definición, luego devolver el cursor al lugar donde está trabajando. En contra de esto, el hábito de usar const cuando sea posible es una bandera roja que algunos de esos ajustes están ocultos en el cuerpo de la función, y muy útil para su posterior comprensión y mantenimiento.

Aún así, lo aliento activamente a que continúe usando const: normalmente lo hago y lo considero la mejor práctica. Las razones de eso son obviamente entendidas por usted y han sido enumeradas en otras respuestas.

3

Yo personalmente diría que nunca hay demasiados const, y los uso abundantemente para las variables locales. El único contexto en el que podía añadir un const pero no lo hago es sobre los parámetros de los tipos predefinidos:

vacío foo (const int);

Aquí, creo (pero eso es realmente una cuestión de gusto personal) que inutiliza la interfaz.