coding style - name - prácticas defensivas de codificación
psr 3 php (15)
Al comparar una cadena con una constante, escriba
if ("blah".equals(value)){}
en lugar de
if (value.equals("blah")){}
para evitar una NullPointerException. Pero esta es la única vez que uso el estilo de codificación sugerido (porque "if (a = 1) ..." no es posible en Java).
Desde que escribí por primera vez
if ($a = 5) {
# do something with $a, e.g.
print "$a";
}
y pasó por la sesión de desconcierto normal de
- ¿Por qué el resultado es siempre cierto?
- ¿Por qué $ a siempre es 5
hasta que me di cuenta, había asignado 5 a $ a, en lugar de realizar una comparación.
Así que decidí escribir ese tipo de condición arriba como
if (5 == $a)
en otras palabras:
coloque siempre el valor constante en el lado izquierdo del operador de comparación, lo que da como resultado un error de compilación, en caso de que olvide agregar el segundo signo "=".
Tiendo a llamar a esta codificación defensiva y tienden a creer que es un primo de la programación defensiva , no en la escala algorítmica, sino palabra clave por palabra clave.
¿Qué prácticas de codificación defensiva has desarrollado?
Una semana más tarde:
Un gran "gracias" a todos los que respondieron o podrían agregar otra respuesta en el futuro.
Lamentablemente (¡o afortunadamente!) No hay una única respuesta correcta. Para eso mi pregunta fue amplia, pidiendo más opiniones o aprendiendo de la experiencia, en lugar de hechos.
Cosas de pareja:
- Sí, los bloques de 1 línea. Usa los frenos ... diablos, la mayoría de los buenos IDE te harán em.
- Comenta tu código después de escribirlo, o vuelve a leer tus comentarios si lo hiciste antes de tiempo. Asegúrate de que tu código todavía haga lo que dicen los comentarios.
- Las pruebas unitarias son una excelente alternativa para volver a leer su código.
- Siempre registre una excepción ... o, NUNCA capture una excepción sin decirlo, al menos en la depuración.
De mi blog:
Piensa positivo y regresa temprano además de evitar la anidación profunda. En lugar de
if (value! = null) {... hacer algo con valor ...} return
escribir
if (value == null) {return} ... hacer algo con valor ...
Evite las "constantes de cadena" (es decir, el mismo texto entre comillas en más de un lugar). Defina siempre una constante real (con un nombre y un comentario opcional lo que significa) y úselo.
Dejé de usar idiomas donde puedes hacer
if a = 5: print a
Esto me ha ahorrado toneladas de dolores de cabeza =).
En una nota más seria ... ahora siempre escribo las llaves justo después de escribir mis if
y for
bucles, y luego los llevo después. Esto asegura que mis corchetes estén siempre alineados.
Devolver una copia de un objeto mutable, es decir, una copia de una matriz, no el objeto mutable en sí.
Esto es simple y obvio, pero NUNCA JAMÁS repito la misma constante de cadena dos veces en mi código, porque SÉ que si lo hago, estaré deletreando una de ellas mal :) ¡Use constantes, gente!
Las 3 mejores prácticas de codificación defensivas que empleo son
- examen de la unidad
- examen de la unidad
- examen de la unidad
No hay mejor defensa para la calidad de su código que una buena prueba de unidad para respaldarlo.
Personalmente, no me gusta este estilo defensivo, hace que el código sea difícil de leer.
El nivel 4 de advertencia del compilador de VC detectará este error (posible).
"advertencia C4706: asignación dentro de la expresión condicional"
Puede habilitar solo esta advertencia específica del compilador, en cualquier nivel:
#pragma warning(3,4706)
Siempre coloque llaves después de un if / for / while ... incluso si solo hay una sola declaración después. BTW D. Crockford piensa que es mejor también: bloques necesarios
Siempre use llaves:
if(boolean)
oneliner();
nextLineOfCode();
no es lo mismo que:
if(boolean)
{
oneliner();
}
nextLineOfCode();
Si oneliner () es una función #defined, y no está definida, la siguiente línea de código queda súbitamente sujeta a if (). Lo mismo se aplica a los bucles for, etc. Con los corchetes, el siguiente fragmento de código nunca se vuelve accidentalmente condicional en el if / for, etc.
Resharper instalado;) Entonces no necesito escribir "5 == a" para que me avisen si hice algo mal :)
Varias sugerencias para la programación C incrustada en el artículo Reglas para programación C defensiva de embedded.com.
Evita la prueba innecesaria. Ejemplo
- if (bool == verdadero)
- El puntero comprueba si (puntero)
EDIT: if (puntero) no es legible así que hoy en día prefiero if (NULL! = Puntero)
Una de las cosas que siempre trato de recordar cuando estoy en el mundo Javascript es comenzar siempre el valor de retorno de una función en la misma línea que la palabra clave de retorno.
function one(){
return {
result:"result"
};
}
function two(){
return
{
result:"result"
};
}
Estas 2 funciones no devolverán el mismo valor. La primera función devolverá un Objeto con un conjunto de resultados de propiedades a "resultado". La segunda función volverá undefined
. Es un error muy simple y ocurre debido a la estrategia de inserción de Semi-Colon de JavaScript demasiado celosa. Los semi-puntos son semi-opcionales en Javascript y debido a esto, el motor de Javascript agregará semi-coons donde cree que debería estar. Como return
es en realidad una declaración válida, se insertará un punto y coma después de la declaración de devolución y el resto de la función se ignorará esencialmente.
- Siempre inicializar variables
- Usar
const
siempre que pueda (sin usarmutable
) - Evite la asignación dinámica simple de memoria u otros recursos
- Siempre use llaves
- Código de casos de uso y pruebas para cualquier clase antes de la implementación de la codificación
- Active tantas advertencias útiles como pueda (
-Wall -Wextra -ansi -pedantic -Werror
como mínimo) - Use la herramienta más simple que resuelve el problema (en mi entorno actual, es
bash
->grep
-> awk -> Python -> C ++).