Barrapunto

Todo esto está muy bien, ya que cuando trabajas en grandes grupos de programación debes asegurarte que todo el código sea lo más homogeneo posible, en muchas ocasiones se tiene que modificar código que ha escrito otra persona y cosas así facilitan esa tarea.

El problema que yo veo a estas reglas es que atienen a un criterio arbitrario, en la mayoría de ocasiones cambiarán los criterios de una empresa a otra. Algunos están bien ya que permiten al programador cierta libertad de elección (lógica de la aplicación) otras "reglas" obligan a crear monstruosos códigos inmantenibles (me ha pasado en varias ocasiones al tener que ceñirme a reglas de "calidad de código", tan sólo por que en ciertos casos no se puede utilizar una consulta sql o tener que repetir código ya que se usa más de un bucle y eso no está permitido). El caso es que si se diseñan unas buenas reglas de "calidad de código", no sólo se puede programar una buena aplicación, si no que ayudará al mantenimiento de la aplicación que se ha desarrollado facilitando la tarea a los que curran, los programadores.

La única manera de conseguir que este tipo de políticas se cumplan es configurar el repositorio (cvs, svn, PVCS, ClearCase o lo que sea) para que no permita hacer check-in de ficheros que no cumplan las reglas.

Para un buen desarrollo del proyecto: pocas normas, que estén muy claras y que se validen de manera automática. En caso contrario las normas de estilo acaban siendo ignoradas, incluso en los proyectos en los que hay una etapa de revisión de código antes de integrar a la rama principal.

Seguramente muchos ya siguen alguna guia muy parecida a estas. Yo personalmente uso una más o menos igual. Por ejemplo prefiero usar mayusculas para separar los nombres, en vez del guión bajo "_". O los operadores unitarios muchas veces agradezco que esten no esten en una línea solamente. Por cierto, la traducción de ese ejemplo esta mal.

Ahhh, y hay un leve fallo tanto en Poner espacios entre signos, como en Precedencia de operadores y en No uses variables sin inicializar por coherencia debería estar aplicada la regla de Números dentro del código.

La guia de CSS debería dar algo más de libertad. ¿Porque el header y no el footer? (¿se escribe así?).

El mensaje de esa separación me parece buenisimo pero hay que hacerle mucho caso al diseño para definir que elementos ponemos en un fichero aparte tal y como hace el ejemplo con el header.

Por lo demás unas guias muy correctas y sencillas que seguro quitan más de un dolor de cabeza trabajando en equipo.

Enhorabuena.

En ambas guías se recomienda utilizar tabuladores en lugar de espacios y no puedo estar más en contra de tal política. Tab es DAÑINO.

En un entorno de desarrollo grande se utilizarán diferentes herramientas para trabajar con el mismo código. Algunos desarrolladores utilizaran Eclipse, otros Visual Studio, otros Ultraedit/TextPad y algún friqui habrá que escriba el código en vim o notepad. Además, el código hay que verlo con alguna(s) herramienta(s) de comparación de versiones donde también habrá variedad. Algunos utilizarán el comparador integrado con el repositorio mientras que otros usarán UltraCompare o vaya usted a saber qué.

Si hay mezcla de espacios y tabs el resultado será horrible. El código que se ve bien indentado en una herramienta no se verá bien en ninguna de las demás. Pero si se utilizan sólo tabuladores el resultado tampoco es óptimo, ya que algunos tendránm configurado el tabulador a dos espacios, otros a cuatro y otros a ocho. En cuanto un fichero haya sido editado con tres o cuatro herramientas diferentes ya no habrá manera de seguirlo porque, lo abras con lo que lo abras, la indentación estará mal.

Sin embargo, si fuerzas a que todo el mundo use espacios poniendo una regla en el repositorio que impida subir ficheros que contengan [tab], el código se verá correctamente indentado en todo tiempo, en todo lugar y con toda herramienta.

Este tipo de documentos estan muy bien, pero es practicamente imposible cumplirlos siempre, ya sea por olvido o por rapidez al codificar.

Sin embargo, si utilizas un indentador automatico de codigo, te libras de estos problemas de un plumazo. Como indent para C. Cada cual programa como mas le gusta, y antes de a~adir su codigo al proyecto lo pasa por el indentador automatico, con lo que se consigue que no este pensando en cosas como si debe poner o no una llave en una nueva linea o en la misma y se concentre en la programacion.

Hola,

Este programa que comentáis, CheckStyle, ¿es sólo válido para Java o también funciona con otros lenguajes? (por ejemplo, PHP).

