• No results found

Conclusions

In document Predicting Speech Intelligibility (Page 74-80)

La selección de identifi cadores adecuados es un paso que con frecuencia se pasa por alto en el diseño del programa. Cuando usted escribe programas, elige identifi cadores para las variables, las constantes y los módulos. Antes en este capítulo usted aprendió las reglas para nombrar variables y módulos: cada uno debe ser una sola palabra sin espacios y debe comenzar con una letra. Estas sencillas reglas brindan gran libertad de acción para nombrar los elementos del programa, pero no todos los identifi cadores son igual de buenos. La elección de los que sí lo son simplifi ca su labor de programación y facilita que otras personas entiendan su trabajo. Algunos lineamientos generales son los siguientes:

• Aunque no es necesario en todos los lenguajes de programación, por lo general tiene sen- tido dar a una variable o constante un nombre que sea un sustantivo (o una combinación de un adjetivo y un sustantivo) debido a que representa una cosa. Del mismo modo, tiene sen- tido dar a un módulo un identifi cador que sea un verbo, o un verbo y un sustantivo combi- nados, debido a que un módulo emprende una acción.

• Use nombres signifi cativos. Crear un elemento de datos que se ha nombrado someData o un módulo llamado firstModule() hace que un programa sea confuso. No sólo otras personas encontrarán dif ícil la lectura de los programas que usted haya escrito, sino que además usted podría olvidar el propósito de haber incluido estos identifi cadores. Todos los programadores usan nombres breves no descriptivos como x o temp en un programa rápido; sin embargo, en la mayoría de los casos, los nombres de los datos y el módulo deben ser significativos. Los programadores se refieren a los programas que contienen nombres significativos como autodocumentados. Esto significa que, aun sin información adicional, el código se explica por sí solo a los lectores.

• Use nombres pronunciables. Un nombre de variable como pzf no es pronunciable ni significativo; uno que parezca significativo cuando usted lo escribe podría no serlo cuando alguien más lo lea; por ejemplo, preparead() quizá signifique “Prepare ad" (Preparar anuncio) para usted, pero “Prep a read" (Preparar una lectura) para otras personas. Observe sus nombres en forma crítica para asegurarse de que es posible pronunciarlos. Las abreviaturas estándar no tienen que ser pronunciables. Por ejemplo, la mayoría de las personas de negocios interpretarían isr como impuesto sobre la renta.

• No olvide que no todos los programadores comparten su cultura. Una abreviatura cuyo significado parezca obvio para usted podría ser confusa para alguna persona en una parte distinta del mundo, o incluso de su país. Por ejemplo, usted podría nombrar roi a una variable a fin de que contenga un valor para el rendimiento sobre la inversión, pero alguien que hable francés interpretaría el significado como rey.

• Sea juicioso cuando use abreviaturas. Usted puede ahorrar algunos golpes de tecla cuando cree un módulo llamado getStat() pero, ¿el propósito del módulo es encontrar el estado en el que se localiza una ciudad, introducir algunas estadísticas o determinar el estado de algunas variables? Del mismo modo, ¿una variable que se ha nombrado fn pretende contener un primer nombre, un número de archivo o algo más? Las abreviaturas también 66

pueden confundir a las personas que se encuentran en diferentes líneas de trabajo: AKA podría sugerir una hermandad femenina (Alpha Kappa Alpha) para un administrador universitario, un registro (American Kennel Association) para un criador de perros o un alias (also known as [también conocido como]) para un detective de policía.

Para ahorrar tiempo en la mecanografía cuando desarrolle un programa, usted puede usar un nombre breve como efn. Una vez que el programa opera correctamente, puede usar las herramientas Buscar y Reemplazar de un editor de textos para cambiar su nombre codificado por otro más significativo como employeeFirstName.

Muchos IDE soportan una característica para completar declaraciones en forma automática que ahorra tiempo de mecanografía. Después de la primera vez que usted usa un nombre como

employeeFirstName, sólo necesita teclear las primeras letras antes de que el editor del compilador le muestre una lista de nombres disponibles entre los que puede elegir. La lista se conforma con todos los nombres que ha usado y que empiecen con los mismos caracteres.

En general, evite los dígitos. Los ceros se confunden con la letra O, y la letra l minúscu- la con el número 1. Por supuesto, use su juicio: budgetFor2014 probablemente no se malinterpretará.

• Use el sistema que su lenguaje permita para separar las palabras en los nombres de variables largos que contengan muchas. Por ejemplo, si el lenguaje de programación que utiliza acep- ta guiones o subrayados, entonces use un nombre de módulo como initialize-data() o initialize_data(), lo cual es más fácil de leer que initializedata(). Otra opción es usar la notación de camello para crear un identifi cador como initializeData(). Si utiliza un lenguaje que es sensible a las mayúsculas y minúscu-las, es legal pero confuso usar nom- bres de variables que sólo difi eran en las mayúsculas y minúsculas. Por ejemplo, si un solo programa contiene empName, EmpName y Empname, de seguro habrá confusión.

Considere incluir una forma del verbo to be, como is o are, en los nombres para las varia- bles que se espera que contengan un estado. Por ejemplo, use isFinished como una variable de cadena que contiene una Y o N para indicar si un archivo está agotado. Hay más probabilidades de que el nombre más breve, finished, se confunda con un módulo que se ejecuta cuando acaba un programa. (Muchos lenguajes soportan un tipo de datos booleano, que se asigna a las variables que se espera que contengan sólo verdadero o falso. Es apro- piado usar una forma de to be en los identifi cadores para las variables booleanas.)

• Muchos programadores siguen la convención de nombrar constantes usando sólo letras mayúsculas, insertando subrayados entre palabras para mejor legibilidad. En este capítulo vio ejemplos como SALES_TAX_RATE.

• Las organizaciones a veces imponen diferentes reglas para que los programadores las sigan cuando nombran los componentes del programa. Es su responsabilidad averiguar las con- venciones que se utilizan en su organización y apegarse a ellas.

Los programadores en ocasiones crean un diccionario de datos, que es una lista de todos los nombres de variables que se han usado en un programa, junto con su tipo, tamaño y descripción. Cuando se crea este diccionario se vuelve parte de la documentación del programa.

Cuando usted comience a escribir programas, quizá la determinación de cuáles variables de datos, constantes y módulos necesita y cómo nombrarlos le parezca abrumador. Sin embargo, el proceso de diseño es crucial. Cuando reciba su primera asignación de programación pro- fesional, el diseño bien podría haberse completado ya. Lo más probable es que su primera

d d

67 Características de un buen diseño de programa

asignación será escribir o modifi car un pequeño módulo que forma parte de una aplicación mucho más grande. Entre más se apeguen los programadores originales a los lineamientos para nombrar, será mejor el diseño original y más fácil su labor de modifi cación.

In document Predicting Speech Intelligibility (Page 74-80)

Related documents