13.01.2015 Views

Pensar en C++ (Volumen 1) - Grupo ARCO

Pensar en C++ (Volumen 1) - Grupo ARCO

Pensar en C++ (Volumen 1) - Grupo ARCO

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

✐<br />

✐<br />

✐<br />

“Volum<strong>en</strong>1” — 2012/1/12 — 13:52 — page 526 — #564<br />

✐<br />

Apéndice A. Estilo de codificación<br />

int func(int a);<br />

Se sabe, por el punto y coma al final de la línea, que esto es una declaración y no<br />

hay nada más, pero al leer la línea:<br />

int func(int a) {<br />

inmediatam<strong>en</strong>te se sabe que se trata de una definición porque la línea termina con<br />

una llave de apertura, y no un punto y coma. Usando este <strong>en</strong>foque, no hay difer<strong>en</strong>cia<br />

a la hora de colocar el paréntesis de apertura <strong>en</strong> una definición de múltiples líneas.<br />

int func(int a) {<br />

int b = a + 1;<br />

return b * 2;<br />

}<br />

y para una definición de una sola línea que a m<strong>en</strong>udo se usa para inlines:<br />

int func(int a) { return (a + 1) * 2; }<br />

Igualm<strong>en</strong>te, para una clase:<br />

class Thing;<br />

es una declaración del nombre de una clase, y<br />

class Thing {<br />

es una definición de clase. En todos los casos, se puede saber mirando una sola<br />

línea si se trata de una declaración o una definición. Y por supuesto, escribir la llave<br />

de apertura <strong>en</strong> la misma línea, <strong>en</strong> lugar de una línea propia, permite ahorrar espacio<br />

<strong>en</strong> la página.<br />

Así que ¿por qué t<strong>en</strong>emos tantos otros estilos En concreto, verá que mucha g<strong>en</strong>te<br />

crea clases sigui<strong>en</strong>te el estilo anterior (que Stroustrup usa <strong>en</strong> todas las ediciones de<br />

su libro The <strong>C++</strong> Programming Language de Addison-Wesley) pero crean definiciones<br />

de funciones poni<strong>en</strong>do la llave de apertura <strong>en</strong> una línea aparte (lo que da lugar a<br />

muchos estilos de ind<strong>en</strong>tación difer<strong>en</strong>tes). Stroustrup lo hace excepto para funciones<br />

inline cortas. Con el <strong>en</strong>foque que yo describo aquí, todo es consist<strong>en</strong>te - se nombra lo<br />

que sea (class, functión, <strong>en</strong>um, etc) y <strong>en</strong> la misma línea se pone la llave de apertura<br />

para indicar que el cuerpo de esa cosa está debajo. Y también, la llave de apertura<br />

se pone <strong>en</strong> el mismo sitio para funciones inline que para definiciones de funciones<br />

ordinarias.<br />

Creo que el estilo de definición de funciones que utiliza mucha g<strong>en</strong>te vi<strong>en</strong>e de el<br />

antiguo prototipado de funciones de C, <strong>en</strong> el que no se declaraban los argum<strong>en</strong>tos<br />

<strong>en</strong>tre los paréntesis, si no <strong>en</strong>tre el paréntesis de cierre y la llave de apertura (esto<br />

demuestra que las raíces de C son el l<strong>en</strong>guaje <strong>en</strong>samblador):<br />

void bar()<br />

int x;<br />

526<br />

✐<br />

✐<br />

✐<br />

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!