Share
Dos veces al mes, volvemos a visitar algunas de las publicaciones favoritas de nuestros lectores de toda la historia de Nettuts.+.
La legibilidad del código es un tema universal en el mundo de la programación informática. Es una de las primeras cosas que aprendemos como desarrolladores. Este artículo detallará las quince mejores prácticas más importantes al escribir código legible.
Los entornos de desarrollo integrados (IDE) han recorrido un largo camino en los últimos años. Esto hizo que comentar tu código sea más útil que nunca. Seguir ciertos estándares en sus comentarios permite que IDE y otras herramientas los utilicen de diferentes maneras.
Considera este ejemplo:
Los comentarios que agregué en la definición de la función se pueden previsualizar cuando uso esa función, incluso desde otros archivos.
Aquí hay otro ejemplo en el que invoco una función de una biblioteca de terceros:
En estos ejemplos particulares, el tipo de comentario (o documentación) utilizado se basa en PHPDoc, y el IDE es Aptana.
Supongo que ya sabes que debes sangrar tu código. Sin embargo, también vale la pena señalar que es una buena idea mantener un estilo de sangría coherente..
Hay más de una forma de sangrar código.
función foo () si ($ quizás) do_it_now (); otra vez(); else abort_mission (); finalizar ();
función foo () si ($ quizás) do_it_now (); otra vez(); else abort_mission (); finalizar ();
función foo () si ($ quizás) do_it_now (); otra vez(); else abort_mission (); finalizar ();
Solía codificar en estilo # 2, pero recientemente cambié a # 1. Pero eso es solo una cuestión de preferencia. No hay un estilo "mejor" que todos deberían seguir. En realidad, el mejor estilo, es un estilo consistente. Si eres parte de un equipo o si estás contribuyendo código a un proyecto, debes seguir el estilo existente que se está utilizando en ese proyecto..
Los estilos de sangrado no siempre son completamente distintos entre sí. A veces, mezclan diferentes reglas. Por ejemplo, en los estándares de codificación PEAR, el corchete de apertura "" va en la misma línea que las estructuras de control, pero va a la siguiente línea después de las definiciones de funciones.
Estilo de la pera:
la función foo () // se coloca en la siguiente línea si ($ quizás) // se coloca en la misma línea do_it_now (); otra vez(); else abort_mission (); finalizar ();
También tenga en cuenta que están utilizando cuatro espacios en lugar de pestañas para sangrías.
Aquí hay un artículo de Wikipedia con ejemplos de diferentes estilos de sangría..
Comentar tu código es fantástico; sin embargo, puede ser exagerado o simplemente ser redundante. Tomemos este ejemplo:
// obtener el código de país $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); // si el código del país es EE. UU. si ($ código_del_campo == 'EE. UU.) // muestra la entrada del formulario para el estado echo form_input_state ();
Cuando el texto es tan obvio, no es productivo repetirlo en los comentarios..
Si debe comentar sobre ese código, simplemente puede combinarlo en una sola línea:
// mostrar la selección de estado para los usuarios de EE. UU. $ código_grupo = obtener_código_país ($ _ SERVIDOR ['REMOTE_ADDR']); if ($ country_code == 'US') echo form_input_state ();
La mayoría de las veces, ciertas tareas requieren algunas líneas de código. Es una buena idea mantener estas tareas dentro de bloques de código separados, con algunos espacios entre ellos..
Aquí hay un ejemplo simplificado:
Accentsconagua
// obtener la lista de foros $ forums = array (); $ r = mysql_query ("SELECCIONAR ID, nombre, descripción DE los foros"); while ($ d = mysql_fetch_assoc ($ r)) $ forums [] = $ d; // cargar las plantillas load_template ('header'); load_template ('forum_list', $ forums); load_template ('footer'); Agregar un comentario al comienzo de cada bloque de código también enfatiza la separación visual.
PHP a veces es culpable de no seguir esquemas de nombres consistentes:
En primer lugar, los nombres deben tener límites de palabras. Hay dos opciones populares:
Tener diferentes opciones crea una situación similar a los estilos de sangría, como mencioné anteriormente. Si un proyecto existente sigue una convención determinada, debe ir con eso. Además, algunas plataformas de lenguaje tienden a usar un determinado esquema de denominación. Por ejemplo, en Java, la mayoría de los códigos utiliza los nombres de camelCase, mientras que en PHP, la mayoría de los que usan subrayados.
Estos también se pueden mezclar. Algunos desarrolladores prefieren usar guiones bajos para funciones de procedimiento y nombres de clase, pero usan camelCase para nombres de método de clase:
class Foo_Bar public function someDummyMethod () function procedural_function_name ()
Así que de nuevo, no hay un "mejor" estilo obvio. Solo siendo consistente.
DRY significa no repetirte. También conocido como DIE: la duplicación es el mal.
El principio establece:
"Cada pieza de conocimiento debe tener una representación autoritaria única e inequívoca dentro de un sistema".
El propósito de la mayoría de las aplicaciones (o computadoras en general) es automatizar las tareas repetitivas. Este principio debe mantenerse en todo el código, incluso en las aplicaciones web. El mismo código no debe repetirse una y otra vez..
Por ejemplo, la mayoría de las aplicaciones web constan de muchas páginas. Es muy probable que estas páginas contengan elementos comunes. Los encabezados y pies de página suelen ser los mejores candidatos para esto. No es una buena idea seguir copiando estos encabezados y pies de página en cada página. Aquí está Jeffrey Way, que explica cómo crear plantillas en CodeIgniter..
$ this-> load-> view ('includes / header'); $ this-> load-> view ($ main_content); $ this-> load-> view ('includes / footer'); Demasiados niveles de anidación pueden hacer que el código sea más difícil de leer y seguir.
function do_stuff () //? if (is_writable ($ folder)) if ($ fp = fopen ($ file_path, 'w')) if ($ stuff = get_some_stuff ()) if (fwrite ($ fp, $ stuff)) //? else devolver falso; else return false; else return false; else return false;
Por motivos de legibilidad, generalmente es posible realizar cambios en su código para reducir el nivel de anidamiento:
function do_stuff () //? if (! is_writable ($ folder)) return false; if (! $ fp = fopen ($ file_path, 'w')) return false; if (! $ stuff = get_some_stuff ()) return false; if (fwrite ($ fp, $ stuff)) //? else devolver falso;
Nuestros ojos son más cómodos al leer columnas de texto altas y estrechas. Esta es precisamente la razón por la que los artículos periodísticos se ven así:
Es una buena práctica evitar escribir líneas de código largas y horizontales..
// mal $ mi_mail-> set_from ('[email protected] ') -> add_to (' [email protected] ') -> set_subject (' Methods Chained ') -> set_body (' Some long message ') -> enviar(); // good $ my_email -> set_from ('[email protected] ') -> add_to (' [email protected] ') -> set_subject (' Methods Chained ') -> set_body (' Some long message ') -> enviar(); // bad $ query = "SELECT id, username, first_name, last_name, status FROM users IEFT JOIN user_posts USING (users.id, user_posts.user_id) DONDE post_id = '123'"; // good $ query = "SELECT id, username, first_name, last_name, status FROM users IEFT JOIN user_posts USING (users.id, user_posts.user_id) DONDE post_id = '123'"; Además, si alguien tiene la intención de leer el código desde una ventana de terminal, como los usuarios de Vim, es una buena idea limitar la longitud de la línea a alrededor de 80 caracteres..
Técnicamente, podría escribir un código de aplicación completo dentro de un solo archivo. Pero eso resultaría ser una pesadilla para leer y mantener.
Durante mis primeros proyectos de programación, conocía la idea de crear "incluir archivos". Sin embargo, aún no estaba ni remotamente organizado. Creé una carpeta "inc", con dos archivos en ella: db.php y funciones.php. A medida que las aplicaciones crecieron, el archivo de funciones también se volvió enorme e inigualable..
Uno de los mejores enfoques es utilizar un marco o imitar su estructura de carpetas. Aquí es cómo se ve CodeIgniter:
Normalmente, las variables deben ser descriptivas y contener una o más palabras. Pero, esto no necesariamente se aplica a las variables temporales. Pueden ser tan cortos como un solo personaje..
Es una buena práctica usar nombres consistentes para sus variables temporales que tienen el mismo tipo de rol. Aquí hay algunos ejemplos que tiendo a usar en mi código:
// $ i para contadores de bucle para ($ i = 0; $ i < 100; $i++) // $j for the nested loop counters for ($j = 0; $j < 100; $j++) // $ret for return variables function foo() $ret['bar'] = get_bar(); $ret['stuff'] = get_stuff(); return $ret; // $k and $v in foreach foreach ($some_array as $k => $ v) // $ q, $ r y $ d para mysql $ q = "SELECT * FROM tabla"; $ r = mysql_query ($ q); while ($ d = mysql_fetch_assocr ($ r)) // $ fp para los punteros a archivos $ fp = fopen ('file.txt', 'w'); La interacción de la base de datos es una parte importante de la mayoría de las aplicaciones web. Si está escribiendo consultas SQL sin procesar, es una buena idea mantenerlas legibles también..
Aunque las palabras especiales de SQL y los nombres de funciones no distinguen entre mayúsculas y minúsculas, es una práctica común usar mayúsculas para distinguirlas de sus nombres de tabla y columna.
ID SELECCIONAR, nombre de usuario DE usuario; ACTUALIZAR usuario SET last_login = NOW () WHERE id = '123' SELECT id, username DESDE user u LEFT JOIN user_address ua ON (u.id = ua.user_id) WHERE ua.state = 'NY' GROUP BY u.id ORDER BY u.nombre de usuario LIMIT 0,20
Este es otro principio que se aplica a casi todos los lenguajes de programación en todos los entornos. En el caso del desarrollo web, los "datos" generalmente implican resultados HTML..
Cuando PHP se lanzó por primera vez hace muchos años, fue visto principalmente como un motor de plantillas. Era común tener grandes archivos HTML con algunas líneas de código PHP en el medio. Sin embargo, las cosas han cambiado con los años y los sitios web se volvieron cada vez más dinámicos y funcionales. El código ahora es una gran parte de las aplicaciones web, y ya no es una buena práctica combinarlo con el código HTML..
Puede aplicar el principio a su aplicación usted mismo o puede usar una herramienta de terceros (motores de plantillas, marcos o CMS) y seguir sus convenciones..
Marcos de PHP populares:
Motores de plantillas populares:
Sistemas de gestión de contenidos populares
Puede elegir no usar un motor de plantillas sofisticado y, en cambio, ir con PHP en línea en sus archivos de plantillas. Esto no necesariamente viola la "Separación de código y datos", siempre que el código en línea esté directamente relacionado con la salida y sea legible. En este caso, debe considerar el uso de la sintaxis alternativa para las estructuras de control.
Aquí hay un ejemplo:
Hola, nombre de usuario; ?>
|Mi tablero de mensajes
título; ?>
Foros como $ foro):?>id, $ forum-> title)?> (Hilos-> cuenta (); ?> hilos)
descripción; ?>
Esto te permite evitar muchos frenillos. Además, el código se ve y se siente similar a la forma en que el HTML está estructurado y sangrado..
La programación orientada a objetos puede ayudarte a crear código bien estructurado. Pero eso no significa que deba abandonar completamente la programación de procedimientos. Realmente crear una mezcla de ambos estilos puede ser bueno..
Los objetos se deben utilizar para representar datos, que generalmente residen en una base de datos.
usuario de la clase nombre de usuario $ público; public $ first_name; public $ last_name; correo electrónico público $; función pública __construir () //? public function create () //? función pública guardar () //? función pública delete () //?
Las funciones de procedimiento se pueden utilizar para tareas específicas que se pueden realizar de forma independiente.
función mayúscula ($ string) $ ret = strtoupper ($ string [0]); $ ret. = strtolower (substr ($ string, 1)); devuelve $ ret;
Los proyectos de código abierto se construyen con la entrada de muchos desarrolladores. Estos proyectos deben mantener un alto nivel de legibilidad del código para que el equipo pueda trabajar en conjunto lo más eficientemente posible. Por lo tanto, es una buena idea navegar a través del código fuente de estos proyectos para observar lo que están haciendo estos desarrolladores.
Cuando "refactoriza", realiza cambios en el código sin cambiar ninguna de sus funciones. Puede pensarlo como una "limpieza", con el fin de mejorar la legibilidad y la calidad.
Esto no incluye correcciones de errores o la adición de cualquier nueva funcionalidad. Puede refactorizar el código que ha escrito el día anterior, mientras aún está fresco en su mente, de modo que sea más legible y reutilizable cuando pueda verlo potencialmente dentro de dos meses. Como dice el lema: "refactorice temprano, refactorice a menudo".
Puede aplicar cualquiera de las "mejores prácticas" de legibilidad del código durante el proceso de refactorización..
Espero que hayan disfrutado este artículo! ¿Alguna que me haya perdido? Déjame saber a través de los comentarios. Y si desea mejorar su codificación, hay muchos scripts y aplicaciones disponibles para ayudarle en Envato Market. Vea lo que es más popular esta semana.