Yo estaría interesado en encontrar algo para PHP... :-)

Los que despotrican de la "notación húngara" deberían leerse primero este artículo de Joel Spolsky [joelonsoftware.com]. Para los ansiosos: hay una notación húngara buena (la original) y una notación húngara mala.

Pero, claro, que se puede esperar cuando hasta en la documentación de linux [unsw.edu.au] se le echa la culpa de los bugs de los programas de Microsoft. Quizá tienen razón y el problema de Microsoft es que usa la notación húngara... mala. O quizá Linus tampoco se ha leido el artículo de Joel.

Yo me he encontrado al menos con un software (en PHP) que utiliza notación húngara buena y me ha resultado muy útil. De hecho, ha sido el código que más fácil me ha resultado meterle mano. Ver Mantis Coding Conventions [mantisbt.org].

Creo que las mismas razones que llevan a decir que conviene nombrar una función como crear_usuario() en lugar de simplemente crear(), sirven para recomendar nombrar a una variable global con g_nombre en lugar de simplemente nombre.

Es sencillo, úsalos en una sola línea y a la derecha, ejemplo:

//Esto está MAL
$cosa = $matriz[$i--];
$otra = $matriz[++$y];

//Esto está BIEN
$i--;
$y++;
$cosa = $matriz[$i];
$otra = $matriz[$y];

Que pena que lo que está BIEN no hace lo mismo que lo que está MAL.

¿O es que la regla es justamente para los que no entienden como funcionan los operadores unarios de suma y resta?

Los tabs en lugar de espacios sólo sirven cuando una sola persona lee el código y lo hace siempre con el mismo editor.
Yo mismo, programando con quanta y a veces con vi, me encuentro con que se me desarman las indentaciones por las "diferencias de opinión" entre un editor y otro sobre lo que significa un tab.
Usando espacios uno se asegura de que el fuente se verá en todas partes exactamente como el programador lo escribió. Usando un estilo legible se obtendrá un código legible independientemente de los seteos del editor pero únicamente si no se usan tabs.

Estemmm... si dicen que hay que usar tabs en lugar de espacios para que cada uno formatee como le guste, por qué será que dicen también esto:
General Formatting * Use TABS with a size of 4

Debe ser que se han dado cuenta de que al mostrarse diferente en cada editor, los tabs hacen dificil la lectura. En lugar de pedir que se usen tabs de tamaño 4 deberían simplemente prohibir el uso de tab, así usarían una regla en lugar de dos.

Hay cosas con las que no estoy deacuerdo, pero dejando a un lado lo de los Tabs, que ya se ha comentado, en ese articulo hay algunos errores.

Entre otras cosas, espero que nadie programe las constantes en PHP así:

$ARTICULOS_PORTADA = 10;

Escribirlo en mayusculas no convierte a una variable en contante, mejor sería definirla como constante define ('ARTICULOS_PORTADA' , 10); [php.net]

El resto de errores se encuentran con el clasico prueba y error ;-P

Creo que es equivocado no utilizar constantes en PHP con la función define(). Primero porque es mucho más claro definir un:

define( MICONSTANTE, valor );

que un

$MICONSTANTE = valor;

porque se puede prestar a malas intepretaciones, sobre todo cuando dichas constantes aparecen en ciclos:

for ( $i = 0; $i MICONSTANTE; $i++ )

aquí se ve claramente que la constante MICONSTANTE es eso, y que no se redefine en ningún lado por error, por lo que se evitan muchos errores de lógica que luego son difíciles de rastrear.

Ya que estamos en el tema...¿Hay alguna forma de hacer indentacion automatica con kate/quanta/kwrite para PHP de la forma que lo hace vim, o ultraedit (windows)?
Quizás un alma caritativa que haya hecho un archivo de sangrado basado en variables para esto...

bien formateado, pero mal colocado.

je

ojú!

Ostia! Es verdad.

Fijate, que estamos hablando de guias de codificación, y la seguridad no tiene nada que ver. Que cosas.

Si al final va a ser verdad que la culpa de los fallos de seguridad la tiene cualqueira menos los desarrolladores xD.

Estoy de acuerdo en que:

if ($cosa)
{
                funcion();
}

es pasarse con las ganas de claridad. Pero sólo si sabes positiva y totalmente que en ese if nunca habrá más líneas. Y como eso es prácticamente imposible, salvo en casos triviales, el usar esa disposición permite añadir código sin modificar la regla de claridad.