¿Debo escribir código compacto o código con muchos espacios? [duplicar]

15

Tengo dos amigos que tienen escuelas de pensamiento completamente diferentes sobre cómo diseñar su código.

El primero dice que el código debe estar bien sangrado y usar muchos espacios y nombrar las variables con criterio para organizar las cosas de manera que puedas entender de inmediato la jerarquía y la semántica código.

Aquí hay una muestra de cómo se ve su código:

var Stack = function () {

    var pair = function ( first ) {
        return function ( second ) {
            return function ( dispatcher ) {
                return dispatcher ( first ) ( second );
            };
        };
    };

    var getFirst = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return x;
            };
        } );
    };

    var getSecond = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return y;
            };
        } );
    };

    var emptyStack = function () {
        return function () {
            return null;
        }
    };

    var stack = emptyStack ();

    var self = {
        push: function ( item ) {
            stack = pair ( item ) ( stack ); 
            return self;
        },
        pop: function () {
            var top = getFirst ( stack );
            stack = getSecond ( stack ) || emptyStack ();
            return top;
        },
        top: function () {
            return getFirst ( stack );
        }
    };

    return self;
};

El segundo dice que es mejor tener su código escrito de una manera más compacta para que pueda ver una parte más grande de la imagen a la vez y poder reconocer más inmediatamente cómo una parte de El programa afectará a otro.

Aquí está el mismo programa escrito en su estilo:

var Stack=function(){
var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
var fst=function(p){return p(function(x){return function(y){return x}})};
var snd=function(p){return p(function(x){return function(y){return y}})};
var empt=function(){return function(){return null}};var stk=empt();
var slf={push:function(val){stk=pair(val)(stk);return slf},
pop:function(){var top=fst(stk);stk=snd(stk)||empt();return top},
top:function(){return fst(stk)}};return slf}

Personalmente prefiero escribir código de la primera forma, pero realmente no he probado la segunda forma, así que tal vez no estoy acostumbrado.

Me he dado cuenta de que cuando veo el código Javascript de la mayoría de los sitios web profesionales, usualmente usan el segundo estilo, por lo que podría haber algo en él.

Aparte de las preferencias estilísticas subjetivas, ¿hay alguna razón para preferir una sobre la otra?

    
pregunta Peter Olson 23.05.2013 - 16:55
fuente

7 respuestas

17

Debería usar el primer enfoque porque se puede escalar a programas más grandes.

La mentalidad de "Necesito ver cómo todo afecta a todo" es perjudicial para el desarrollo de software. Desea que las funciones / objetos estén desacoplados, de modo que pueda cambiar una cosa sin romper otra función distante / no relacionada.

Incluso si usa un estilo de codificación compacto, eventualmente tendrá más código del que cabrá en la pantalla a la vez.

Una mejor solución (de Clean Code por Robert Martin) es listar primero las funciones públicas de "alto nivel", y hacer que cada función permanezca en un nivel de detalle.

    
respondido por el Aaron Kurtzhals 23.05.2013 - 18:14
fuente
2

La mayoría de los IDE-s permitirá colapsar la primera muestra en 8 (o incluso 1) líneas pequeñas, para que pueda ver el panorama general. La segunda muestra, por el contrario, no puede hacerse ver como la primera fácilmente.

La primera muestra es más fácil de entender, especialmente para los novatos. Revela la jerarquía y la secuencia de las acciones realizadas. Además, los novatos de la OMI preferirían tener dificultades para captar la segunda muestra a la vez, porque parece bastante "aterrador" y complicado.

Entonces, si trabaja en un entorno de profesionales más o menos experimentados, preferiría la segunda muestra _ si está acostumbrado a ese estilo, puede comprender toda la idea de un vistazo. Pero debido a que en realidad hay muy pocos (si los hay) entornos de desarrollo que consistan solo de desarrolladores experimentados, la primera muestra es mejor.

P.S. Si no te gusta escribir todos esos espacios y nuevas líneas manualmente, podrías tener una herramienta automatizada para eso.

    
respondido por el superM 23.05.2013 - 17:22
fuente
2

Generalmente escribo código con sangría, similar al # 1, pero con menos líneas en blanco. Las sangrías permiten detectar fácilmente los problemas con los paréntesis. Esto, combinado con cada asignación en su propia línea, hace que las cosas sean más fáciles de leer. La finalización de tabulación permite el uso de nombres de variables más largos sin tener que escribir demasiado extra.

