¿A quién le importa… siempre y cuando el resultado sea bueno?

Question

Estoy un poco sorprendido por muchas reacciones a preguntas que señalan que los desarrolladores se preocupan más por los bytes compilados resultantes que por el significado de su código.Tiendo a ser quisquilloso con el incremento de postfijo/prefijo, ya que tiendo a ser quisquilloso con el uso de un booleano para un tipo enumerado con dos valores, y con la denominación adecuada de funciones, y...

Entonces la pregunta es más bien una encuesta retórica:¿Cuándo se permite ignorar la semántica de lo que se escribe?¿Dónde está la línea fronteriza?

• operador++ (posfijo/prefijo)
• cadena.empty() vs.cadena == ""
• vector.empty() vs.vector.tamaño() == 0
• enumerar {encendido, apagado} vs.booleano activado = verdadero;apagado = falso
• ...

Nombralo.

EDITAR -

No quise cuestionar la necesidad de (micro) optimizaciones.Más bien quiero opiniones sobre lo bien que deberías estar. consciente De lo que estás escribiendo, y en declaraciones como "Pero se compila a un DWORD, de todos modos, entonces, ¿por qué debería convertirlo en un enumno?" (Ese es un caso extremo ...).

Answer 1

He escrito un mucho de código en mi carrera. Desde luego no tanto como mucha gente aquí, pero una gran cantidad de código, no obstante. Durante ese tiempo, he aprendido una cosa que resultó ser cierto una y otra vez:. Al llegar descuidado, cuando se ignora los detalles, defectos infiltran en él

Los defectos cuestan tiempo y dinero para reparar. Usted puede pasar el tiempo para escribir el código de forma limpia y clara desde el principio, cuando es barato para hacerlo, o puede gastar mucho tiempo y dinero en el futuro persiguiendo a un defecto de código que es probable que no recuerda del todo bien porque se dio una palmada juntos en una prisa o porque no cumplen con el estándar de codificación. El resultado final es, usted está perdiendo tiempo y dinero. Además, estás perdiendo el tiempo y el dinero que no tiene que perder para empezar, ya que podría haberse evitado con un poco adelantado la inversión.

Nunca me he arrepentido de ser meticuloso en mi forma de escribir código. Nunca ha vuelto a atormentarme. Siendo descuidado siempre ha de volver a atormentarme.

Answer 2

Definir "ok". ¿Está bien si funciona en la fecha de entrega inicial, pero cada vez que se necesita para hacer un cambio que se necesita un extra de tres semanas para averiguar el código antiguo?

No es su respuesta: el tiempo que se puede entender el código y no se pierde nada de su capacidad para mantenerla

.

Answer 3

Cuando empezar a preocuparse por cosas esotérica que no tienen ningún efecto sobre la línea de fondo, creo que eso es ir demasiado lejos. Discusiones como si se debe utilizar el operador ternario o escribir explícita si las declaraciones son buenas para aquellos días en los que no tienen nada que hacer más que sentarse, poner los pies, cerveza SIP / vino / refresco y tratar asuntos de "gran trascendencia":)

Pero la creación de una enumeración de booleana es simplemente errónea.

Answer 4

depende de su función de costes

A continuación, un par de dimensiones gente le encanta discutir, ya menudo confunden. En realidad, la respuesta es que depende. ¿Qué es lo que realmente valor?

• Recuento de caracteres
• El número de operaciones creadas
• en tiempo de ejecución
• Portabilidad
• mantenibilidad
• Claridad
• Cleverness
• Estabilidad (libre de errores?)
• Extensibilidad

Siempre apunte para la mayor material de primer orden, como la claridad. Pérdida de claridad se paga en ciclos humanos, de los cuales siempre hay una escasez de. La gente rara vez se preocupan por la hora del reloj en bruto, y las personas que dicen que son casi siempre la optimización prematura.

Si les ayuda ninguna, me gusta pensar que estamos haciendo progresos subiendo por la pila, preocuparse más por la semántica y el trabajo conseguir que se hagan en lugar de ser esclavos de los bits y números. Sin embargo, esto no es una excusa para olvidar los fundamentos y recordar cómo ciertos trozos se implementan semánticas. Usted no quiere quedar atrapado con sus pantalones abajo durante esas raras ocasiones donde la velocidad comienza a adquirir importancia y la convención va por la ventana.

