coding style - name - prácticas defensivas de codificación

psr 3 php

Question

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.

Answer 1

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).

Answer 2

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.

Answer 3

De mi blog:

1. 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 ...

2. 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.

Answer 4

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.

Answer 5

Devolver una copia de un objeto mutable, es decir, una copia de una matriz, no el objeto mutable en sí.

Answer 6

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!

Answer 7

Las 3 mejores prácticas de codificación defensivas que empleo son

1. examen de la unidad
2. examen de la unidad
3. examen de la unidad

No hay mejor defensa para la calidad de su código que una buena prueba de unidad para respaldarlo.

Answer 8

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)

Answer 9

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

Answer 10

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.

Answer 11

Resharper instalado;) Entonces no necesito escribir "5 == a" para que me avisen si hice algo mal :)

Answer 12

Varias sugerencias para la programación C incrustada en el artículo Reglas para programación C defensiva de embedded.com.

Answer 13

Evita la prueba innecesaria. Ejemplo

1. if (bool == verdadero)
2. El puntero comprueba si (puntero)

EDIT: if (puntero) no es legible así que hoy en día prefiero if (NULL! = Puntero)

Answer 14

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.

Answer 15

• Siempre inicializar variables
• Usar const siempre que pueda (sin usar mutable )
• 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 ++).