Programacin estructurada Es este paradigma de programacin el que se podra llamar original, procedimental, o tambin conocido como Divide y vencers.

Se trata de dividir el problema a resolver en tareas a realizar, y estas tareas en una serie de procedimientos, para finalmente encontrar el algoritmo que mejor se encuadre en ellos. Fortran (creado en 1954, por Jhon Backus) es el lenguaje original de programacin procedimental, aunque hoy en da la mayora de los lenguajes de programacin la permiten. El lenguaje Pascal (de principios de los 70, creado por Niklaus Wirth), es muy conocido debido al refuerzo que haca de este tipo de programacin. En este tipo de programacin, el programador debe concentrarse en que cada procedimiento tenga una interfaz consistente, describiendo los argumentos de entrada y los de salida, y que cada procedimiento sea independiente del resto. Procedimientos y funciones Un algoritmo que resolviera un problema complejo, contendra cientos o miles de lneas de cdigo en su interior. Esto es inabarcable para cualquier programador, por lo que se utiliza el concepto de procedimientos y funciones para subdividir el problema en partes. La idea es que cada una de estas partes contenga un conjunto de instrucciones que permita la ejecucin de algn proceso determinado y lgico desde el punto de vista humano. Dos ejemplos, funcin y procedimiento respectivamente:

La descomposicin del software en tareas tambin se conoce con el nombre de top-down y fue presentada por primera vez por Niklaus Wirth. Este autor proporciona la siguiente visin de refinamiento: En cada paso (del refinamiento), una o varias instrucciones del programa dado, se descomponen en instrucciones ms detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones termina cuando todas las instrucciones estn expresadas en trminos de la computadora usada o del lenguaje de programacin.

Conforme se refinan las tareas, tambin los datos pueden ser refinados, descompuestos o estructurados siendo natural refinar las especificaciones del programa y los datos en paralelo Cada paso de refinamiento implica algunas decisiones de diseo. Es importante que el programador sea consciente de los criterios subyacentes (en las decisiones de diseo adoptadas) y de la existencia de soluciones alternativas Tpicamente, una descomposicin insuficiente de un problema en tareas conduce a la definicin de pocos procedimientos, cada uno de las cuales implementar mltiples funcionalidades. Programacin modular Con los aos, en el diseo de programas se dio mayor nfasis al diseo de procedimientos que a la organizacin de la informacin. Entre otras cosas esto refleja un aumento en el tamao de los programas. La programacin modular surge como un remedio a esta situacin. A menudo se aplica el trmino mdulo a un conjunto de procedimientos afines junto con los datos que manipulan. As, el paradigma de la programacin modular consiste en: a) Establecer los mdulos que se requieren para la resolucin de un problema. b) Dividir el programa de modo que los procedimientos y los datos queden ocultos en mdulos. Este paradigma tambin se conoce como principio de ocultacin de procedimientos y datos. Aunque C++ no se dise especficamente para desarrollar la programacin modular, su concepto de clase proporciona apoyo para el concepto de mdulo. Programacin orientada a objetos (OOP) El problema con la abstraccin de datos es que no hay ninguna distincin entre las propiedades generales y las particulares de un conjunto de objetos. Expresar esta distincin y aprovecharla es lo que define a la OOP a travs del concepto de herencia. El paradigma de la programacin orientada a objetos es, entonces, a) Definir que clases se desean b) Proporcionar un conjunto completo de operaciones para cada clase c) Indicar explcitamente lo que los objetos de la clase tienen en comn empleando el concepto de herencia

