Como bien te dice Nicneretu, lo que se busca es el código autodocumentado.
Hay muchas convenciones de código, x ej, en el caso de Java, el código autodocumentado está a tope... Por ahí cuesta mucho verlo en código de hace unos años o de gente que se acostumbró a abreviarlo todo. Y siempre noto que medio mundo se resiste esgrimiendo las excusas de "por qué un nombre de función tan largo" o "hay que teclear mucho más" o "tantos llamados a función generan una sobrecarga de llamados y bla bla bla"... Para algo los IDEs o RADs ayudan mucho con esto (CTRL+ Espacio en eclipse y otros IDEs autocompletan nombres de función o variables como TAB en bash), y los compiladores cada día están más optimizados.
El que se acostumbró al código chapucero, lamentablemente es muy dificil sacarle las malas mañas; y siempre es el primero en chillar ante este tipo de prácticas.
--
El doc
"Nada de cerveza mientras no acabes tu tequila!" --Padre de Leela, Futurama.
Re:Mi experiencia con extreme programming
(Puntos:2)( http://www.psicofxp.com/ )
Hay muchas convenciones de código, x ej, en el caso de Java, el código autodocumentado está a tope... Por ahí cuesta mucho verlo en código de hace unos años o de gente que se acostumbró a abreviarlo todo. Y siempre noto que medio mundo se resiste esgrimiendo las excusas de "por qué un nombre de función tan largo" o "hay que teclear mucho más" o "tantos llamados a función generan una sobrecarga de llamados y bla bla bla"... Para algo los IDEs o RADs ayudan mucho con esto (CTRL+ Espacio en eclipse y otros IDEs autocompletan nombres de función o variables como TAB en bash), y los compiladores cada día están más optimizados.
El que se acostumbró al código chapucero, lamentablemente es muy dificil sacarle las malas mañas; y siempre es el primero en chillar ante este tipo de prácticas.
El doc
"Nada de cerveza mientras no acabes tu tequila!" --Padre de Leela, Futurama.