¿Por qué hay tanto código así? - página 3
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿Pero no significa eso que si están pidiendo ayuda con la sintaxis o la lógica el código no va a " . . ser sintáctica y lógicamente correcto;" ?
Sí, tiene razón. Pero en el contexto de la discusión de los estilos/prácticas de codificación más (o menos) eficaces, el aspecto más importante es que el código sea sintáctica y lógicamente correcto, independientemente del estilo de codificación utilizado. Supongo que otra forma de decirlo es que el estilo debe dar paso a un código sintáctica y lógicamente correcto: la cuestión principal no es si el código se ve bien y es fácilmente legible, sino, más bien, si es sintáctica y lógicamente correcto para realizar la tarea para la que está escrito. :)
También estoy de acuerdo con los comentarios. Uno nunca puede tener demasiados // comentarios, tanto para refrescar la mente del programador original en cuanto a las particularidades de las diversas partes del código como para ayudar/ayudar a la comprensión del código por parte de otros después de la finalización/implementación.
Sí, tienes razón. Pero en el contexto de la discusión de los estilos/prácticas de codificación más (o menos) eficaces, el aspecto más importante es que el código sea sintáctica y lógicamente correcto, independientemente del estilo de codificación utilizado. Supongo que otra forma de decirlo es que el estilo debe dar paso a un código sintáctica y lógicamente correcto: la cuestión principal no es si el código se ve bien y es fácilmente legible, sino, más bien, si es sintáctica y lógicamente correcto para realizar la tarea para la que está escrito. :)
Ah vale, ya veo lo que dices... el código bien presentado no sirve de nada si no funciona... pero quizás sea más fácil de arreglar...
Creo que la mayoría de los estilos de codificación permiten tanta legibilidad como el codificador quiera o necesite, yo cierro mi código cuando está terminado y funcionando, pero es fácil abrirlo de nuevo con algunos espacios de línea si necesito compartirlo o discutirlo. Creo que un formato de codificación debería permitir identificar fácilmente un corchete que falta y los pares if else cuando hay un árbol if else complejo con múltiples ramas. Nunca adopté el estilo K&R, así que me gustaría ver cómo lo hacen los codificadores del estilo K&R.
Cierro mi código cuando está terminado y funcionando, pero es fácil volver a abrirlo con unos cuantos espacios de línea si necesito compartirlo o discutirlo.
¿Por qué cerrarlo? Realmente no entiendo el sentido de cerrar el código. Si necesitas abrirlo para compartirlo/discutirlo, ¿qué implica eso?
Creo que un formato de codificación debería permitir identificar fácilmente un corchete que falta, e identificar fácilmente los pares if else cuando hay un árbol if else complejo con múltiples ramas. Nunca he adoptado el estilo K&R, así que me gustaría ver cómo lo hacen los codificadores del estilo K&R.
Para el estilo K&R, el corchete inferior se alinea con la coincidencia de condiciones. Yo personalmente uso
1. Sangría consistente
2. Para las cláusulas de una sola declaración, ya sea con corchetes y sangría o con la condición sin corchetes, es decir.
3. Utilice un editor de programadores decente que haga coincidir las llaves.
La concordancia de los corchetes no es un problema - la mayor parte del kernel de linux está escrito en este estilo, y es el estándar de Java. Aunque puedo ver la atracción del estilo Allman, ya que, con el estilo K&R, a menudo insertaría una línea en blanco adicional después de la condición para despejar el código. Hmm, puede que me convierta :)
¿Por qué cerrarlo del todo? Realmente no entiendo el sentido de aplastar el código. ¿Si usted necesita abrirlo para compartir/discutir qué implica eso?
Para el estilo K&R, la abrazadera inferior se alinea con la coincidencia de condiciones. Yo personalmente uso
1. 1. Sangría consistente
2. Para las cláusulas de una sola declaración, ya sea con corchetes y sangría o con la condición sin corchetes.
3. Utilice un editor de programadores decente que haga coincidir las llaves.
La concordancia de las llaves no es un problema - la mayor parte del kernel de Linux está escrito en este estilo, y es el estándar de Java. Aunque puedo ver la atracción del estilo Allman ya que, con el estilo K&R, a menudo insertaría una línea en blanco adicional después de la condición para despejar el código. Hmm, puede que me convierta :)
Simplemente lo cierro para que ocupe menos espacio en la pantalla. Me gusta ver todo lo que cabe en la pantalla al mismo tiempo. No necesito un emparejador de llaves, lo formateo de manera que si coloco el cursor detrás de una llave y lo paso verticalmente por las líneas con la tecla de flecha, cuando toca otra llave esa es su par. si lo coloco detrás de un else y hago lo mismo, cuando toca un if ese es el par if else.
En esta sección de código es fácil ver que el tercer else empareja el primer if, el segundo else empareja el segundo if y el primer else empareja el tercer if porque la(s) llave(s) detrás de cada else se alinean verticalmente detrás de su correspondiente llave if. Del mismo modo, es fácil ver qué if no tiene un else porque cada llave de if se alinea verticalmente con su correspondiente llave de cierre en el grupo detrás del else. No estoy sugiriendo que todo el mundo deba formatear el código de esta manera sólo porque a mí me gusta, pero para mí es compacto y lógico.
No puedo responder a esto para todos los codificadores que utilizan k&r. Sinceramente, cuanto más miro su formato, más me gusta. Si hubiera adoptado el estilo de Allman, definitivamente podría verme usando tu versión modificada. Los corchetes se alinean uno debajo del otro, se libra de que los corchetes de apertura y cierre ocupen una línea entera. Puedes pasar el cursor por la i sobre el if y encontrar las llaves que faltan, sin preocuparte por las convenciones de tamaño de tabulación/indentación, modo compacto {ver la mayoría de tus códigos en pantalla}. Así que sí, es bastante genial, es sólo que a primera vista, porque no estoy acostumbrado, me pareció confuso. Y ese es el corazón de la cuestión aquí.
A mí me parece que muchos codificadores americanos adoptan el estilo [KnR & Allman], mientras que el estilo Whitesmiths parece popular entre los europeos. Whitesmith es también el estilo por defecto para Mt4. Ahora bien, no hay nada malo en ninguno de estos estilos, es sólo que cuando estoy ayudando a alguien, tengo que recordarme a mí mismo que debo ignorar mi estilo K&R y pensar más en Whitesmith. Eso o usar un formateador de código.
Por qué alguien querría escribir "árboles complejos if else" está más allá de mí. Cuando alguien deja todo el espacio en blanco y el formato dentro de un complejo if_nest, parece como si estuvieran tratando de diseñar un Snake | Spaghetti | ZigZag a través de la página. El primer if comienza en la línea 1 y termina en la línea 300, alrededor de 150 o %50 de esas líneas están siendo sostenidas por llaves. En lugar de los "complejos árboles if else", ¿por qué no crear una función? Entonces deja que la línea_1 termine realmente en la línea_1 con if( false ){ return; }.
Gracias ubzen me alegro de que a alguien le guste mi formato lol. Utilizo mucho el if else, probablemente porque cuando empecé a codificar alguien me dijo que el if else hace un código rápido, así que me acostumbré a hacerlo así.
Gracias ubzen me alegro de que a alguien le guste mi formato lol. Utilizo mucho el if else, probablemente porque cuando empecé a codificar alguien me dijo que el if else hace un código rápido, así que me acostumbré a hacerlo así.
No es nada personal
Es en momentos como este en los que hubiera sido bueno tener un estándar formal y obligatorio con el que todo el mundo trabajara... entonces todos estaríamos haciendo lo mismo y a todos nos gustaría su código. Y antes de que preguntes, no, seguiré con mi estilo de Whitesmiths... al menos ahora sé cómo llamarlo, gracias ubzen