En algunas reas las posibilidades de la OOP son enormes. Sin embargo, en otras aplicaciones, como las que usan los tipos aritmticos bsicos y los clculos basados en ellos, se requiere nicamente la abstraccin de datos y/o programacin por procedimientos, por lo que los recursos necesarios para apoyar la OOP podran salir sobrando. Resolucin de problemas y desarrollo de software. La creacin de un programa requiere de tcnicas similares a la realizacin de otros proyectos de ciencia e ingeniera, ya que, en la prctica, un programa no es ms que una solucin desarrollada para resolver un problema concreto. La escritura de un programa es casi la ltima etapa de un proceso en el que se determina primero cul es el problema? y el mtodo que se utilizar para resolver el problema. Cada campo de estudio tiene su propio nombre para denominar el mtodo sistemtico utilizado para resolver problemas mediante el diseo de soluciones adecuadas. En ciencia y en ingeniera el mtodo se conoce como mtodo cientfico mientras que cuando se realiza anlisis cuantitativo se suele conocer como enfoque o mtodo sistemtico. Las tcnicas utilizadas por los desarrolladores profesionales de software para llegar a soluciones adecuadas para la resolucin de problemas se denominan proceso de desarrollo de software. Aunque el nmero y nombre de las fases puede variar segn los modelos, mtodos y tcnicas utilizadas. En general, las fases de desarrollo de software se suelen considerar las siguientes: Anlisis y especificacin del problema. Diseo de una solucin. Implementacin (codificacin). Pruebas, ejecucin, correccin y depuracin. Documentacin. Mantenimiento y evaluacin. Modelos de proceso de desarrollo de software A lo largo de la historia del desarrollo de software desde la dcada de los cincuenta del siglo pasado se han propuesto muchos modelos. Pressman en la ltima edicin de su conocida obra Ingeniera del software, plantea la siguiente divisin: 1. Modelos normativos (prescriptivos). 2. Modelos en cascada. 3. Modelos de proceso incremental Modelo incremental. Modelo DRA (Desarrollo Rpido de Aplicaciones). 4. Modelos de proceso evolutivo. Modelo de prototipado (construccin de prototipos). Modelo en espiral. Modelo de desarrollo concurrente.

5. Modelos especializados de proceso. Modelo basado en componentes. Modelo de mtodos formales. Desarrollo de software orientado a aspectos. 6. El proceso unificado (RUP de Booch, Rumbaugh y Jacobson) 7. Mtodos giles Programacin Extrema (XP, Extreme Programming). Anlisis y especificacin del problema El anlisis de un problema se requiere para asegurarse de que el problema est bien definido y comprendido con claridad. La determinacin de que el problema est definido claramente se hace despus de que la persona entienda cules son las salidas requeridas y qu entradas son necesarias. Para realizar esta tarea, el analista debe tener una comprensin de cmo se pueden utilizar las entradas para producir las salidas deseadas. Despus de un anlisis profundo del problema se debe realizar la especificacin que es una descripcin precisa y lo ms exacta posible del problema; en realidad, es como un contrato previo para solucin. La especificacin del problema no suele ser una tarea fcil sobre todo por la complejidad que entraan la mayora de los problemas del mundo real. La descripcin inicial de un problema no suele ser clara y casi siempre, al principio, suele ser imprecisa y vaga. La formulacin de una especificacin del problema requiere una descripcin precisa y lo ms completa posible de la entrada del problema (informacin disponible para la resolucin del problema) y la salida requerida. Adems, se requiere informacin adicional tal como: hardware y software necesario, tiempo de respuesta, plazos de entrada, facilidad de uso, robustez del software, etc. La persona que realiza el anlisis debe tener una perspectiva inicial lo ms amplia posible y comprender el propsito principal de los que el problema o sistema pretende conseguir. En sistemas grandes el anlisis, lo realiza normalmente un analista de sistemas, y en programas individuales, el anlisis se realiza directamente por el programador. Con independencia de cmo y por quin se realice el anlisis, a la conclusin del mismo se debe tener una comprensin muy clara de: Qu debe hacer el sistema o el programa? Qu salidas debe producir? Qu entradas se requieren para obtener las salidas deseadas? Diseo La fase de diseo de la solucin se inicia una vez que se tiene la especificacin del problema y consiste en la formulacin de los pasos o etapas para resolver el problema. Dos metodologas son las ms utilizadas en el diseo: diseo descendente o estructurado que se apoya en programacin estructurada y diseo orientado a objetos que se basa en la programacin orientada a objetos. El diseo de una solucin requiere el uso de algoritmos. Un algoritmo es un conjunto de instrucciones o pasos para resolver un problema Los algoritmos deben procesar los datos necesarios para la resolucin del problema. Los datos se organizan en almacenes o