Sí, es más largo, pero no hay nada de malo en escribir código largo. Así como uso los párrafos de esta respuesta para facilitar la lectura, ¿por qué no hacer lo mismo en su código? Como el intérprete no sabe la diferencia *, la única persona que se beneficia es usted.

Emacs tiene un complemento VHDL que uso a diario y que embellece el código automáticamente a través de un método abreviado de teclado. Esto permite centrarse más en la codificación en lugar de dedicar tiempo al formateo.

* dependiente del idioma. Algunos idiomas, como python, usan sangrías como parte de la sintaxis, en cuyo caso el intérprete sabe la diferencia.

    
respondido por el user81965 23.05.2013 - 17:49
fuente
1

Estoy de acuerdo con lo que dijo superM. Mis dos centavos:

Prefiero el primero (no en ese extremo) porque de esa manera puedo mantener el código mucho más fácilmente. Incluso si tengo que cambiar mi propio código de hace 6 meses, no entenderé el segundo estilo tan rápido como el primero.

Lo que ves en JavaScript probablemente se escribió de una manera más humana, e incluso con comentarios, pero algunos semi-compiladores hicieron algunos cambios mecánicos (como reducir el nombre de una variable de usersFacebookID a a y eliminar todos comentarios). Esto reduce la cantidad de datos enviados a un usuario, y este es el principal obstáculo de las aplicaciones web, por lo que el sitio parece cargar más rápido. (Y al usuario final no le importa el estilo de los códigos).

    
respondido por el Ramzi Kahil 23.05.2013 - 17:57
fuente
1

Si su IDE no es compatible con el análisis y el plegado de su idioma, tal vez una forma más concisa estaría en orden, pero en general será más difícil detectar errores. La densidad de información es tan alta que fácilmente pasaría por alto algún error. Además de eso, la longitud de las líneas sería bastante larga en los casos en los que tenga que hacer varias llamadas en una función, lo que requeriría desplazarse hacia un lado. (mucho más molesto que desplazarse hacia abajo, que es para lo que están diseñados la mayoría de nuestros IDE) Si está usando un lenguaje de scripts que será interpretado en lugar de compilado, entonces querría usar un minificador antes de enviarlo. El uso de un minificador es una práctica común en las empresas de desarrollo web cuando se utiliza JS por razones de ancho de banda. En las lenguas interpretadas el espacio en blanco es ruido. Los compiladores generalmente eliminan cualquier espacio en blanco excesivo cuando tokenizan el código fuente, dejando solo información útil después del procesamiento. (ya sea a código de byte o lenguaje de máquina) Los compiladores solo tienen que lidiar con el ruido una vez. Los intérpretes tienen que lidiar con el ruido cada vez. (aunque la mayoría tiene algún tipo de almacenamiento en caché para solucionar el problema en estos días).

Al final, depende de la plataforma que use para editar su fuente y del idioma / entorno en el que desea usar su código, pero votaría por la opción 1.

    
respondido por el Onno 23.05.2013 - 18:15
fuente
1

Estoy de acuerdo con el amigo 1

Desde el punto de vista del compilador, no importa ... y la opción 2 solo le ahorrará unos pocos bytes de tamaño de archivo en su disco duro gigaByte

Desde una perspectiva humana, no te importa qué manera usas hoy, ya que sabes lo que has escrito.

Pero cuando vuelva a hacerlo en un día, semana, mes o año, o alguien más lo haga, la Opción 2 será mucho menos legible y mucho menos comprensible.

    
respondido por el Andrew 23.05.2013 - 20:34
fuente
0

¡No hagas ninguno de los dos extremos! Prefiero escribir

var Stack=function(){
    var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
    var fst=function(p){return p(function(x){return function(y){return x}})};
    var snd=function(p){return p(function(x){return function(y){return y}})};
    var empt=function(){return function(){return null}};
    var stk=empt();
    var r={
        push:function(val){stk=pair(val)(stk); return r},
        pop:function(){var top=fst(stk); stk=snd(stk)||empt(); return top},
        top:function(){return fst(stk)}
        };
    return r}

Es compacto y legible.

    
respondido por el amara 23.05.2013 - 17:53
fuente

Lea otras preguntas en las etiquetas