Answer 5

"Cuando se tiene permitido hacer caso omiso de la semántica de lo que se escribe? ¿Dónde está la línea de frontera?"

Creo que es una pregunta razonable: "¿Cuándo debe una indiferencia la semántica de lo que uno escribe"

Desde que ver la programación como una actividad humana, diría que la única vez que un debe no tener en cuenta la semántica de una declaración es cuando el propio sistema le obliga - cuando alguna declaración incomprensible es la Sólo strong> manera

Answer 6

La frontera es cuando se trata de una sola escritura, lectura Nunca código. Sólo entonces se importa en última instancia, no lo que está haciendo (en ese caso), porque nunca se va a usar de nuevo. Por desgracia, esto no aborda las votaciones indirecta de la práctica de las cosas que usted no desea repetir.

Answer 7

La línea de frontera es efectos secundarios.

Si una función de encapsulado hace todo lo que quiere con 0 efectos secundarios inesperados, y el código se puede leer, eso es todo lo que importa. Si usted es predecible a un usuario externo y cualquier funcionalidad "extraño" se lleva a cabo internamente, eso es todo lo que importa.

Se cambia ligeramente si se añade a la optimización, pero ya que nunca se debe optimizar de forma prematura, que es donde termina.

Answer 8

optimizaciones Micro no tienen sentido 99% del tiempo. Por ejemplo, si sus internos del compilador "todos" a una única instancia de todos modos, que no están aumentando el rendimiento de ninguna manera mediante el uso de String.Empty. Al no tener ningún efecto medible es típicamente la mejor que se puede esperar demasiado, he visto "optimizaciones" rendimiento disminución, debido a que el compilador haciendo un mejor trabajo, y la optimización interferir con ella.

La mayor parte del código no necesita ser optimizado. Identificar dónde eso tiene que suceder solamente se puede hacer con el diagnóstico después de que el código se ejecuta, y aun así la mayor parte del tiempo que se lleva a cabo mediante la optimización algorítmica, no micro optimización.

Answer 9

Creo que en estos días la mayoría de las personas están de acuerdo en que, en el supuesto de que funciona correctamente, la legibilidad es la consideración más importante. Hay excepciones, por supuesto - algunas aplicaciones tienen que correr lo más rápido posible, y algunas aplicaciones pueden no se permitirá a chocar, pero en términos generales es la legibilidad

.

Answer 10

Al observar los ejemplos que usted ha proporcionado - El siguiente:

operator++ (postfix / prefijo)

string.empty() vs. string == ""

No parecen ser buenos ejemplos, como se comparan las operaciones que son diferentes en functionality. Por lo tanto, una mejor no no tener en cuenta sus distinciones semánticas.

En contraste, los ejemplos siguientes:

vector.empty() vs. vector.size() == 0

enum eRate {on, off} vs. boolean on=true; off=false

son perfectamente razonables.

indeterminate es preferible si el contexto de su uso es sólo para determinar si el vector está vacía. Al sonar condescendiente riesgo (que hago no la intención de ser): esto se reduce al sentido común. ¿Por qué pedir para el tamaño del vector de si sólo se quiere saber si está vacío? Eso es como preguntar a alguien cuánto dinero que tienen en su cartera cuando simplemente desea saber si tienen suficiente dinero para por una Coca-Cola.

En cuanto a <=> erate {<=>, <=>} vs. <=> <=>; <=>, pregúntate esto: ¿qué probabilidades hay de que usted puede añadir otro valor a la enumeración, en el futuro? Parece razonable que uno puede querer <=> erate {<=>, <=>, <=>} `(o alguna variante), por lo que la respuesta puede ser sí. De lo contrario, un valor lógico simple sería suficiente.

Esto me lleva al quid de la cuestión: lo que parece ser si hay algún enfoque determinista / algorítmico a decidir de una forma u otra en cuestiones como éstas, o su relevancia? Mi respuesta es que hasta el día que Máquinas de Turing son capaces de pasar la Test de Turing , diría No. Esta es la razón por la cual los seres humanos son necesarios para diseñar software.