estructuras de datos. Los programas se compondrn de algoritmos que manipulan o procesan las estructuras de datos. Una buena tcnica para el diseo de un algoritmo, como se ha comentado (diseo descendente), es descomponer el problema en subproblemas o subtareas ms pequeas y sencillas, a continuacin descomponer cada subproblema o subtarea en otra ms pequea y as sucesivamente, hasta llegar a subtareas que sean fciles de implantar en C++ o en cualquier otro lenguaje de programacin. Los algoritmos se suelen escribir en pseudocdigo o en otras herramientas de programacin como diagramas de flujo o diagramas N-S. Hoy da la herramienta ms utilizada es el pseudocdigo o lenguaje algortmico, consistentete en un conjunto de palabras en espaol, ingls, etctera que representan tareas a realizar y una sintaxis de uso como cualquier otro lenguaje. Tcnica de diseo descendente. 1) Descomponer una tarea en subtareas; a continuacin cada subtarea en tareas ms pequeas. 2) Disear el algoritmo que describe cada tarea. Otra tcnica o mtodo de diseo muy utilizado en la actualidad es el diseo orientado a objetos. El diseo descendente se basa en la descomposicin de un problema en un conjunto de tareas y en la realizacin de los algoritmos que resuelven esas tareas, mientras que el diseo orientado a objetos se centra en la localizacin de mdulos y objetos del mundo real. Estos objetos del mundo real estn formados por datos y operaciones que actan sobre los datos y modelan, a su vez, a los objetos del mundo real, e interactan entre s para resolver el problema concreto. El diseo orientado a objetos ha conducido a la programacin orientada a objetos, como uno de los mtodos de programacin ms populares y ms utilizados en el pasado siglo XX y actual XXI. Consideraciones prcticas de diseo Una vez que se ha realizado un anlisis y una especificacin del problema se puede desarrollar una solucin. El programador se encuentra en una situacin similar a la de un arquitecto que debe dibujar los planos de una casa; la casa deber cumplir ciertas especiaciones y cumplir las necesidades de su propietario, pero puede ser diseada y construida de muchas formas posibles. La misma situacin se presenta al programador y al programa a construir. En programas pequeos, el algoritmo seleccionado suele ser muy simple y consta de unos pocos clculos que deben realizarse. Sin embargo, lo ms normal es que la solucin inicial debe ser refinada y organizada en subsistemas ms pequeos, con especificaciones de cmo interactuar entre s y los interfaces correspondientes. Para conseguir este objetivo, la descripcin de la solucin comienza desde el requisito de nivel ms alto y prosigue en modo descendente hacia las partes que deben construir para conseguir este requisito. Una vez que se ha desarrollado una estructura inicial se refinan las tareas hasta que stas se encuentren totalmente definidas. El proceso de refinamiento de una solucin contina hasta que los requisitos ms pequeos se incluyan dentro de la solucin. Cuando el diseo se ha terminado, el problema se resuelve mediante un programa o un sistema de mdulos (funciones, clases...), bibliotecas de funciones o de clases, plantillas, patrones, etc.

Implementacin (codificacin) La codificacin o implementacin implica la traduccin de la solucin de diseo elegida en un programa de computadora escrito en un lenguaje de programacin tal como C++ o Java. Si el anlisis y las especificaciones han sido realizados con correccin y los algoritmos son eficientes, la etapa de codificacin normalmente es un proceso mecnico y casi automtico de buen uso de las reglas de sintaxis del lenguaje elegido. El cdigo fuente, sea cual sea el lenguaje de programacin en el cual se haya escrito, debe ser legible, comprensible y correcto (fiable). Es preciso seguir buenas prcticas de programacin. Los buenos hbitos en la escritura de programas facilitan la ejecucin y prueba de los mismos. Tenga presente que los programas, subprogramas (funciones) y bibliotecas escritos por estudiantes suelen tener pocas lneas de programa (decenas, centenas...); sin embargo, los programas que resuelven problemas del mundo real contienen centenares, y millares e incluso millones de lneas del cdigo fuente y son escritos por equipos de programadores. Estos programas se usan, normalmente, durante mucho tiempo y requieren un mantenimiento que en muchos casos se realiza por programadores distintos a los que escribieron el programa original. Por estas razones, es muy importante escribir programas que se puedan leer y comprender con facilidad as como seguir hbitos y reglas de lecturas que conduzcan a programas correctos (fiables). Pruebas y depuracin La prueba y correccin de un programa pretende verificar que dicho programa funciona correctamente y cumple realmente todos sus requisitos. En teora las pruebas revelan todos los errores existentes en el programa. En la prctica, esta etapa requiere la comprobacin de todas las combinaciones posibles de ejecucin de las sentencias de un programa; sin embargo, las pruebas requieren, en muchas ocasiones, mucho tiempo y esfuerzo, que se traduce a veces en objetivo imposible excepto en programas que son muy sencillos. Los errores pueden ocurrir en cualquiera de las fases del desarrollo de software. As, puede suceder que las especificaciones no contemplen de modo preciso la informacin de entrada, o los requisitos dados por el cliente; tambin puede suceder que los algoritmos no estn bien diseados y contengan errores lgicos o por el contrario que los mdulos o unidades de programa no estn bien codificados o la integracin de las mismas en el programa principal no se haya realizado correctamente. La deteccin y correccin de errores es una parte importante del desarrollo de software, dado que dichos errores pueden aparecer en cualquier fase del pro ceso. Debido a que las pruebas exhaustivas no suelen ser factibles ni viables en la mayora de los programas se necesitan diferentes mtodos y filosofas de prueba. Una de las responsabilidades de la ciencia de ingeniera de software es la construccin sistemtica de un conjunto de pruebas (test) de entradas que permitan descubrir errores. Si las pruebas revelan un error (bug), el proceso de depuracin deteccin, localizacin, correccin y verificacin se puede iniciar. Es importante advertir que aunque las pruebas puedan detectar la presencia de un error, no necesariamente implica la ausencia de errores. Por consiguiente, el hecho de que una prueba o test, revele la existencia de un error no significa que uno indefinible pueda existir en otra parte del programa.

