PDF de programación - hd magazine 04 201302

AÑO ----------- 0
NÚMERO -------- 4
FECHA: 2013-02-25

#4

“Narciso”

HD Hackers &
+

DEVELOPERS

Magazine digital de distribución
mensual sobre Software Libre, Hacking y Programación
para profesionales del sector de Tecnologías de la Información

Staff

Eugenia Bahit
Indira Burga
Laura Mora
María José Montes Díaz
Milagros Infante Montero

Arquitecta GLAP & Agile Coach

Ingeniera de Sistemas

Administradora de Redes y Sistemas

Técnica en Informática de Gestión

Est. Ingeniería de Sistemas

Hackers & Developers Magazine se distribuye bajo una licencia Creative Commons Atribución
NoComercial CompartirIgual 3.0 Unported . Eres libre de copiar, distribuir y compartir este material.
FREE AS IN FREEDOM!

HD

Hackers &
DEVELOPERS
+

#4

Hackers & Developers Magazine, es
una iniciativa sin fines de lucro
destinada al fomento y difusión de
las tecnologías libres presentes o
futuras, bajo una clara óptica
docente y altruista, que resulte de
interés técnico y/o científico a
profesionales
de
sector
Tecnologías de
Información.
Hackers & Developers Magazine se
sostiene económicamente con el
apoyo de
comunidad, no
recibiendo subvención alguna de
ninguna empresa, organización u
organismo
Gobierno.
Necesitamos de tu apoyo para
poder mantener este proyecto.

del
la

de

la

Ayúdanos a continuar
con este proyecto
Puedes
hacer un donativo ahora,
de 10, 15, 25, 50, 100 o 150 USD
para ayudar a que Hackers &
Developers Magazine pueda seguir
publicándose de forma gratuita,
todos los meses. Puedes donar con
PayPal o Tarjeta de Crédito a través
del siguiente enlace:
www.hdmagazine.org/donar

CON TU DONACIÓN DE USD 150
RECIBES DE REGALO,

UNA FUNDA DE

NEOPRENE PARA TU
ORDENADOR PORTÁTIL

VALUADA EN USD 25.-
(Origen: Estados Unidos)

“Hacker es alguien que disfruta
jugando con la inteligencia”

Richard Stallman
Free Software, Free Society
(Pág. 97), GNU Press 2010-2012

En esta edición:
PEP8 de Python.....................................................................................4
Hal 9000 Junior. (Primera Parte)...........................................................9
Pylint al rescate...................................................................................13
Manual de MVC: (3) Controladores......................................................17
Double Test con ZendFramework2 .......................................................23
¿Cómo crear aplicaciones Web PHP con EuropioEngine?.....................27
Manual de Perl (Parte II).....................................................................41
Conociendo a DOM: Parte II.................................................................49
Pásate a GNU/Linux con Arch: Pacman, el gestor de paquetes.............54
Explorando Mosh.................................................................................64
Agilismo en palabras simples...............................................................67
De estudiante a programador..............................................................72

Y LAS SECCIONES DE SIEMPRE:
ASCII Art...................................................................... Pág. 73
Este mes: «The first Daffodil of Spring» by Susie Oviatt
Zona U!........................................................................ Pág. 74
La comunidad de nuestros lectores y lectoras

Créditos

Hackers & Developers Magazine es posible gracias al compromiso de:

Responsable de Proyecto

Eugenia Bahit

Responsables de Comunicación

Indira Burga (Atención al Lector) - Milagros Infante (Difusión)

Staff Permanente

Eugenia Bahit

Arquitecta GLAMP & Agile Coach

www.eugeniabahit.com

Indira Burga

Ingeniera de Sistemas
about.me/indirabm

Milagros Infante Montero

Estudiante de Ingeniería en Sistemas

www.milale.net

Laura Mora

Administradora de Redes y

Sistemas GNU/Linux

blackhold.nusepas.com

María José Montes Díaz

Técnica en Informática de Gestión

archninfa.blogspot.com.es

Colaboradores Estables

Redactores Voluntarios

Elizabeth Ramírez

(Ingeniera Electrónica)

Sergio Infante Montero
(Ingeniero Informático)

Celia Cintas

Eliana Caraballo

Yecely Díaz

(Maestra en Inteligencia Artificial)

Hackers & Developers Magazine agradece a los portales que nos ayudan con la difusión del proyecto:

Difusión

www.debianhackers.net

www.desarrolloweb.com

www.desdelinux.net

E-mail de Contacto:
[email protected]

Hackers & Developers Magazine – Año 0, Número 4 4

PEP8 de Python

N
O
H
T
Y
P

Qué mejor que contar con un documento que liste las
convenciones que tiene el lenguaje que usamos para
desarrollar. PEP8 es la guía de estilo de Python. La
clave para este PEP es una de las ideas de Guido Van
Rossum, que el código se suele leer mucho más de lo
que se escribe.

