Cristhian Camilo Gomez Neira

Parte 1

a. Spartan programming strives for simultaneous minimization of several measures

of code complexity. What do you think is the impact of each one of these metrics
on understandability and quality?

1. Horizontal complexity: Una complejidad horizontal elevada reduce el

entendimiento del código y obliga a los programadores a pensar de mas al
momento de leer código que no sea de ellos. Siempre es necesario minimizar el
numero de caracteres por línea, ya que, al salir del campo de la pantalla, se pierde
el entendimiento y la simplicidad del código.

2. Vertical complexity: Al tener un numero grande de líneas por clase, se vuelve

totalmente tedioso buscar algún método y mantener el hilo lógico de lo que se esta
haciendo.

3. Number of Tokens: Tener artos tokens hace que para el programador sea
realmente complicado entender el código, adicionalmente entre mas grande sea
el numero de tokens es mas probable que algún método este haciendo cosas de
mas o que la clase no este haciendo lo especificado y que sea necesario subdividir
el problema.

4. Parameters: El generar parámetros que tengan la menor variabilidad e interacción

con otros componentes eleva la modularidad del sistema, propiedad que jamás se
debe dejar a un lado en cualquier desarrollo de software.

5. Varables: Las variables hacen que el programador tenga que hacer un esfuerzo
mental muchas veces innecesario para descubrir que hace cada pieza en el
software, adicionalmente las variables tienden a cambiar, es por esto que es
necesario eliminarlas siempre que sea posible.

6. Loops: Los ciclos usualmente tienen un nivel de complejidad elevado, así que
evitarlos ayudara a los programadores a ahorrarse tiempo entendiendo el código.

7. Conditionals: Al igual que los ciclos el entender los condicionales se puede

convertir en una tarea realmente tediosa, es por esto que cuando sea posible es
mejor evitarlos.

b. In your own words explain the Babylonian Tower principle. What is your opinion
about it?

El principio de la torre de Babiliona afirma que existen niveles de abstracción para

los cuales los lenguajes de programación actuales son insuficientes, es decir los
 niveles de abstracción a los que podemos llegar actualmente con el software
tienen un limite, no se extienden hacia el infinito. Opino que es un principio muy
acertado y del cual todo desarrollador debe ser consiente, debido a que muchas
veces caemos en el error de pensar que podemos llegar a abstracciones
inimaginables, siendo esto irrealista y una perdida total de tiempo, cuando la
abstracción llega a limites inimaginables es mejor tomar realizar soluciones
especificas pero realistas.

c. Discuss at least three of the rules listed as “Minimal use of control”. Give short
examples of Java code that exemplify the use of each rule.

1. Minimizing the use of conditionals by using specialized constructs such

ternarization, inheritance, and classes such as Class Defaults, Class Once and
Class Separator. El uso excesivo de condicionales no permite una clara lectura
del codigo, ejemplo.

El siguiente código calcula el mínimo entre dos números.

No es correcto,

Es correcto,
2. Simplifying conditionals with early return. Existen partes en los condicionales
donde en vez de sobrecargar con else o if else, podemos tener returns que
hagan el trabajo que buscamos, ejemplo.

El siguiente código calcula la raíz cuadrada de un numero entero.

No es correcto,

Es correcto,
 3. Simplifying logic of iteration with early exits (via return, continue and break
statements). Al simplificar la logica de iteración de manera rapida, es mas
sencillo leer el código y mantener un hilo lógico de lo que se esta haciendo,
ejemplo

El siguiente código suma un valor entero a un arreglo de números reales,

excluyendo una posición de este.

No es correcto,

Es correcto,

d. What is the relationship between Spartan Programming and two well-known

design rules: The Law of Demeterand The KISS principle?

Spartan programming aplica estos dos principios de forma efectiva, debido a que
Spartan mantiene cada estructura de forma minimal y modular como lo busca la
ley de Demeterand, y evade complejidades innecesarias como lo estipula el
principio KISS. Así usar Spartan programming es una buena alternativa para
mantener las buenas practicas en un equipo de software.

Parte 2

e. Make a report (it could be a table) of five type of tips reported by the
plugin. For each type of tip, report your agreement/disagreement, and
in case you don’t agree,explain your reasons.
Description Resource Path Location Type Comment
Tip: Abbreviate parameter pasajes to ps in method setPasajes Vuelo.java /aero/src/data line 107 Abbreviation Corrección aceptada, debido a que es mas que claro que al usar ps se refiere a los pasajes
Tip: Abbreviate parameter vuelos to vs in method setVuelos Aerolinea.java /aero/src/data line 27 Abbreviation Corrección aceptada, debido a que es mas que claro que al usar vs se refiere a los vuleos
Tip: Convert post-increment of numero to pre-increment Pasaje.java /aero/src/data line 12 Idiomatic Corrección no aceptada, en muchas ocasiones es necesario el post increment
Tip: Inline variable line into next statement Starter.java /aero/src/businessLogic line 18 Inlining Corrección aceptada, es innecesario el uso de la variable
Tip: Inline variable v into next statement Starter.java /aero/src/businessLogic line 19 Inlining Corrección aceptada, es innecesario el uso de la variable
Tip: Remove vacuous 'super()' invocation Aerolinea.java /aero/src/data line 10 SyntacticBaggage Corrección aceptada, el llamado a super() no esta haciendo nada
Tip: Remove vacuous 'super()' invocation Pasaje.java /aero/src/data line 10 SyntacticBaggage Corrección aceptada, el llamado a super() no esta haciendo nada
Tip: Remove vacuous 'super()' invocation Vuelo.java /aero/src/data line 18 SyntacticBaggage Corrección aceptada, el llamado a super() no esta haciendo nada
Tip: Reorder operands of - Vuelo.java /aero/src/data line 27 Idiomatic Corrección aceptada, siempre es preferible ordenar las variables a operar por orden alfabetico
Tip: Reorder operands of * Vuelo.java /aero/src/data line 25 Idiomatic Corrección aceptada, siempre es preferible operar primero numeros y luego variables
Tip: Reorder operands of * Vuelo.java /aero/src/data line 26 Idiomatic Corrección aceptada, siempre es preferible operar primero numeros y luego variables

f. After performing the entire analysis, do you think programmers should

adopt the Spartan Programming practices and use tools like the
Spartan plugin?Explain your answer.
Si los programadores deberían adoptar este plugin, debido a que las buenas practicas se
deben mantener siempre en cualquier equipo de trabajo, personalmente estoy
acostumbrado a usar Ruby Rubocop, plugin especializado en mantener buenas practicas en
Ruby on Rails, realmente como programadores miles de veces pensamos solamente en la
parte funcional del código y no en el estilo de este, cosa que es totalmente incorrecta,
debido a que en un grupo de desarrolladores la mayor perdida de tiempo se da al intentar
entender el código de otros o el propio, es necesario inculcar la enseñanza de estas buenas
practicas y procurar estudiar cada día libros como CleanCode.