Para atrapar y corregir errores de un programa, es importante desarrollar un conjunto de datos de prueba que se puedan utilizar para determinar si el programa proporciona respuestas correctas. De hecho, una etapa aceptada en el desarrollo formal de software es planificar los procedimientos de pruebas y crear pruebas significativas antes de escribir el cdigo. Los procedimientos de prueba de un programa deben examinar cada situacin posible bajo la cual se ejecutar el programa. El programa debe ser comprobado con datos en un rango razonable as como en los lmites y en las reas en las que el programa indique al usuario que los datos no son vlidos. El desarrollo de buenos procedimientos y datos de prueba en problemas complejos pueden ser ms difciles que la escritura del propio cdigo del programa. Verificacin y validacin La prueba del software es un elemento de un tema ms amplio que suele denominarse verificacin y validacin. Verificacin es el conjunto de actividades que aseguran que el software funciona correctamente con una amplia variedad de datos. Validacin es el conjunto diferente de actividades que aseguran que el software construido se corresponde con los requisitos del cliente. En la prctica, la verificacin pretende comprobar que los documentos del programa, los mdulos y restantes unidades son correctos, completos y consistentes entre s y con los de las fases precedentes; la validacin, a su vez, se ocupa de comprobar que estos productos se ajustan a la especificacin del problema. Boehm estableci que la verificacin era la respuesta a: Estamos construyendo el producto correctamente? mientras que la validacin era la respuesta a: Estamos construyendo el programa correcto?. En la prueba de software convencional en posible aplicar diferentes clases de pruebas. Pressman distingue las siguientes: Prueba de unidad: se centra el esfuerzo de verificacin en la unidad ms pequea del diseo de software, el componente o mdulo (funcin o subprograma) de software que se comprueban individualmente. Prueba de integracin: se comprueba si las distintas unidades del programa se han unido correctamente. Aqu es muy importante descubrir errores asociados con la interfaz. En el caso de software orientado a objetos cambia el concepto de unidad que pasa a ser la clase o la instancia de una clase (objeto) que empaqueta los atributos (datos) y las operaciones (funciones) que manipulan estos datos. La prueba de la clase en el software orientado a objetos es la equivalente a la prueba de unidad para el software convencional. La prueba de integracin se realiza sobre clases que colaboran entre s. Otro tipo de pruebas importantes son las pruebas del sistema. Una prueba del sistema comprueba que el sistema global del programa funciona correctamente; es decir las funciones, las clases, las bibliotecas, etc. Las pruebas del sistema abarcan una serie de pruebas diferentes cuyo propsito principal es verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. Estas pruebas se corresponden con las distintas etapas del desarrollo del software.