Escrito por: Milagros Alessandra Infante Montero (Est. Ing. Informática)

Estudiante de Ingeniería Informática. Miembro de APESOL
(Asociación Peruana de Software Libre) y de la comunidad de software
libre Lumenhack. Miembro del equipo de traducción al español de
GNOME. Apasionada por el desarrollo de software, tecnología y
gadgets. Defensora de tecnologías basadas en software libre y de
código abierto.

Webs:
Blog: www.milale.net

Redes sociales:
Twitter / Identi.ca: @milale

L

a PEP (Python Enhancement Proposal) es la propuesta de mejora de Python,
considerada como estándares. Son las guías de estilo que se encuentran en la PEP
número 8, que están dirigidas a mejorar la legibilidad del código y a lograr
consistencia. Esto último es fundamental dentro de un módulo o función, pero también
es muy importante saber cuando ser inconsistente. Por ejemplo, podemos toparnos con
una situación en la que debemos saber diferenciar si al aplicar alguna regla el código
será menos legible.

“Una consistencia estúpida es el duende de las mentes
pequeñas.” - Ralph Waldo Emerson

Es importante recordar que PEP nos dice que> “La legibilidad cuenta”, es importante seguir buenas prácticas de
programación y al final que mejor que lograr un código limpio que cumpla todos los estándares.

Formato del código
Indentación:

Se debe usar 4 espacios por cada nivel de indentación. Cuando se indente código no se
deben mezclar tabuladores o espacios; siempre es recomendable solo hacerlo con
espacios.

Tamaño máximo de línea

Todas las líneas deben contar con un máximo de 79 caracteres y de 72 caracteres a
lineas empleadas para documentación o comentarios. Al dividir líneas largas se suele
continuar la línea de forma implícita dentro de paréntesis, corchetes o llaves, pero
queda mejor el uso de una barra invertida (sobre todo, cuando no exista posibilidad de
agrupamiento): \

def __init__(self, first, second, third,
fourth, fifth, sixth):
output = (first + second + third
+ fourth + fifth + sixth)

Líneas en blanco

Las líneas en blanco separan las funciones no anidadas y definiciones de clases (con dos
líneas) y las definiciones de métodos dentro de una misma clase (con una línea), se
pueden usar líneas en blanco extra; python acepta el carácter control-L (^L).

Codificación de caracteres

Se recomienda el uso de ASCII o Latin-1 (en lugar de este último, usar UTF-8)1

Imports
Los imports deberían colocarse en distintas líneas y siempre en la parte superior del
archivo, antes de las variables globales y las constantes del módulo. Estos deben
agruparse siguiendo este orden: imports de librería estándar, imports de proyectos de
terceras partes relacionados e imports de aplicaciones locales/imports específicos de la
librería.

Espacios en blanco en expresiones y sentencias
Se deben evitar espacios en blanco extra en las siguientes situaciones:

1

http://www.python.org/dev/peps/pep-3120/



©2013 HDMagazine.org – Creative Commons Atribución NoComercial CompartirIgual 3.0 Unported

Pág. 5

• Después de entrar o antes de salir de un paréntesis, corchete o llave.

• Antes de una coma, punto y coma o dos puntos.

• Antes de abrir un paréntesis para una lista de argumentos.

• Antes de abrir un paréntesis usado como índice o para particionar.

• No se debe dar más de un espacio alrededor de un operador de asignación (u

otro operador aritmético) para alinearlo con otro.

Comentarios y documentación
Es bastante primordial que comentemos nuestro código. Imaginen que después de
mucho tiempo vuelves a revisar el código que hiciste pero hay muchas cosas que no
recuerdas. Es importante tener como prioridad que los comentarios se encuentren
actualizados acorde a lo que se vaya desarrollando.

Los comentarios de bloque se identan al mismo nivel que dicho código, cada línea
comienza con un # y un único espacio y para el caso de los comentarios en línea que se
encuentra en la misma línea de la sentencia, los comentarios deberían separarse por al
menos dos espacios de la sentencia que comentan.

Para el caso de las cadenas de documentación, esta es la manera correcta de realizarlo
(notar la línea en blanco antes del """ de cierre):

"""Documentación de ejemplo

Debe realizarse de esta manera para cumplir los estándares del PEP

"""

Convenciones de nombres
Para las convenciones de nombres aún no se tiene algo consistente pero sí se tiene
estándares recomendados.

• Descriptivo:

Estos son los estilos de nombrado. Aquí encontramos a los más comunes: una
letra en minúscula, una letra en mayúscula, minúsculas, mayúsculas, con guiones
bajos, o considerando palabras con CamelCase, pero por ejemplo algo que debe
evitarse es el uso de palabras que inicien con mayúsculas y tenga guiones bajos.

• Prescriptivo:

Existen 3 caracteres que deben evitarse usar como nombre de variable: la ele
minúscula, la o mayú