¿Cuál de estos estilos de programación es mejor?
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
o
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
¿Cuál de estos estilos de programación es mejor?
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
o
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
En palabras sencillas:
Lo importante no es el número de líneas, sino la legibilidad del código.
Cualquier tonto puede escribir código que una computadora pueda entender. Bueno Los programadores escriben código que los humanos pueden entender. ( M. Fowler )
En los ejemplos que dio, el segundo es definitivamente más fácil de leer.
El código fuente es para que las personas lo lean.
Además, los valores intermedios hacen que el código sea más fácil de depurar.
Loscódigos de una línea, por otro lado, son útiles para mostrar a otras personas que eres "inteligente" y que no te importa.
Depende, y su ejemplo no es útil para tomar la decisión.
Si bien menos líneas de código no son siempre mejores (en algún momento, esto causa una ofuscación), generalmente lo son, simplemente porque hay menos cosas que hacer un seguimiento de cuándo tratando de entender el código.
En su ejemplo específico:
Si los nombres de los valores intermedios realmente transmiten un significado que no se hace evidente por los nombres de los métodos y parámetros utilizados para calcular esos valores intermedios, entonces ayudan a entender el código.
Sin embargo, si los nombres de los valores intermedios no agregan información, entonces hacen que el código sea más difícil de entender, ya que son un estado adicional que se debe seguir. Incluso si son inmutables, te obligan a considerar si se usan solo una vez o en diferentes lugares.
Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say '(x++ && false) || y += 2' instead of 'x++; y += 2' and the first variant is just so much more concise and clearer as you can tell because it contains no semi-colons honestly I almost threw up writing the second one I mean who wants to use a character whose name contains a word related to your butt that's just dumb and anyways semi-colons introduce lots of vulnerabilities like what if you typed 'while(true) ;' that would just keep running forever and so its clearly better to have no semi-colons to avoid problems like that overall I'd say programmer salaries should be inversely proportional to the number of newlines and semi-colons in their code because everyone knows as soon as you start using a metric like that it starts working even better than before you incentivized it
Medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de aviones por peso. (Bill Gates)
Por supuesto, menos líneas son no siempre mejores. Pero en mi experiencia, menos líneas son a menudo mejores que más líneas en términos de legibilidad y facilidad de mantenimiento. Hay excepciones, por supuesto, y su ejemplo podría ser una de esas excepciones.
Se necesita peso para construir un avión. Pero debería estar en los lugares correctos.
En la primera versión, es difícil ver qué parámetros se pasan a qué método. Así que la segunda versión es claramente mejor. En otros casos, sin embargo, puede no ser tan obvio.
La principal diferencia de la segunda versión es que le permite nombrar los valores intermedios . Puede haber casos en que este nombre sea crucial para comprender el código.
Si, sin embargo, los valores intermedios solo se llaman algo como varOne , también puedes omitirlos al alinearlos.
Parece que estás usando JavaScript, lo que cambia los parámetros muy ligeramente.
A menos que tenga una razón para almacenar esos var 's, sería mejor que no los inicializara. Sin embargo, debe hacer que la versión de una sola declaración sea lo más legible posible, agregando espacios en blanco y un comentario.
//Do X, Y, Z....
var result = methodOne(
methodTwo(
a,
methodThree(b)
),
c,
d
);
¿Menos líneas de código siempre son mejores?
El corto es simplemente no . El más largo, no , porque depende .
¿Cuál de estos estilos de programación es mejor?
Bueno, el segundo es mucho mejor en un aspecto. Si necesita depurar lo que sucede, tiene las variables que inspeccionar y más posibilidades para ubicar el punto de interrupción.
Por otra parte, no me gusta usar demasiadas variables locales, porque debo inventar los nombres para ellas. Odio tales nombres como resultado 1/2/3, porque después de un tiempo no sé cuál es para qué. Pero no quiero dedicar demasiado tiempo a inventar los nombres ... El primer ejemplo es (para mí) en realidad más legible debido a nombres de variables incorrectos en el segundo ejemplo.
Por lo general, comienzo con el primer código y lo convierto en el segundo primero cuando necesito depurar.
Sin embargo, si las expresiones son más complejas, prefiero mantener los resultados intermedios en las variables locales, pero esas variables locales deben tener nombres autoexplicativos . Solo entonces el código es más fácil de leer.
Mi regla de oro es poner cada operación en su propia línea. Esto es especialmente útil cuando se recorre el código con el depurador. También me gusta asignar el resultado de una operación a una variable antes de pasarla para poder romper y examinar su contenido. así que en lugar de
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
Yo iría
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
Si no me equivoco, los compiladores Java y .NET JIT compilarían los dos ejemplos de la misma manera.
alternativamente, escribiría un comentario muy detallado antes de la línea que explica qué es lo que estoy haciendo.
Sospecho que lo que todos quieren escuchar es "no".
El hecho del asunto es que su ejemplo no es lo suficientemente claro como para dar una respuesta sólida.
resultThirdMethod es un nombre horrible. Me parece que la primera versión es mucho más clara que la segunda.
Sin embargo, si pudiera dar nombres a sus variables (nombres que proporcionen más información que simplemente de dónde provienen los datos), entonces podría ser mejor. Todo depende de la situación actual.
En este ejemplo en particular, no encuentro que la primera versión sea más difícil de leer, es igual que leer una expresión aritmética simple como (a + f(b)) * c * d . La segunda versión no agrega ninguna información que ayude a entenderla (a menos que las variables tengan nombres significativos que ayuden a comprender un proceso complicado).
Lo que me parece un poco problemático con la segunda versión es que introduce una complejidad adicional al analizar el código. Un programador que lee el código debe pensar si se usa resultThirdMethod o resultSecondMethod en otro lugar, entonces solo para calcular result . Y si escribe un método lleno de tales declaraciones, no hay una línea de cálculo clara, debe verificar constantemente qué se calcula a partir de qué y dónde. Entonces, en este caso, si desea una versión más detallada, sugeriría encapsularla en una función separada:
function methodCombined(a, b, c, d)
var resultThirdMethod = methodThree(b);
var resultSecondMethod = methodTwo(a, resultThirdMethod);
return methodOne(resultSecondMethod, c, d);
}
// ...
result = methodCombined(a, b, c, d);
o al menos enciérrelo en un bloque de código para que el alcance de las variables sea inmediatamente visible:
var result;
{
var resultThirdMethod = methodThree(b);
var resultSecondMethod = methodTwo(a, resultThirdMethod);
result = methodOne(resultSecondMethod, c, d);
}
Depende de cuán familiarizado esté el lector con estos operadores y su dominio de problemas. Incluso si todos los métodos son funciones aritméticas, puede ayudar a romperlo.
Dividir una fórmula más grande en pequeños pasos puede arruinar la legibilidad:
(let* ((term1 (* b b))
(term2 (* 4 a c))
(discriminant (- term1 term2))
(twoa (* 2 a))
(top1 (+ b (sqrt discriminant)))
(top2 (- b (sqrt discriminant)))
(root1 (/ top1 twoa))
(root2 (/ top2 twoa)))
(list root1 root2))
versus
(let* ((root1 (/ (+ b (sqrt (- (* b b) (* 4 a c))))
(* 2 a)))
(root2 (/ (- b (sqrt (- (* b b) (* 4 a c))))
(* 2 a)))
(list root1 root2))
La división de fórmulas en pequeños pasos es lo que hace un compilador cuando genera un código intermedio. (Fortran: FORmula TRANslator.)
Las expresiones de ruptura para facilitar la lectura son útiles, pero no "Fortran it" (ir por la borda).
El mejor estilo es el que hace que el código sea más legible (para un humano, es decir, a las computadoras no les importa). Pero "legible" depende mucho de quién hace la lectura , por lo que depende del contexto. Sin embargo, esto es suficiente para responder a su pregunta exacta: "¿[es lo que sea] siempre mejor"? Luego, no , depende del contexto.
La primera persona que debe leer el código es el propio desarrollador. Si escribes un código tal que tú mismo puedas leerlo y entenderlo dentro de cuatro semanas, ya habrás hecho un buen trabajo, un trabajo mucho mejor que el de la mayoría de los desarrolladores en el industria (por desgracia).
Sin embargo, se pueden agregar algunas generalidades. Leer código implica usar el ojo y el cerebro. Los ojos humanos se cansan más rápido cuando tienen que moverse mucho, especialmente cuando tienen que moverse verticalmente (el movimiento lateral es menos un problema). Usar menos líneas de código, al igual que todas las demás cosas, permitirá al lector comprender el código con menos movimiento vertical de los ojos, por lo que es algo bueno.
Por otra parte, el análisis de sintaxis que se realiza en el cerebro querrá utilizar tantos "anclajes visuales" como sea posible y sufrirá ciertas actividades, en particular paréntesis de conteo. Difundir el código en más líneas, con sangría, ayuda al cerebro. Realmente es un intercambio entre la fatiga ocular y la fatiga cerebral, y, insisto, el punto de equilibrio correcto no es el mismo para todos.
En última instancia, es una cuestión de "buen gusto". Las personas que escriben códigos feos también son personas felices comiendo mala pizza.
Das un mal ejemplo.
La solución que da para resolver un problema es mejor tener un buen diseño para que sea comprensible y lo suficientemente buena para mantener el código corto.
Si puedes hacer que el código sea más comprensible haciéndolo más largo, es algo que hacer, pero hay un límite.
Siempre pensaré que el código que tiene un buen diseño Y se mantiene corto, garantiza una mayor comprensión a medida que es más corto.
Debes centrarte en un buen diseño y luego encontrar maneras de hacer que el código sea lo suficientemente corto para que las personas que lo lean puedan entenderlo sin que se desplacen y se desplacen.
En resumen, no hay una respuesta realmente buena para esto. Lo importante es qué tan bien divide su código en funciones y secciones, y cómo puede hacerlo corto y fácil de entender.
La cita de Bill Gates es buena, pero también está la cita que habla de una pieza de código perfecta, que es una en la que no puedes eliminar nada.
Este es uno de esos problemas que creo que tienes para decidir de qué manera funciona para cada caso por separado. Decidir si un resultado particular debe almacenarse en una variable intermedia es parte de ser un programador, parte de la nave. Utiliza las habilidades que has adquirido junto con los estándares de codificación en tu lugar de trabajo.
En los dos ejemplos creados a continuación, probablemente iría con 1A y 2A, debido a la legibilidad (demasiado ruido y redundancia en 1B, demasiado tiempo y uso indirecto de una matriz anónima en 2B). Pero realmente no se puede crear una lista exhaustiva de patrones en los que se pueda estipular una manera sobre la otra: las situaciones nuevas surgen a medida que avanza el arte de la programación.
1A:
startManufacture(loadProductName(), isProductOk(loadProductState()));
vs.
1B:
String productName = loadProductName();
ProductState state = loadProductState();
boolean productIsOk = isProductOk(state);
startManufacture(productName, productIsOk);
2A:
boolean antennaCount = storage.getCount(currentDealer, items[ANTENNA_INDEX]);
boolean chassisCount = storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING);
orderManufacture(RADIO, antennaCount, chassisCount);
vs.
2B:
orderManufacture(RADIO, storage.getCount(currentDealer, items[ANTENNA_INDEX]), storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING));
Yo diría que ambos ejemplos son igualmente malos , pero eso es solo por el código de ejemplo insuficiente. Para poder decir si uno de los dos es mejor, debe proporcionar un ejemplo real.
No hay absolutamente ninguna correlación entre el número de líneas de código fuente y la calidad del código.
Suponiendo que ignoramos el hecho obvio de que el código debe hacer lo que se supone que debe hacer, el aspecto más importante es que los lectores lo entienden fácilmente.
La forma "clásica" de lograr esto es agregar comentarios de código que describan la funcionalidad del código. En mi experiencia personal, es incluso mejor usar identificadores descriptivos para métodos, variables y constantes.
Si, por ejemplo, ve una secuencia de código fuente como esta, entenderá de inmediato lo que se supone que debe hacer, y puede examinar los métodos y las variables individuales para (con suerte) determinar con la misma facilidad que hacen lo que se supone que deben hacer. hacer:
if (a_new_game_is_starting && hand_not_dealt_yet()) {
deal_new_hand_to(all_players_at_table);
}
En el ejemplo anterior, no es necesario agregar ningún comentario. ¿Qué diría un comentario que no se entiende fácilmente a partir del código real? Esto es algo por lo que hay que esforzarse: a no es necesario agregar comentarios al código para describir lo que hace.
Esto no es algo que sea difícil de hacer. Todo lo que necesita es que piense en lo que realmente está tratando de lograr y nombre sus identificadores desde un punto de vista funcional.
Más importante que legibilidad es mantenibilidad , porque la razón principal por la que leemos el código es para mantenerlo. Mantener a menudo significa realizar cambios en el código debido a cambios pequeños o grandes en los requisitos.
Entonces, piense en los cambios en los requisitos que podría haber, e intente que sean lo más fáciles de hacer posible. Si puede llevar al mantenedor directamente al código relevante y dejar que realicen los cambios con la edición mínima, ¡pensarán que usted es un gran programador!
OTOH, si la gente está leyendo el código para verificar su corrección, asegúrese de que su razonamiento sea claro por qué es correcto. Si las personas dudan de la exactitud de su código, es probable que lo vuelvan a escribir, lo que es probable que lo rompa. Para evitarlo, asegúrese de que el código se explica por sí mismo.
Además, asegúrate de explicar tus decisiones relacionadas con el rendimiento, porque una forma en que un buen código se destruye es reescribirlo en un intento equivocado para hacerlo más rápido.
return ($this->main->context != "ajax" || in_array($this->type, $this->definition->ajax)) ? eval('return method_exists($this,"Show'.ucfirst($this->type).'") ? $this->Show'.ucfirst($this->type).'('.(count($args) ? join(",",array_map(create_function('$a','return (is_numeric($a) || preg_match("/^array/",$a)) ? $a : "\"".$a."\"";'),$args)) : "").') : null;') : '';
Me topé con este código en un proyecto que heredé hace algún tiempo. Creo que demuestra muy bien por qué es una mala idea intentar usar el menor número de líneas posible. Es completamente ilegible e imposible de depurar.
La ortografía de las cosas puede ayudar no solo con la legibilidad sino también con la capacidad de escritura.
Esto podría parecer una pregunta de entrevista tonta pero una vez en una entrevista me pidieron que escribiera una función para rotar una imagen 90 grados. Se proporcionan la fuente y el destino (no es necesario realizar ninguna asignación de memoria) y el ancho y la altura de la fuente. Sí, es un problema fácil. Le sugiero que lo haga antes de continuar y ver si tiene algún problema.
.
Lo hiciste? ¿Lo probaste? Desde que me hicieron la pregunta en una entrevista, también la utilicé en las entrevistas y lo que encontré fue que muchos programadores se confundirían. Escribirían un código como este
void Rotate90(const Pixel* src, Pixel* dst, int width, int height)
{
for (int y = 0; y < height; ++y)
{
for (int x = 0; x < width; ++x)
{
dst[???] = src[???];
Y ahí es donde se atascarían. A veces gastaban hasta 20 minutos en la pizarra tratando de averiguar qué es lo que hay en ellos. zona. Muchas veces ellos piensan que tienen la respuesta y escriben cosas como
dst[x * width + (height - 1 - y)] = src[y * width + x];
obteniendo el hecho de que usar width con dst es incorrecto. O a menudo se mezclan x y y en uno u otro lado.
El problema es que x , y , width y height todos significan swap porque al girar 90 grados el destino se convierte en ancho de alto y alto de ancho, lo que hace que las referencias a estas variables sean confusas. Siempre deseé que un programador agregara algunas variables más para ayudar a que sea más claro para ellos mismos, como este
void Rotate90(const Pixel* src, Pixel* dst, int src_width, int src_height)
{
int dst_width = src_height;
int dst_height = src_width;
for (int src_y = 0; src_y < src_height; ++src_y)
{
for (int src_x = 0; src_y < src_width; ++src_x)
{
int dst_x = src_height - src_y - 1;
int dst_y = src_x;
dst[dst_y * dst_width + dst_x] = src[src_y * src_width + src_x];
}
}
}
Me pareció que dividir las cosas en sus significados explícitos haría mucho más fácil escribir el código y mucho más fácil evitar errores. Sentí que si veía a un programador hacer esto, pensaría en ellos como prudente y los calificaría más alto.
Sí, hay algunas optimizaciones que puedes hacer. Ese no es el punto. Sí, las matemáticas dentro de la última declaración también podrían dividirse en líneas separadas. Eso también estaría bien. El punto es que agregar más líneas hace que sea más fácil de entender para la persona que escribe el código, no solo una persona que lo lea más tarde. En este caso, debido a que el significado de x , y , width y height son diferentes en relación a dst vs src haciendo variables separadas para cada uno hace que el código sea mucho más claro para leer Y escribe .
Continuando ... de manera similar, a menudo es útil poder inspeccionar valores antes de llamar a una función, especialmente si se trata de una función en una biblioteca o en el sistema en el que no puede ingresar. Si escribes un código como este
ctx.lineTo(x + Math.cos(angle) * radius, y + Math.sin(angle) * radius);
vs esto
var circleX = x + Math.cos(angle) * radius;
var circleY = y + Math.sin(angle) * radius;
ctx.lineTo(circleX, circleY);
En el segundo estilo, ahora puede detener el depurador en la línea ctx.lineTo e inspeccionar circleX y circleY . Es posible que encuentres que son NaN , lo que probablemente te haga verificar que x , angle y radius son realmente los nombres correctos, algo que no podrías hacer en el depurador. (El modo "estricto" probablemente atrapa eso). También te permite registrar fácilmente los valores
console.log("cx: " + circleX = ", cy: " + circleY);
Otro ejemplo más,
class Person
{
public:
...
const String& name() const { return m_name; }
int age() const { return m_age; }
private:
string m_name;
int m_age;
};
vs
class Person
{
public:
...
const String& name() const
{
return m_name;
}
int age() const
{
return m_age;
}
private:
string m_name;
int m_age;
};
Sé que algunos de ustedes gritarán en este ejemplo porque su estilo personal quiere que los buscadores y los programadores sean de 1 línea pero me escuchan ... al depurar, dependiendo del depurador, en el primer estilo si coloca un punto de interrupción en age o name el depurador no podrá inspeccionar this ni m_age ni m_name , por lo que no tendrá forma de verificar antes de que la función devuelva lo que devolverá o a qué objeto está haciendo referencia. En el segundo estilo, puede colocar puntos de interrupción en las líneas return y podrá inspeccionar todo.
El punto de esta respuesta es que más líneas a menudo no solo son buenas para la legibilidad. También suele ser bueno para la capacidad de escritura y para la depuración.
No.
De hecho, iría más lejos y diría que pocas líneas de código rara vez son mejores.
Ahora, eso no quiere decir que no se encapsulen las llamadas de métodos, sino en el ejemplo anterior, cuando se realiza la depuración de errores: va a ser muy difícil ver el resultado de los métodos tres y dos métodos cuando todo está en línea de esa manera.
Un montón de código en un método que hace muchas cosas es malo. Muchos de los pequeños métodos que se llaman y asignan a las variables locales mejoran la legibilidad, mejoran la capacidad de mantenimiento y no tienen un costo real, ya que el compilador se optimizará.
Piensa desde lo básico.
¿Por qué escribimos código, cuando queremos agregar alguna funcionalidad y entregarlo a otro desarrollador, puede entender su código o no, por qué es importante estructurar, por qué uno debe seguir las pautas estándar básicas?
Las respuestas son las siguientes:
Por qué ponemos comentarios en nuestro código.
Para los desarrolladores (que pueden aprovechar esta pequeña documentación para comprender el código y la funcionalidad de la rutina), las computadoras o los sistemas de decodificación / codificación simplemente omiten los comentarios, y solo se ocupan del código real. Por ejemplo: paquete de desarrollo y versión minifest,
Si utilizamos la segunda opción, es fácil de leer y ampliar, y un nuevo desarrollador no necesita mucha orientación al extender nuestro código. Pero si utilizamos la primera opción, que está menos documentada, solo la persona que escribió este código o puede entender su propósito, y no todo el equipo. Estamos trabajando en un ciclo de desarrollo rápido en el que tenemos que trabajar en diferentes proyectos y no tenemos mucho tiempo para coordinarnos con otros departamentos, por lo que en este caso, el segundo enfoque funciona bien y otro desarrollador puede ampliar la funcionalidad fácilmente. Se trata de la dependencia: trabajamos en la modularización del código donde miles de desarrolladores trabajan en miles de funciones y solo saben qué devolver, qué pasar a la función y qué variable se asigna a qué, y para qué.
Para un solo usuario o para programas pequeños, el primer enfoque es correcto cuando el equipo está trabajando en conjunto, pero cuando la gente está trabajando de forma remota qué hacer, ese es el punto que probablemente vaya con la segunda opción, la optimización es otra técnica para acortar el código, pero solo después de que estemos feliz con la salida.
la computadora es máquina, solo entiende el lenguaje de cero, pero si escribimos un código que guíe a otros desarrolladores acerca de programe como segundo enfoque, nuevas personas también pueden usar esto como guía o para editar el programa,
La computadora entiende 0 y 1 y el humano puede entender los comentarios.
así que me gusta el segundo enfoque que ayuda al desarrollador a entender qué está pasando dentro del bucle o la función
por ejemplo: ** suponga que si está trabajando en un proyecto y lo usa de 1ª manera y en algún caso tuvo otra tarea y otro desarrollador está trabajando en su código, ¿entiende esto o no? no es cuestión de simplicidad ni de cómo documentar, sino de cómo se trata de cómo enviar nuestro código a nuestro socio cuando él quiere actualizar el código con soporte sin problemas.
El segundo enfoque es bueno para socios y desarrolladores, y las primeras opciones funcionan bien cuando estamos trabajando en una plataforma web o escribiendo guiones donde el tamaño del código importa
TL; DR:
Documente su código . Escribe comentarios cuando lo estés escribiendo. Le ahorrará un tiempo valioso tres meses después de volver a la línea y no podrá entender lo que está haciendo el código. Además, sus compañeros de trabajo lo elogiarán cuando puedan entender realmente lo que está haciendo y son capaces de extender / refactorizar o modificar el código escrito por usted.
Sin embargo, no exagere .
Si menos líneas de código tienen sentido, siga adelante y hágalo en tantas líneas. Pero no no haga que escribir menos líneas haga que tenga que agregar comentarios para explicar su código. Debería ser lo más explicativo posible.
¿Qué pasa con
var result = methodOne( methodTwo( a,
methodThree(b)
),
c,
d
);
Esto probablemente se mejorará aún más con la ayuda de un IDE decendente, imprimiendo líneas que coincidan con las llaves.
En pocas palabras, el cerebro humano, para la gente más común , puede contener 7 cosas diferentes, en el mejor de los casos. Esto es para gente común, y esto es un promedio. (Me temo que no he encontrado la fuente de mi declaración)
Como consecuencia, si desea escribir código que cualquiera pueda leer, no debe usar más de 7 variables / conceptos / funciones / operaciones diferentes.
por ejemplo:
rotate(translate(rotate(translate(circle,50,0),0,10,pi),-50,0),0,10,pi)
ahí es muy difícil entender lo que está pasando, sorprendentemente estas líneas no hacen absolutamente nada en el sentido geométrico:
circle = translate(circle,50,0)
circle = rotate(circle,0,10,pi)
circle = translate(circle,-50,0)
circle = rotate(circle,0,10,-pi)
esta es la razón por la que es más fácil leer funciones que tienen menos de 40 líneas de código también.
Ambos ejemplos son realmente malos.
¿Qué sucede si methodOne falla? ¿Qué pasa si methodTwo falla? ¿Qué sucede si methodThree falla? Obviamente, omitió la comprobación de errores para mayor claridad aquí, pero es un punto importante: agregar la comprobación de errores agregará más líneas de código (que por su cuenta deberían responder a su pregunta), así que líneas adicionales de código significativo que en realidad, hace algo nunca debe verse como algo malo.
Aparte de eso, todavía preferiría el segundo ejemplo. La razón por la cual es porque es más fácil de mantener; puede insertar más fácilmente una llamada a methodTwoPointFive entre las llamadas a methodTwo y methodThree, por ejemplo, si los requisitos futuros lo necesitan.
Lea otras preguntas en las etiquetas code-quality coding-style clean-code