Eleccin de datos de prueba Para que los datos de prueba sean buenos, necesitan cumplir dos propiedades: 1. Se necesita conocer cul es la salida que debe producir un programa correcto para cada entrada de prueba. 2. Las entradas de prueba deben incluir aquellas entradas que ms probabilidad tengan de producir errores. Aunque un programa se compile, se ejecute y produzca una salida que parezca correcta no significa que el programa sea correcto. Si la respuesta correcta es 211492 y el programa obtiene 211491, algo est equivocado. A veces, el mtodo ms evidente para encontrar el valor de salida correcto es utilizar lpiz y papel utilizando un mtodo distinto al empleado en el programa. Puede ayudarle utilizar valores de entrada ms pequeos o simplemente valores de entrada cuya salida sea conocida. Existen diferentes mtodos para encontrar datos de prueba que tengan probabilidad de producir errores. Uno de los ms utilizados se denomina valores de frontera. Un valor frontera de un problema es una entrada que produce un tipo de comportamiento diferente, por ejemplo, la funcin C++ int comprobar_hora (int hora) //la hora de da est en el rango 0 a 23, tiene dos valores frontera 0 //(referir a 0, no es vlido) y 23 (superior a 23 no es vlida, ya que 24 //es un nuevo da); de igual modo si se deja contemplar el hecho de //maana (AM) o tarde (PM), los valores frontera sern 0 y 11, 12 y 23, // respectivamente. En general, no existen definiciones de valores frontera y es en las especificaciones del problema donde se pueden obtener dichos valores. Una buena regla suele ser la siguiente: Si no puede comprobar todas las entradas posible, al menos compruebe los valores frontera. Por ejemplo, si el rango de entrada va de 0 a 500.000, asegure la prueba de 0 y 500.000, y ser buena prctica probar 0, 1 y 1 siempre que sean valores vlidos. Depuracin La depuracin es el proceso de fijacin o localizacin de errores. La deteccin de una entrada de prueba que produce un error es slo parte del problema de prueba y depuracin. Despus que se encuentra una entrada de prueba errnea se debe determinar exactamente por qu ocurre el error y, a continuacin, depurar el programa. Una vez que se ha corregido un error debe volver a ejecutar el programa. En programas sencillos la depuracin se puede realizar con mayor o menor dificultad, pero en programas grandes el seguimiento (traza o rastreo) de errores es casi imposible sin ayuda de una herramienta de software denominada depurador (debugger). Un depurador ejecuta el cdigo del programa lnea a lnea, o puede ejecutar el cdigo harta que se produzca una cierta condicin. El uso de un depurador puede especificar cules son las condiciones que originan la ejecucin anmala de un programa. Los errores ms frecuentes de un programa son: Errores de sintaxis: faltas gramaticales de la sintaxis del lenguaje de programacin. Errores en tiempo de ejecucin: se producen durante la ejecucin del programa.

Errores lgicos: normalmente errores de diseo del algoritmo. Ejemplos Errores de sintaxis double presupuesto //error, falta l; cin presupuesto; //error, falta >> Error de ejecucin Clculo de divisin por cero, obtener races de nmeros negativos, valores fuera de rango. Error lgico Mal planteamiento en el diseo de un algoritmo. Documentacin El desarrollo de software requiere un gran esfuerzo de documentacin de las diferentes etapas. En la prctica, muchos de los documentos clave (crticos) se crean durante las fases de anlisis, diseo, codificacin y prueba. La documentacin completa del software presenta todos los documentos en un manual que sea til a los programadores y a su organizacin. Aunque el nmero de documentos puede variar de un proyecto a otro, y de una organizacin a otra, esencialmente existen cinco documentos imprescindibles en la documentacin final de un pro grama: 1. Descripcin del problema (especificaciones). 2. Cambio y desarrollo de los algoritmos. 3. Listados de programas, bien comentados. 4. Ejecucin de las pruebas de muestra. 5. Manual del usuario. La documentacin del software comienza en la fase de anlisis y especificacin del problema y contina en la fase de mantenimiento y evolucin. Mantenimiento Una vez que el software se ha depurado completamente y el conjunto de programas, biblioteca de funciones y clases, etc., se han terminado y funcionan correctamente, el uso de los mismos se puede extender en el tiempo durante grandes perodos (normalmente meses o aos). La fase de mantenimiento del software est relacionada con correccin futura de problemas, revisin de especificaciones, adicin de nuevas caractersticas, etc. El mantenimiento requiere, normalmente, un esfuerzo importante ya que si bien el desarrollo de un programa puede durar das, meses o aos, el mantenimiento se puede extender a aos e incluso dcadas. Un ejemplo tpico estudiado en numerosos cursos de ingeniera de software fue el esfuerzo realizado para asegurar que los programas existentes funcionan correctamente al terminar el siglo XX conocido como el efecto del ao 2000. Estadsticamente est demostrado que los sistemas de software, especialmente los desarrollados para resolver problemas complejos presentan errores que no fueron detectados en las diferentes pruebas y que se detectan cuando el software se pone en funcionamiento de modo comercial o profesional. La reparacin de estos errores es una etapa importante y muy costosa del mantenimiento de un programa. Adems de estas tareas de mantenimiento existen muchas otras tareas dentro de esta etapa:

mejoras en la eficiencia, aadir nuevas caractersticas (por ejemplo, nuevas funcionalidades), cambios en el hardware, en el sistema operativo, ampliar nmero mximo de usuarios.... Otros cambios pueden venir derivados de cambios en normativas legales, en la organizacin de la empresa, en la difusin del producto a otros pases, etc. Estudios de ingeniera de software demuestran que el porcentaje del presupuesto de un proyecto software y del tiempo de programador/analista/ingeniero de software ha ido creciendo por dcadas. As, en la dcada de los setenta, se estimaba el porcentaje de mantenimiento entre un 35-40 por 100, en la dcada de los ochenta, del 40 al 60 por 100, y se estima que en la dcada actual del siglo XXI, puede llegar en aplicaciones para la web, videojuegos, software de inteligencia de negocios, de gestin de relaciones con los clientes (CRM), etc., hasta un 80 o un 90 por 100 del presupuesto total del desarrollo de un producto software. Por todo lo anterior, es muy importante que los programadores diseen programas legibles, bien documentados y bien estructurados, bibliotecas de funciones y de clases con buena documentacin, de modo que los programas sean fciles de comprender y modificar y en consecuencia fciles de mantener. Entorno IDE de Turbo C Un IDE es un entorno de programacin que ha sido empaquetado como un programa de aplicacin; es decir, consiste en un editor de cdigo, un compilador, un depurador y un constructor de interfaz grfica (GUI). Los IDEs pueden ser aplicaciones por s solas o pueden ser parte de aplicaciones existentes. El lenguaje Visual Basic, por ejemplo, puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word. Los IDE proveen un marco de trabajo amigable para la mayora de los lenguajes de programacin tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecucin, en donde se permite utilizar el lenguaje de programacin en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.

Directivas de compilacin Las directivas de compilacin son aquellas expresiones que empiezan por # y sirven para indicar en tiempo de compilacin un nmero de operaciones bsicas para tener control de informacin mientras se cumple con la etapa previa a la compilacin llamada preprocesado. El preprocesado es aquella etapa donde el compilador limpia el cdigo de comentarios y remplaza todos aquellos valores existentes en las directivas de compilacin por todo lo necesario para crear cdigo objeto. Las directivas que soporta el ANSI C Son: #define Define constantes o Funciones

#error Para la compilacion por un error #include Incluye un archivo en el codigo #if evalua valor de una variable #define #else evalua valor de una variable #define #elif evalua valor de una variable #define #endif Terminacin de un condicional #if #ifdef Mira si un valor ya fue definido #ifndef Mira si un valor no fue definido #undef Quita una definicin #line Modifica los valores de __LINE__ y __FILE__ #pragma Permite pasar opciones al compilador Comandos Bsicos del Lenguaje C La tabla a continuacin muestra los 32 comandos bsicos, que en conjunto con la sintaxis formal del C, constituyen el estndar C89. Todos los comandos del C son escritos en minsculas. En C, una letra en minscula es diferente de la misma letra en mayscula. El nombre de un comando no puede ser usado para un propsito diferente del originalmente previsto; por ejemplo, no puede ser usado como nombre de funcin o de variable. auto break case char const continue default do Double Else Enum Extern Float For Goto If int long register return short signed sizeof static Struct Switch Typedef Union Unsigned Void Volatile While

Todos los programas en C consisten de una o ms funciones. La nica funcin indispensable es llamada main(), y es la primera funcin invocada cuando se ejecute el programa. En un cdigo C "bien escrito", la funcin main() esboza lo que hace el programa. Este "esbozo" est compuesto de invocaciones a funciones. Aun main() no es un comando, debe ser tratado como si lo fuera.