Este es el documento que cree por el cual nos regimos para seguir estandares de trabajo en la empresa, lo pueden tomar como ejemplo para crear una metodología de trabajo limpa y organizada. Lo llame:
LA LEY DEL OESTE!
Este documento fue creado con la finalidad de mantener el standar de forma
de trabajo que se ha venido trabajando y formando en el paso del tiempo.
TODOS deben leer y entender estas reglas para empezar o continuar a trabajar
con algún proyecto.
REGLAS VISUALES Y DE DISEÑO:
----------------------------------------------------------------------------
· NO UTILIZAR EN LO POSIBLE EL MODO DE DISEÑO DEL DREAMWEAVER!!!
Esto daña la indentación que se hayan hecho en los archivos y escribe
codigo incontroladamente.
· La indentación es su mejor amiga:
Se deben indentar las lineas de código perfectamente! esto con la
finalidad de comprender el codigo de una forma mas rápida y para que
sea claro para todos
Aqui acostumbramos a trabajar asi -> ANEXOS(Buena Identación)
· Nombramiento de clases de CSS
Debe nombrar las clases de CSS refiriendose al contenido que halla en
este elemento, no las debe nombrar por sus caracteristicas visuales.
Ejemplo:
NO -> .tituloRojo{} (Nombra el color)
NO -> .barraDerecha{} (Nombra la posición en que sera colocada)
NO -> .CabeceraAmarilla{} (Nombra el color y la posición)
SI -> .listaProductos{}
SI -> .MenuPrincipal{}
SI -> .elementoMenu{}
SI -> .comentario{}
SI -> .error{}
· Documentar todo lo que se cree y se modifique
Reglas de documentación en ANEXOS (Documentación)
· Regirse SIEMPRE! por los estandares de W3C para XHTML
Utilizar siempre código que cumpla con los estandares establecidos por
W3C (http://validator.w3.org/)
Ver Resumen -> ANEXOS (XHTML)
· Tratar de usar tablas lo menos posible
Solo utilizar tablas para escritura de datos
· Asegurarse de que sea multibrowser:
Debe asegurarse de que se vea bien en los siguientes browsers por lo
menos:
-> Mozilla Firefox
-> IE6
-> IE7
-> Opera
· Utilizar 'hacks' de CSS con sintaxis válida en lo posible:
Para una lista de 'hacks' para diferentes browsers puede ir aquí
· Código "leible" por google y otros buscadores
Leer esta guia:
http://www.google.com/support/webmasters/bin/answer.py?answer=35769
· Skip the %3Ctable%3E tag for page layout.
Use it only to display tabular information like spreadsheets, schedules,
and charts. You can do all your layout with CSS for much less time and
code than the table tag tango.
· Don't abuse the %3Cbr /%3E tag.
If you grew up using the
tag %3Cbr /%3E (%3Cbr%3E in HTML) to insert a line break
without creating a new paragraph, then you're in for a treat.
(Browsers automaticallyand sometimes infuriatingly insert a bit of space
between paragraphs, including between headers and <p> tags. In the past,
designers used elaborate workarounds to avoid paragraph spacing they
didn't want, like replacing a single </p><p> tag with a bunch of line breaks
and using a <span> tag to make the first line of the paragraph look like
a headline.) Using CSS's margin controls you can easily set the amount of
space you want to see between paragraphs, headers and other block-level
elements.
----------------------------------------------------------------------------
REGLAS DE PROGRAMACIÓN:
----------------------------------------------------------------------------
· No utilizar directamente variables de POST/GET:
Validar correctamente los datos antes de utilizarlos, y con mas razon
si se utilizan para hacer querys a la BD. ¿Por que?
Ver ANEXOS (Validación de Datos)
· Validar preferiblemente de los dos lados (cliente/servidor):
SIEMPRE! validar del lado del Servidor y preferiblemente validar del
lado del cliente también
· No crear funciones especificas que realicen solo un trabajo especifico!
· Separar en lo posible las 3 capas (Diseño, Contenido y Procesos)
Diseño -> CSS y XHTML
Procesos con DB -> Stored Procedures ,Vistas y Triggers
Procesos con PHP -> Progrmación Orientada a Objetos, funciones genericas
Contenido multiidioma -> Almacenado en BD o en archivos separados
· Optimizar los procesos al máximo!
No repetir procesos, todo lo que se pueda automatizar, automatizelo!.
Si son procesos repetitivos buscar la forma de hacer todo en un proceso
y que este se repita las veces necesarias.
· Respaldar antes de modificar
Siempre antes de empezar a trabajar algun archivo debe respaldarlo
siguiendo las politicas de Respaldo -> ANEXOS (Respaldos)
· La seguridad es primero:
Se debe tener en cuenta que se estan trabajando en servidores de
producción y hay que hacer lo posible por no dejar ningun hueco de
seguridad. Debe pensar siempre si lo que esta haciendo es seguro.
Principalmente si esta trabajando con archivos en el servidor o con
bases de datos.
· Nombrar correctamente los elementos:
Debe nombrar correctamente las variables con nombres descriptivos de lo
que se va a almacenar en esta. Igualmente para las funciones debe
llamarlas con un nombre descriptivo que defina claramente lo que esta
realiza.
----------------------------------------------------------------------------
ANEXOS:
· Buena indentación:
-> Para condicionales IF:
//Comentarios del if
if(condicion){
//codigo si condicion es true;
//linea 2 del codigo;
} else {
//codigo si condicion es falso;
//linea 2 del codigo;
}
-> Para switch case:
//Comentarios del Switch
siwtch(variable){
case 'opcion1':
//Codigo a ejecutar 1
//Linea 2
break;
default:
//Codigo a ejecutar por defecto
//Linea 2
break;
}
-> Para tablas html
<table>
<tr>
<td>
Contenido de la primera columna
</td>
<td>
Contenido de la segunda columna
</td>
</tr>
</table>
/////////////////////////////////////////////////////////////////////////////
·XHTML
Es obligatorio seguir los estandares de XHTML, esto demuestra la calidad
de la empresa y es el lenguaje correcto en que se debe "hablar"
Nota:
-------------------------------------------------------------------------
SI esta usando Firefox, puede descargar la extension llamada
HTML Validator (https://addons.mozilla.org/es-ES/firefox/addon/249 ), este
te dira al correr tus páginas si cumple con los estandares o no, y cuales
son los errores que tienes.
-------------------------------------------------------------------------
Para escribir XHTML válido, solo debe seguir las siguientes reglas:
-> Cierra todos los elementos que abras:
Ejemplo:
<a>Link</a>
<img src="" alt="'Descripcion'" /> (Note el '/>' al final)
(Note el '/>' al final)
-> Cierra los elementos en el orden correcto con que fueron abiertos:
Ejemplo:
<strong> Este <em>texto esta en Negrita</em></strong>
//Por decirlo de una manera el tag 'strong' contiene al 'em'
//Primero cierra el em y luego el strong
-> Los elementos y atributos deben estar en minuscula:
//Inválido: <strong id="'prueba'"></strong>
//Valido: <strong id="'prueba'"></strong>
-> Todo atributo abierto debe tener un valor:
-> No utilizar elementos html deprecados:
Existen elementos que aunque algunos exploradores los reconocen, son
elementos que ya no son estandares y no se utilizan mas, generalmente
hay un remplazo para estos.
/////////////////////////////////////////////////////////////////////////////
·Validación de entradas del usuario:
Siempre que tenga alguna página que interactue con el usuario, las
entradas siempre deben ser validadas dependiendo del caso.
¿Por qué debo validar las entradas?
Por varios motivos, los mas importantes:
-> Seguridad:
Si se esta recibiendo algún dato de un usuario para crear un
query contra la base de datos, un usuario malintencionado podría
crear una cadena especial que le permita tener información e
incluso hasta modificar datos de la BD, esto es llamado inyección
SQL.
Para saber mas acerca de Inyecciones SQL vea ANEXO (Inyecciones
SQL)
-> Saber que los datos recibidos estan bien formateados:
Esto en caso de pedir Emails, números de teléfonos o datos que
tengan un formato específico. Generalmente utilizamos la función
ereg() en PHP.
-> Evitar Errores en pantalla:
Debemos validar si el dato con que vamos a trabajar existe y
tiene el formato correcto para poder trabajarlo para evitar que
se muestre un error (WARNING, NOTICE o FATAL ERROR).
Puede utilizar la funcion isset() para la mayoría de los casos
·Inyecciones SQL:
/////////////////////////////////////////////////////////////////////////////
· Respaldos:
Se mantendran 3 archivos de respaldo llamados de la siguiente maneras
(Ejemplo):
-> archivo_actual.php (Archivo que se usa en producción)
-> archivo_actual.old.php (Último archivo que funcionaba bien)
-> archivo_actual.old2.php (Una versión anterior al old)
Nunca NUNCA quitar la terminación del archivo. (Ejemplo)
NO -> archivo_actual.php.old
SI -> archivo_actual.old.php
Si alguien intenta abrir el arhivo archivo_actual.php.old este podra ver
el codigo fuente del archivo y puede mostrar datos que no quisieramos
que se muestre.
/////////////////////////////////////////////////////////////////////////////
· Documentación:
/////////////////////////////////////////////////////////////////////////////
· Complementos de Firefox:
Para una lista de los elementos preferidos dirijase a:
http://jorgepedret.blogspot.com/2007/04/extensiones-de-firefox-add-ons.html
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||*/
Esto daña la indentación que se hayan hecho en los archivos y escribe
codigo incontroladamente.
· La indentación es su mejor amiga:
Se deben indentar las lineas de código perfectamente! esto con la
finalidad de comprender el codigo de una forma mas rápida y para que
sea claro para todos
Aqui acostumbramos a trabajar asi -> ANEXOS(Buena Identación)
· Nombramiento de clases de CSS
Debe nombrar las clases de CSS refiriendose al contenido que halla en
este elemento, no las debe nombrar por sus caracteristicas visuales.
Ejemplo:
NO -> .tituloRojo{} (Nombra el color)
NO -> .barraDerecha{} (Nombra la posición en que sera colocada)
NO -> .CabeceraAmarilla{} (Nombra el color y la posición)
SI -> .listaProductos{}
SI -> .MenuPrincipal{}
SI -> .elementoMenu{}
SI -> .comentario{}
SI -> .error{}
· Documentar todo lo que se cree y se modifique
Reglas de documentación en ANEXOS (Documentación)
· Regirse SIEMPRE! por los estandares de W3C para XHTML
Utilizar siempre código que cumpla con los estandares establecidos por
W3C (http://validator.w3.org/)
Ver Resumen -> ANEXOS (XHTML)
· Tratar de usar tablas lo menos posible
Solo utilizar tablas para escritura de datos
· Asegurarse de que sea multibrowser:
Debe asegurarse de que se vea bien en los siguientes browsers por lo
menos:
-> Mozilla Firefox
-> IE6
-> IE7
-> Opera
· Utilizar 'hacks' de CSS con sintaxis válida en lo posible:
Para una lista de 'hacks' para diferentes browsers puede ir aquí
· Código "leible" por google y otros buscadores
Leer esta guia:
http://www.google.com/support
· Skip the %3Ctable%3E tag for page layout.
Use it only to display tabular information like spreadsheets, schedules,
and charts. You can do all your layout with CSS for much less time and
code than the table tag tango.
· Don't abuse the %3Cbr /%3E tag.
If you grew up using the
tag %3Cbr /%3E (%3Cbr%3E in HTML) to insert a line break
without creating a new paragraph, then you're in for a treat.
(Browsers automaticallyand sometimes infuriatingly insert a bit of space
between paragraphs, including between headers and <p> tags. In the past,
designers used elaborate workarounds to avoid paragraph spacing they
didn't want, like replacing a single </p><p> tag with a bunch of line breaks
and using a <span> tag to make the first line of the paragraph look like
a headline.) Using CSS's margin controls you can easily set the amount of
space you want to see between paragraphs, headers and other block-level
elements.
------------------------------
REGLAS DE PROGRAMACIÓN:
------------------------------
· No utilizar directamente variables de POST/GET:
Validar correctamente los datos antes de utilizarlos, y con mas razon
si se utilizan para hacer querys a la BD. ¿Por que?
Ver ANEXOS (Validación de Datos)
· Validar preferiblemente de los dos lados (cliente/servidor):
SIEMPRE! validar del lado del Servidor y preferiblemente validar del
lado del cliente también
· No crear funciones especificas que realicen solo un trabajo especifico!
· Separar en lo posible las 3 capas (Diseño, Contenido y Procesos)
Diseño -> CSS y XHTML
Procesos con DB -> Stored Procedures ,Vistas y Triggers
Procesos con PHP -> Progrmación Orientada a Objetos, funciones genericas
Contenido multiidioma -> Almacenado en BD o en archivos separados
· Optimizar los procesos al máximo!
No repetir procesos, todo lo que se pueda automatizar, automatizelo!.
Si son procesos repetitivos buscar la forma de hacer todo en un proceso
y que este se repita las veces necesarias.
· Respaldar antes de modificar
Siempre antes de empezar a trabajar algun archivo debe respaldarlo
siguiendo las politicas de Respaldo -> ANEXOS (Respaldos)
· La seguridad es primero:
Se debe tener en cuenta que se estan trabajando en servidores de
producción y hay que hacer lo posible por no dejar ningun hueco de
seguridad. Debe pensar siempre si lo que esta haciendo es seguro.
Principalmente si esta trabajando con archivos en el servidor o con
bases de datos.
· Nombrar correctamente los elementos:
Debe nombrar correctamente las variables con nombres descriptivos de lo
que se va a almacenar en esta. Igualmente para las funciones debe
llamarlas con un nombre descriptivo que defina claramente lo que esta
realiza.
------------------------------
ANEXOS:
· Buena indentación:
-> Para condicionales IF:
//Comentarios del if
if(condicion){
//codigo si condicion es true;
//linea 2 del codigo;
} else {
//codigo si condicion es falso;
//linea 2 del codigo;
}
-> Para switch case:
//Comentarios del Switch
siwtch(variable){
case 'opcion1':
//Codigo a ejecutar 1
//Linea 2
break;
default:
//Codigo a ejecutar por defecto
//Linea 2
break;
}
-> Para tablas html
<table>
<tr>
<td>
Contenido de la primera columna
</td>
<td>
Contenido de la segunda columna
</td>
</tr>
</table>
//////////////////////////////
·XHTML
Es obligatorio seguir los estandares de XHTML, esto demuestra la calidad
de la empresa y es el lenguaje correcto en que se debe "hablar"
Nota:
------------------------------
SI esta usando Firefox, puede descargar la extension llamada
HTML Validator (https://addons.mozilla.org/es
te dira al correr tus páginas si cumple con los estandares o no, y cuales
son los errores que tienes.
------------------------------
Para escribir XHTML válido, solo debe seguir las siguientes reglas:
-> Cierra todos los elementos que abras:
Ejemplo:
<a>Link</a>
<img src="" alt="'Descripcion'" /> (Note el '/>' al final)
(Note el '/>' al final)
-> Cierra los elementos en el orden correcto con que fueron abiertos:
Ejemplo:
<strong> Este <em>texto esta en Negrita</em></strong>
//Por decirlo de una manera el tag 'strong' contiene al 'em'
//Primero cierra el em y luego el strong
-> Los elementos y atributos deben estar en minuscula:
//Inválido: <strong id="'prueba'"></strong>
//Valido: <strong id="'prueba'"></strong>
-> Todo atributo abierto debe tener un valor:
-> No utilizar elementos html deprecados:
Existen elementos que aunque algunos exploradores los reconocen, son
elementos que ya no son estandares y no se utilizan mas, generalmente
hay un remplazo para estos.
//////////////////////////////
·Validación de entradas del usuario:
Siempre que tenga alguna página que interactue con el usuario, las
entradas siempre deben ser validadas dependiendo del caso.
¿Por qué debo validar las entradas?
Por varios motivos, los mas importantes:
-> Seguridad:
Si se esta recibiendo algún dato de un usuario para crear un
query contra la base de datos, un usuario malintencionado podría
crear una cadena especial que le permita tener información e
incluso hasta modificar datos de la BD, esto es llamado inyección
SQL.
Para saber mas acerca de Inyecciones SQL vea ANEXO (Inyecciones
SQL)
-> Saber que los datos recibidos estan bien formateados:
Esto en caso de pedir Emails, números de teléfonos o datos que
tengan un formato específico. Generalmente utilizamos la función
ereg() en PHP.
-> Evitar Errores en pantalla:
Debemos validar si el dato con que vamos a trabajar existe y
tiene el formato correcto para poder trabajarlo para evitar que
se muestre un error (WARNING, NOTICE o FATAL ERROR).
Puede utilizar la funcion isset() para la mayoría de los casos
·Inyecciones SQL:
//////////////////////////////
· Respaldos:
Se mantendran 3 archivos de respaldo llamados de la siguiente maneras
(Ejemplo):
-> archivo_actual.php (Archivo que se usa en producción)
-> archivo_actual.old.php (Último archivo que funcionaba bien)
-> archivo_actual.old2.php (Una versión anterior al old)
Nunca NUNCA quitar la terminación del archivo. (Ejemplo)
NO -> archivo_actual.php.old
SI -> archivo_actual.old.php
Si alguien intenta abrir el arhivo archivo_actual.php.old este podra ver
el codigo fuente del archivo y puede mostrar datos que no quisieramos
que se muestre.
//////////////////////////////
· Documentación:
//////////////////////////////
· Complementos de Firefox:
Para una lista de los elementos preferidos dirijase a:
http://jorgepedret.blogspot
||||||||||||||||||||||||||||||
