Cosas simples que ayudan mucho - La refactorización más simple
Bueno, esta es la segunda entrega de 'Cosas simples que ayudan mucho' de mi blog. Y si bien gracias a @OscarRyz por explicar singleton en la entrada anterior no fue necesario hacer una entrega de esta nano-sección sobre singleton. A esto @OscarRyz ha propuesto algunos temas, uno de ellos es abordabo en esta entrada.
Comencemos con que es la refactorizacón de código. Seguro que cómo yo muchos de ustedes han llevado la materia de cálculo integral y diferencial (seguro a más de uno le dan pesadillas hoy XD), en donde existe algo que llamamos refactorización que es una manera más ¿simple? de expresar un resultado después de integrar o derivar.
Pues bien en programación es algo similar, expresar de una manera más simple y entendible el código que picamos.
Refactor en las propiedades
Si bien algo a lo que le hachaca a Java es lo verborreico que es. Si a esto le agregamos que los programadores puristas hacen algo cómo:
¿Qué tenemos?, de entrada si todo está bien definido, pero es un código muy WET (véase DRY), ¿porqué?, pues porque repetimos una cantidad de veces "private String". Algo que lo deja muy simple y fácil de entender es:
class Persona{
----private String
--------nombre,
--------apellidopri,
--------apellidoseg,
--------calle,
--------colonia,
--------matricula;
----private String
--------nombre,
--------apellidopri,
--------apellidoseg,
--------calle,
--------colonia,
--------matricula;
/*Seguido de la pleyade de métodos accesores */
}
Cómo pueden ver es algo más limpio y sano, podemos agrupar todas las propiedades de un objeto y de un vistazo ver el tipo y ganamos la ventajas que en algunos IDE tenemos la capacidad de collapse con esta práctica.
Refactor en los métodos accesores
Ya hemos visto en las propiedades, pero también es posible en los métodos accesores (este creo lo siguen muchos). Primero el paso de parámetros (esto también aplica para el constructor). Suponiendo tenemos un código cómo el siguiente:
public void setNombre(nombre){
----this.nombre = nombre;
}
----this.nombre = nombre;
}
¿Qué tiene de malo?. Bueno en general nada, pero (por lo general) los métodos accesores son cosas muy simples y que se pueden reducir a una línea y a quitar ese this que es obvio es una propiedad de dicha clase, dejando algo cómo:
Lo que me parece bastante legible y más explicado.
El refactor del singleton
Para finalizar tenemos el típico extracto de código de un singleton:
class Singleton{
----private static INSTANCE;
----private static INSTANCE;
----private Singleton(){}
----public static Singleton getInstance(){
--------if(INSTANCE == null)
------------createInstance();
--------return INSTANCE;
----}
----private static Singleton createInstance(){
--------if(INSTANCE == null)
------------INSTANCE = new Singleton();
--------return INSTANCE;
----}
}
Creo que podemos hacer algo cómo:
class Singleton{
----private static INSTANCE;
----private static INSTANCE;
----private Singleton(){}
----public static Singleton getInstance(){
--------return INSTANCE == null ? createInstance() : INSTANCE;
----}
----private static Singleton createInstance(){
--------INSTANCE = new Singleton();
--------return INSTANCE;
----}
}
Dejando con un sencillo y cómodo ternario para el método getInstance en una sola línea.
Bueno, espero les guste y les sirva este artículo. Saludos.
- wishmaster77's blog
- Inicie sesión o regístrese para enviar comentarios
Comentarios
Programa siempre tu código
Yo soy el psicópata violento que si encuentra código como este te irá a buscar. Yo prefiero una instrucción por línea y juegos de llaves incluso en estructuras de control vacías o que contienen una sola sentencia.
Pero todo es cuestión de estilos y gustos. Seguramente habrá otros psicópatas que buscan mi cabeza.
Re: Programa siempre tu código
----print("FLSMDFR");
print("X vale 0");
else
----print("X no vale 0")
Si no eres capaz de ver el error ahí, creo que es cuestión de ser más observador. La duda es, ¿porqué es malo tratar de evitar palabras repetidas, ahorrarse comparaciones con ternarios y demás?; desde mi punto de vista es menos código y mucho más entendible; se ve más elegante.
Re:Re:Programa siempre tu código...
¿Más bien quizó decir "documenta" en vez de programa?, como que suena más lógico. Tal vez se refería a eso. No tanto que estuvieras mal wishmaster77 sino que tal vez quería un poco más de explicación
Te refieres al ";" de la
Te refieres al ";" de la línea 5???
Jajaja, ya en serio, a mi se me hizo más fácil encontrar el error(a simple vista y sin ayuda de algún IDE) con llaves que sin llaves:
if(x == 0){ ----print("FLSMDFR"); } print("X vale 0"); //Error else{ ----print("X no vale 0"); }Pero sigue siendo cuestión de gustos y costumbres, aunque es una buena practica siempre poner las llaves.
Código ofuscado
Parece que está mal entendido lo que significa DRY, puesto que trata de evitar la repetición de procesos, no de eliminar la legibilidad de código.
Normalmente un programador utilizando algún entorno de desarrollo moderno jamás va a escribir ese código manualmente. Simplemente se escribe el tipo y nombre de la variable, se aplica un comando del IDE y ya tenemos modificadores de acceso y métodos.
Si nos vamos a los extremos de no querer "repetir" el acto de teclear terminaremos en que lo ideal es el código ofuscado, con variables de una letra y demás aberraciones que llevarían a cualquiera a querer ser psicópata.
Recordemos que el término DRY se utiliza para centralizar procesos, de manera que cambios posteriores se hagan únicamente en un solo lugar y no haya repetición de estos procesos en distintos lugares, lo que lleva a pesadillas de mantenimiento, al igual que el código ofuscado.
Si lo que no te gusta es el tener que poner getters y setters está la opción de integrar clases de Groovy o algún otro lenguaje que se compile sobre la VM.
En realidad me refería a
En realidad me refería a entender cosas como este código que postearon hace unos días. A veces abreviar ciertos procesos produce un código difícil de entender. Y no digo que lo que haces esté mal, sólo que no es para usarse en todos los casos.
---int arreglo[] = new int[]{10, 20, 30, 40, 50, 70, 80, 90, 100, 90,
------numero = ((numero != 100) ? 0 : 999999),
------numero = 10, 200, 300, 400
}
/** IMPRIMIENDO EL VALOR DE NUMERO **/
/* System.out.println ("imprimiendo el valor de numero: " + numero);*/;
/***/
for(int i = 0; i <= 10; i++)
---numero = i;
---imprimeValor( String.valueOf(arreglo[numero]) );
}
Refactorización simple
El refactor de propiedades no me ha tocado verlo en algún proyecto todavía,, y no sé en realidad si en gral. ayuda o perjudica hacerlo de esa forma. Con lo de los setters no estoy muy de acuerdo en la forma en que se plantea el refactor, además de que generalmente esos métodos son introducidos por el mismo IDE, y finalmente estoy completamente de acuerdo y muy a favor del uso de ternarios en el caso del tercer ejemplo.
Saludos a la comunidad.
@Carraro "programa" es
@Carraro "programa" es correcto. La documentación finalmente no se ejecuta. Mejor aún sería tener código que no necesite documentación.
Comparemos:
if( p.edad() > 18 && p.edad() < 60 && ! p.puesto() == Puesto.GERENTE
&& Calendar.getInstance().get( Calendar.YEAR ) - p.fechaIngreso().year() > 1 ) {
lista.add( p );
}
...
Con:
list.add( p );
}
Que nos muestra más claramente que regla de negocio se está validando.
Obvio tenemos que definir el método, pero ahora tenemos la ventaja de que esté método hace una sola cosa:
boolean cumpleAntiguedad = Calendar.getInstance().get( Calendar.YEAR ) - p.fechaIngreso().year() > 1;
return p.edad() > 18 && p.edad() < 60
&& p.puesto() != Puesto.GERENTE
&& cumpleAntiguedad;
}
Pareciera contraproducente al principio, porque tenemos que escribir un nuevo método, pero a la larga, esto ayuda al mantenimiento. Cuando un método le delega a otros partes significativas, se hace más fácil que alguien más lo modifique sin riesgo de romper otras partes. Este es un ejemplo burdo para revisar la edad, puesto y antigüedad, pero podría ser algo mucho mucho más complejo.
See also:
- http://www.refactoring.com/catalog/extractMethod.html
- http://www.refactoring.com/catalog/introduceExplainingVariable.html
Ya entendi
Gracias por la corrección @OscarRyz
Creí que se refería a la documentación(que considero debe si existir) del código .
El ejemplo está bien, pero pensé que @vicho se quejaba de la documentación.
Por ejemplo, si en un proyecto que es necesario realizarle alguna modificación ¿no es mejor contar con documentación y asi ahorrar tiempo?
0_o
Definitivamente. De hecho se
Definitivamente. De hecho se necesitan ambos, documentación de alto nivel para entender "el big picture" y una programación adecuada.
La documentación sirve para quién va a usar el software, el código bien escrito para quién va a darle mantenimiento. :)
En efecto. Sin embargo creo
En efecto. Sin embargo creo que mi código está auto explicado (o así me lo han dicho ya varias personas); no me ahorro cosas ni estoy poniendo ejemplos (cómo el tuyo). Por lo tanto (desde mi punto de vista) no viene al caso tu comentario, estamos comparando las peras con los caballos. Y en ninguna parte de mi post dice: "Son universalmente útiles"; sin embargo en mi experiencia ayudan mucho.
DRY en general significa
DRY en general significa "Don't Repeay Yourself"...Y en concepto podemos decir: "No repitas lo que ya has escrito", sean procesos o código. Con lo del comando de un IDE y demás, pues ya es de cada quien. Digo a mi no me gusta ningún IDE y de no forzarme a usarlo prefiero utilizar gEdit o Textmate o E.
Lo que no entiendo es porqué dicen que mi código es difícil de mantener.
Jejeje...si está bueno para
Jejeje...si está bueno para gente cómo yo (que no usa IDE).
Sugerencia
tal vez para otra entrega puedas decir mas o menos como se deberia de ordenar el codigo en un POJO. yo tengo mi propuesta. por ejemplo cuando se usa throws Exception en los metodos algunas veces no te ayuda del todo, la exception es un poco vaga, pero si usas try-catch y le pones informacion relevante te ayuda de mucho y si aplicas lo que posteaste en tus dos entregas a lo mejor sale algo bueno. Bueno es una sugerencia
Re: Refactorizacion
Hola
La Refactorizacion va mas alla de reescribir el codigo para reducir lineas.
La refactorizacion es realizar cambios estructurales en el codigo que no afecten la funcionalidad actual. ¿Por que alguien invertiria tiempo en hacer esto? Las razones pueden ser por que necesitas reutilizar el componente, ampliarlo o darle mantenimiento y el codigo nacio sin forma, sin diseño o no estaba preparado para lo que necesitas ahora.
Algo que te facilita la refactorizacion es seguir estandares, como mencionaron..."Codifica como si quien le va a dar mantenimiento a tu codigo es un psicopata..." Se refiere a que codifiques de tal manera que cualquiera que conoce los estandares pueda darle mantenimiento al codigo y pueda aplicar una refactorizacion o mantenimiento sin sufrir primero por tratar de interpretar el código y despues entender la funcionalidad.
Saludos
Yo le quitaría el "va más
Yo le quitaría el "va más allá" por "no es para".
Algunos refactorizaciones incluso agrega más líneas de código o nuevas clases. Algunas los reducen.
La razón como mencionas es para "mejorar el diseño" de una aplicación existente y es parte fundamental del TDD ( a su vez los refactorings necesitan pruebas unitarias para saber que nada se rompió )
Al mejorar el diseño ( sin cambiar funcionalidad ! ) se le puede dar más flexibilidad a nuestro software permitiendo que se adapte a los nuevos cambios.
Alguna vez han encontrado una pieza de código, que cada vez que se encontraba un nuevo escenario se le tenía que poner un if más?
Terminando en algo como:
if( whacha whacha ) {
if( whacha whacha ) {.
if( whacha whacha ) {
// hasta que se pierde al fin del scroll
}
}
}
}
¿Y en cada cambio se le ponían nuevas variables y más y más kilómetros de código?
La razón es por que el diseño se esa pieza no estaba preparada para cambios. Lo cual inicialmente no es malo, cada pieza debe de estar preparada para lo que está preparada, ni más ni menos ( es decir si un método acepta un entero, validar contra entero y no contra otra cosa que en el futuro pudiera haber ). No se debe de hacer un código que este preparado para adivinar el futuro y saber que escenario se va a presentar dentro de un año.
En vez de esto, lo que se puede hacer es que cada vez que se agreguen nuevos cambios, se encuentren patrones en común o deficiencias en el diseño ( ver : Code smells ) y mejorarlos con un refactoring.
A veces la solución esta tan sencilla como reemplazar condiciones anidadas con condiciones guarda ( como que eso de la traducción no me suena bien )
return whacha 1
}
if( !whacha whacha && whacha !whacha ) {
return whacha 2
}
if( whacha > whacha && whacha < whacha ) {
return whacha 3
}
Otras va más profundamente como reemplazar las condiciones con polimorfismo
En fin, el tema es muy amplio.
Si alguién puede, regalese de fin de año este libro: Refactoring: Improving the design of existing code
El psicopata que le de mantenimiento a su código y que sepa donde viven, se los va a agradecer :)
Soy nuevo
Soy nuevo programando. Sólo quiero decir que el aporte que hace wishmaster77 me parece interesante, en el sentido que es un aporte corto pero vaya que si ha creado comentarios. Me gustan este tipo de aportes porque con cosas tan atómicas (es decir muy pequeñas o que hacen una partecita de algo más grande), se entienden nuevas cosas. Felicitaciones y gracias por el aporte está bien interesante esta comunidad. Seguiré ahondando en esto de escribir el código refactorizado ya que he escrito algunos y Dios!!!! el tal piscópata que lo tenga que mantener terminaría primero recluido en un hospital al tratar de entenderlo!!!
PD: Estoy exagerando. Gracias
Re: Re: Refactorizacion
Por eso el tema se llama: "La refactorización más simple". ;)
Sé que es posible refactorizar utilizando estándares y flujos mejor escritos. Autodocumentando el código (gracias por el ejemplo @OscarRyz), entre otras tantas cosas.
No quise decir que era lo único, universal y mejor. Sólo las cosas que (en mi experiencia) ayudan mucho. Y de nuevo digo si alguien me puede decir: ¿Qué es lo difícil, no comprensible y poco mantenible de mi código?
Re: Soy nuevo
Gracias =).
Y pues con tu código, no te claves mucho. Digo lo mejor es aprender o entender cosas cómo patrones de diseño, paradigmas de programación, etc. Recuerdo cuando leí un libro de Pragmatic Programmers, el cual dice: "Seguro si aprendes orientado a objetos programarás diferente en C".
No te apures todos en esta vida hemos cometido errores o escrito cosas =S. Un ejemplo, cuando estudiaba el TSU veías cosas así:
/*Propiedades ¿static? por acá*/
----public static void setNombre(String Nombre){
--------this.Nombre = Nombre;
----}
}
En donde veías herejías de ese tipo. Claro que mucha de la culpa era de los profes que nos explicaban así, ya después de que entiendes orientado a objetos sabes que eso es una herejía casi cómo decir que la tierra es cuadrada.
¿Qué tiene de malo el código?
Pues en general no es malo, simplemente no es estándar. Es bueno seguir convenciones de codificación.
Para el primer caso asquí está la convención que no se sigue:
http://www.oracle.com/technetwork/java/codeconventions-141270.html#2992
Para el segundo caso no veo ningún problema, la palbra reservada "this" sirve para esclarecer las cosas al igual que el guión bajo, que recuerda mucho a ciertos estándares de C.
Con el caso del singleton el "refactor" crea un comportamiento diferente, al final ninguno de los dos garantiza un singleton en un ambiente multi-hilo, pero el código antes del refactor trata de asegurar que si dos hilos llaman a createInstance() el que enttre primero al método cree la instancia.
Podría considerarse un "refactor" solamente si sabemos que el código será utilizado en una situación "x" en donde ambos códigos se comportarán de la misma manera.
El uso de un IDE facilita ciertas tareas y muchas veces promueve también el seguimiento de estándares, aunque quien no quiera o no le guste usar un IDE no debe abandonar el seguir convenciones cuando es muy probable que su código será mantenido por alguien mas,
multi-hilo
Para que el método
createInstancesea seguro de usar en ambientes multi-hilo:if (inst == null) {
synchronized (MiClase.class) {
if (inst == null) {
inst = new Objeto();
}
}
return inst;
}
El doble
ifes necesario porque al llegar al primerifdos hilos al mismo tiempo, entran ambos al bloque, pero sólo uno entrará a la vez al bloquesynchronizedy ahí el primer que entre tiene nuevamente la misma condición que se sigue cumpliendo, y crea el objeto; al salir de ahí, el segundo hilo (y todos los demás que estuvieran esperando en elsynchronized) entran a la sección crítica pero la condición ya no se cumple así que ya no crean nada.En ambientes de Java 5 o superior, puedes agregar
volatilea la declaración de la variable estática donde guardas el singleton (insten el ejemplo que puse) para asegurar que no haya bronca con optimizaciones del compilador o del JIT (gracias a OscarRyz por la liga).Para el primer ejemplo
Para el primer ejemplo es simple vislumbrarlo, existen varias cosas, supongamos que tenemos 3 variables X, Y, Z en el principio definidas como String segun la forma que propones seria asi:
private String X, Y, Z;bien veamos hay necesidad de que Z ya no sea String sino Integer hay que cambiar a algo como esto:
private Integer Z;
Con lo cual requiere un cambio de dos lineas, ahora se necesita tener valor por default en X con lo cual el codigo se tendria que modificar asi:
private Integer Y;
private String Z;
Entonces de que sirvio refactorizar del modo que propones??? Y mas aun el cambio se hizo en varias lineas, lo que aumenta la posibilidad de errores,
ademas basandonos en el estandard que se menciona en otro comentario creo que el standard ayuda a tener mas claro el codigo, en este ejemplo nada mas se tienen 3 variables, y es facil entenderlo, pero imaginate 20 variables separadas por comas, creeme lo digo por experiencia se hace muy dificil entender ese tipo de codigo.
Re: Para el primer ejemplo
¿No se te ocurre algo cómo?:
/**/X = "Este es el valor default de X",
/**/Z = "Este es el valor default de Z";
private Integer Y = 0;
Y pues, no será estándar, pero pues limpia tu código. Digo, eso de tener:
private String y = "y";
private String h = "h";
Tienes 4 palabras demás, siendo que algo bien ordenado cómo:
/**/ x = "x",
/**/ y= "y",
/**/ z = "z";
/* Y también algo cómo */
private int
/**/ numero = 12,
/**/ cantidad = 15;
Te ahorras el repetitivo trabajo de teclear "private ${tipo} ${nombre} = ${valor}" una n cantidad de veces. Siendo que con un sólo "private ${tipo}" basta para n "${nombre} = ${valor}". Claro que con lo de los IDE te ayuda, pero (como ya dije) en mi caso no me agrada utilizarlos.
Son sólo recomendaciones, no estoy diciendo que eso sea lo correcto puro y mejor. Sino algo que en lo personal ayuda mucho y con código más limpio, esto sobretodo nos sirve en JAVA porque no tenemos cosas cómo #region.
refactoring
Pero eso no es refactoring. Simplemente son cambios estéticos.
10-4 ;)
10-4 ;)
Sigo diciendo, no es limpiar
Sigo diciendo, no es limpiar el codigo, al contrario lo hace menos entendible, bueno al menos yo no lo entenderia, aqui son tres variables pero si tienes muchas mas complica todo, bueno tal vez es que estoy acostumbrado a que la mayoria de los codigos que he visto en JAVA manejan este standard, y pocos muy pocos ( que si los he visto ) hacen lo que propones y al menos a mi me ha resultado mas dificil entender codigos que se manejan asi.
@ezamudio es cierto esto no es refactoring de hecho al hacer refactoring las modificaciones serian en lo funcional, tratar de mantener las premisas DRY (dont repeat yourself ) y KISS (keep it simple stupid) y es uno de los pasos obligatorios por los que debe de pasar todo aquel que pretenda hacer TDD (Test driven development), pero creo que este post se refiere un poco a hacer codigo con menos lineas, aunque el costo es a mi parecer el hecho de que no es entendible, con todo respeto, puesto que cada quien puede programar como le plazca...
To mundo puede programar como le plazca
Creo que quinteroac está parcialmente en lo correcto con esta afirmación. Si eres un programados aislado del mundo que vive en una caverna y no tienes internet puedes hacer con tu código lo que te plazca. En cambio, si convives con muchos programadores y desarrollas un código que debe ser tocado por muchas manos, entonces deberás encontrarle sentido al por qué tu mamá te decía que ordenaras tu cuarto.
Cuando el código va a ser leido y modificado por varias personas es necesario que existan estándares de programación que le facilitarán la vida a todos, así como a tu mamá se le facilita el encontrar las cosas en un cuarto ordenado. Imagina un lugar común como una biblioteca pública en la que cada persona pusiera los libros en donde mejor le pareciera que deben ir. Aunque existiera un gran artista que los acomodara de forma tal que los títulos formaran un poema en el estante, esto no sería muy útil para las personas que quieren consultar alguno de estos libros.
Mi punto es que aunque puede resultar muy agradable, visualmente o en cualquier otro sentido, el hacer "refactorizaciones" de este tipo, no son una buena práctica al no seguir estándares generales y pueden retrasar el entendimiento del código para otros.
Si la idea en general es escribir menos líneas de código entonces yo creo que es mejor intentar otro lenguaje, los lenguajes script vienen muy bien para eso y hay varios muy interesantes que se compilan sobre la máquina virtual de java.
Re: To mundo puede programar como le plazca
En general el comment va para todos. Digo hablan cómo si vivo aislado haciendo programas que sólo yo utilizo o sin trabajar en un equipo lo que en la actualidad considero imposible (al menos para proyectos grandes). Lo que he recibido de mis colegas de trabajo es un: "Me gusta cómo ordenas tu código".
Ahora con eso de: "No es el estándar", pues bueno ya es de cada quién, pero alguien que no es lo suficientemente observador y que se pierde "porqué algo no sigue el estándar", que me disculpe pero no es un programador, más bien es un seguidor del manual, un programador debe ser capaz de entender las cosas con o sin el estándar; no digo que no batalle, pero debe ser capaz.
Disculpen pues que haya posteado algo así, esto me deja en claro algo, no volveré a postear algo desde mi experiencia (la cual seguro dicen que es nula ;). Y de ser posible haré varios borradores para que me comenten e ir adaptando el post a lo que mejor les parezca, lo que menos quiero causar son problemas o peleas.
Saludos.
wishmaster77
Yo te diría que no te lo tomes personal. A mi parecer fue un buen post porque generó una discusión interesante.
Sobre los convenciones de código.
Es verdad lo que dice Wishmaster77, debemos de tener la capacidad de leer cualquier código de otras personas si conocemos el lenguaje.
Cada equipo debe de ponerse de acuerdo ANTES de que empiece el proyecto sobre que convenciones seguirán; en ese sentido, se ponen de acuerdo para su propio estándar. Si el equipo define que todas las clases deben empezar con minúsculas y las variables con mayúsculas, y cada llave en su propia linea, ni modo, aunque se vea feo ha de seguirse.
{
private int CONTADOR;
unaclase( int VALOR_INICIAL )
{
CONTADOR = VALOR_INICIAL;
}
}
El objetivo que se persigue aquí es que cualquiera del equipo le pueda dar mantenimiento y se cree un entendimiento común de como escribir las cosas.
Lo que propone acá Whishmaster son sugerencias de como ordenar el código para hacerlo más claro ( obvio, la claridad es un concepto subjetivo y habrá a quién le parece menos claro ) pero sigue siendo una opinión válida.
A falta de una convención por proyecto se toma la de Sun ( ehem la de Oracle ): Code conventions for the Java programming language.
Tener una convención por default es importante porque crea un sentido común, si bien es cierto que a la computadora le da exactamente lo mismo, que escribamos:
public
int
a,c,b,d;
private
String
e, f, g;
}
vs.
public int a;
public int b;
public int c;
public int d;
private String e;
private String f;
private String g;
}
Hay que recordar que el código también se escribe para que lo entiendan los humanos.
A mi en lo particular me causa cierta desazón, cuando se emplean estilos de otros lenguajes en Java, por ejemplo muchas veces veo esto de gente que usa C# o en cierta metida C++
{
private int _privada;
public void MetodoUno()
{
if( condicion )
{
this.Otro()
}
else
{
//
}
}
}
Pero definitivamente prefiero ver como veo la mayoría de las clases Java:
private int privada;
public void metodoUno() {
if( condicion ) {
this.otro();
} else {
//
}
}
}
Lo importante es ponerse de acuerdo.
Estándares
De lo que dices primero Oscar, yo no estaría de acuerdo si estuviera en ese equipo y protestaría de que las clases deben empezar con mayúscula y los métodos y variables con minúscula ( todas las variables con MAYUSCULA como pusiste en tu ejemplo). Esto porque así es el estándar en Java y aunque todo el código que se escriba para el proyecto se haga de la manera contraria, va a causar confusión, porque las clases básicas de Java siguen el estándar, y si se usa cualquier biblioteca o framework externo, va a seguir el estándar también.
Si te sale el líder de proyecto con que precisamente por eso hay que hacerlo alrevés, para distinguir el código del proyecto del código externo, lo agarras a sapes y le explicas para qué sirven los paquetes en Java.
Pero si de 10 integrantes tu
Pero si de 10 integrantes tu eres el único que protesta, o dejas el equipo o te aguantas.
Además te ahi te podrían decir que los paquetes van a ir todos como titulo ( para distinguirlos ) ;)
jejeje
Es decir, yo estoy de acuerdo y prefiero la convención de Sun a cualquier otra ( tanto que su reforzamiento forma parte del diseño de Ryz - lo cual traerá otras discusiones, pero eso es otra onda ) Pero por eso son "convenciones" y de codificación y no "reglas" de codificación. Aunque por otro lado eso explica porque existen los psicopatas violentos que le dan mantenimiento al código
Psicópata violento.
Me apunto en los psicópatas violentos. Y para resolver el caso en el que de 10 integrantes sea yo el único que quiera usar las convenciones de Sun, la solcuión es simple e iterativa: golpear a los demás hasta que sigan los estándares.
que les parece mi solución
for(int i=-50 ; i<=numeroSapes; i++){
integrante.sendSape();
}
}
Me apunto!!
Wishmaster, a mi en lo personal me cae de variedad la forma que propones para ordenar el código, pero nunca lo he visto en un desarrollo en forma,
Con respecto a lo que dice Oscar, hay cada cab... que cree que puede imponer cosas locas, sólo por hacerlas "distintas", casualmente, acabo de entrar a un proyecto, donde el "estándar" de aquí, es escribir los métodos como funciones en C, así como el ejemplo de Oscar....por otro lado , también concuerdo con ezamudio en que, hay que hacer entrar en razón a los del equipo, a fin de cuentas, los frameworks en general, trabajan con estándares, y con esa dependencia, no podemos pasarnos por el arco del triunfo lo que los mismos estándares marcan..
Yo también me apunto en la masacre de sapes, Shadonwk, podrías cambiar la firma de tu método, añadiendo un parámetro que acepte un objeto de tipo Instrumento ??? ésto por si no te quieres lastimar las manos jejejeje...
Ventajas de seguir las convenciones...
Considero que seguir las convenciones no solo es necesario si no sano. En mi opinión no seguirlas es como escribir/decir "sip, nop, pus, conste... etc" (conste que yo soy de los primeros en escribir/decir ese tipo de cosas jejeje), y pues si el IDE hace la chamba canija demos le chance de trabajar a gusto. Varios frameworks, lenguajes, etc. como por ejemplo Spring usan esas convenciones para hacernos la vida más fácil, como los geters/seter. Perooooo, también hay cosas muy locas que no siguen esas convenciones y me parecen muy chida jejeje como dice un comentario de @OscarRyz http://www.javamexico.org/foros/java_standard_edition/proyecto_ayudaofus....
Pero esta padre que surjan post de este tipo, tengo algo que leer llegando de trabajar por ejemplo jejeje suerte :)
Re: wishmaster77
No, de lejos me lo tomé personal, pero no me gusta que se cause discusión por cosas TAN absurdas cómo por una sugerencia =) y caemos en los flamewars (qué este estuvo a punto de serlo) y es lo que menos quiero provocar con las entradas que publico. Lo hago por eso, lo malo es que cómo dijo alguien una vez en los post: "Este es un medio tan impersonal, que en ocasiones parece que escribes cómo ofendido o cómo ofendiendo, siendo que no es tal tu afán".
Re: Sobre los convenciones de código.
En el primer bloque no va el código TRUENA jajaja solución propuesta:
{
private int _privada;
public void MetodoUno()
{
if( condicion )
{
this.Otro()
}
else
{
//
} //esta te faltó
}
}
¬¬
En realidad era solo un ejemplo ¬¬
De cualquier forma ya está corregido.
Claro aqui lo importante es
Claro aqui lo importante es el intercambio de opiniones (no tiene nada de malo que algunas se contrapunteen, al contrario es enriquecedor), el fin no es atacar, hay que tomar en cuenta que un estandard es solo un acuerdo de como deben de ser las cosas, y cada equipo, grupo, comunidad, etc puede hacer sus propios estandares.
Es solo que si es cierto algunos somos un poco cerrados, y queremos ver el mundillo de ciertos colores, pero tambien tiene que ver que por algo las cosas se estandarizan, es cierto cualquiera que se haga llamar programador debe de entender un programa asi este todo en una sola linea, pero digo cuesta mas trabajo de una forma que de otra, ¿ Porque ? pues tal vez es porque estoy mas acostumbrado a verlo de cierta forma...
Re: ¬¬
Duh!, era sólo un cotorreo XD
Flamewar??
Las discusiones son buenas, aportan diferentes puntos de vista. Yo creo que esto está lejos de un flamewar, tal vez son puntos de vista, pero a mi incluso se me hizo amena y divertida con aquellos de los sapes, jeje.