martes, 19 de febrero de 2019

Mapa Conceptual


mapa Conceptual.


Estilos de programación

1.Estilos de Programación

Es un término que describe convenciones para escribir código fuente en ciertos lenguajes de programación.
El estilo de programación es frecuentemente dependiente del lenguaje de programación que se haya elegido para escribir
2
DIFERENTES TIPOS DE PARADIGMAS DE PROGRAMACIÓN
Un paradigma de programación es una propuesta tecnológica que es adoptada por una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que unívocamente trata de resolver uno o varios problemas claramente delimitados. La resolución de estos problemas debe suponer consecuentemente un avance significativo en al menos un parámetro que afecte a la ingeniería de software. Tiene una estrecha relación con la formalización de determinados lenguajes en su momento de definición. Un paradigma de programación está delimitado en el tiempo en cuanto a aceptación y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente.
TIPOS DE PARADIGMAS DE PROGRAMACIÓN

Programación Imperativa

La programación imperativa, en contraposición a la programación declarativa es un paradigma de programación que describe la programación en términos del estado del programa y sentencias que cambian dicho estado. Los programas imperativos son un conjunto de instrucciones que le indican al computador cómo realizar una tarea.
La implementación de hardware de la mayoría de computadores es imperativa; prácticamente todo el hardware de los computadores está diseñado para ejecutar código de máquina, que es nativo al computador, escrito en una forma imperativa. Esto se debe a que el hardware de los computadores implementa el paradigma de las Máquinas de Turing. Desde esta perspectiva de bajo nivel, el estilo del programa está definido por los contenidos de la memoria, y las sentencias son instrucciones en el lenguaje de máquina nativo del computador (por ejemplo el lenguaje ensamblador).
Los lenguajes imperativos de alto nivel usan variables y sentencias más complejas, pero aún siguen el mismo paradigma. Las recetas y las listas de revisión de procesos, a pesar de no ser programas de computadora, son también conceptos familiares similares en estilo a la programación imperativa; cada paso es una instrucción, y el mundo físico guarda el estado (Zoom).
Los primeros lenguajes imperativos fueron los lenguajes de máquina de los computadores originales. En estos lenguajes, las instrucciones fueron muy simples, lo cual hizo la implementación de hardware fácil, pero obstruyendo la creación de programas complejos. Fortran, cuyo desarrollo fue iniciado en 1954 por John Backus en IBM, fue el primer gran lenguaje de programación en superar los obstáculos presentados por el código de máquina en la creación de programas complejos.
500px-PROGRAMA1

Programación lógica

La programación lógica consiste en la aplicación del corpus de conocimiento sobre lógica para el diseño de lenguajes de programación; no debe confundirse con la disciplina de la lógica computacional.
La programación lógica es un tipo de paradigmas de programación dentro del paradigma de programación declarativa. El resto de los subparadigmas de programación dentro de la programación declarativa son: programación funcional, programación basada en restricciones, programas DSL (de dominio específico) e híbridos. La programación lógica gira en torno al concepto de predicado, o relación entre elementos. La programación funcional se basa en el concepto de función (que no es más que una evolución de los predicados), de corte más matemático.
fig_2.3

Programación funcional

En ciencias de la computación, la programación funcional es un paradigma de programación declarativa basado en la utilización de funciones aritméticas que no maneja datos mutables o de estado. Enfatiza la aplicación de funciones, en contraste con el estilo de programación imperativa, que enfatiza los cambios de estado. La programación funcional tiene sus raíces en el cálculo lambda, un sistema formal desarrollado en los 1930s para investigar la definición de función, la aplicación de las funciones y la recursión. Muchos lenguajes de programación funcionales pueden ser vistos como elaboraciones del cálculo lambda.
Los lenguajes de programación funcional, especialmente los que son puramente funcionales, han sido enfatizados en el ambiente académico principalmente y no tanto en el desarrollo de software comercial. Sin embargo, lenguajes de programación importantes tales como Scheme, Erlang, Objective Caml y Haskel, han sido utilizados en aplicaciones comerciales e industriales por muchas organizaciones. La programación funcional también es utilizada en la industria a través de lenguajes de dominio específico como R (estadística), Mathematica (matemáticas simbólicas), J y K (análisis financiero), F# en Microsoft.NET y XSLT (XML). Lenguajes de uso específico usados comúnmente como SQL y Lex/Yacc, utilizan algunos elementos de programación funcional, especialmente al procesar valores mutables. Las hojas de cálculo también pueden ser consideradas lenguajes de programación funcional.
La programación funcional también puede ser desarrollada en lenguajes que no están diseñados específicamente para la programación funcional. En el caso de Perl, por ejemplo, que es un lenguaje de programación imperativo, existe un libro que describe cómo aplicar conceptos de programación funcional. JavaScript, uno de los lenguajes más ampliamente utilizados en la actualidad, también incorpora capacidades de programación funcional.
images

Programación declarativa

La Programación Declarativa, es un paradigma de programación que está basado en el desarrollo de programas especificando o “declarando” un conjunto de condiciones, proposiciones, afirmaciones, restricciones, ecuaciones o transformaciones que describen el problema y detallan su solución. La solución es obtenida mediante mecanismos internos de control, sin especificar exactamente cómo encontrarla (tan sólo se le indica a la computadora que es lo que se desea obtener o que es lo que se está buscando). No existen asignaciones destructivas, y las variables son utilizadas con Transparencia referencial

Programación estructurada

La programación estructurada es una forma de escribir programas de ordenador (programación de computadora) de manera clara. Para ello utiliza únicamente tres estructuras: secuencia, selección e iteración; siendo innecesario el uso de la instrucción o instrucciones de transferencia incondicional (GOTO, EXIT FUNCTION, EXIT SUB o múltiples RETURN).

Otras definiciones.

Estilo de programación

‘El estilo de programación’ se refiere a la forma en que se da formato al código fuente. Para C, esto involucra la forma en que se ubican las llaves, se indenta el código y se utilizan los paréntesis. GNOME tiene una mezcla de estilos de programación y no se obliga el uso de ninguno de ellos. Lo más importante es que el código sea consistente dentro de un programa o una biblioteca — el código con un formato desordenado no es aceptable debido a que es difícil de leer.
Cuando escribas un nuevo programa o biblioteca, sigue un estilo consistente de ubicación de llaves y de indentación. Si no tienes ninguna preferencia personal de estilo, recomendamos el estilo de programación del núcleo de Linux o el estilo de programación de GNU.
Lee el nodo de info (Standards)Writing C en la documentación de GNU. Luego, obtén el código fuente de Linux y lee el archivo linux/Documentation/CodingStyle, e ignora los chistes de Linus. Estos dos documentos te darán una buena idea de nuestras recomendaciones para el código de GNOME.

Estilo de indentación

Para el código del núcleo de GNOME preferimos el estilo de indentación del núcleo de Linux. Usa tabuladores de 8 espacios para la indentación.
Usar tabuladores de 8 espacios para indentación proporciona un número de beneficios. Permite que el código sea más fácil de leer, ya que la indentación se marca claramente. También ayuda a mantener el código ordenado forzando a dividir funciones en trozos más modulares y bien definidos — si la indentación va más allá del margen derecho, significa que la función está mal diseñada y que debiera dividirse para hacerla más modular o bien, repensarla.
Los tabuladores de 8 espacios para indentación también ayudan al diseño de funciones que encajen bien en la pantalla, lo cual significa que las personas puedan entender el código sin tener que desplazarse atrás y adelante para entenderlo.
Si usas Emacs, entonces puedes seleccionar el estilo de indentación del núcleo de Linux incluyendo en el archivo .emacs lo siguiente:
(add-hook 'c-mode-common-hook
          (lambda ()
            (c-set-style "k&r")
            (setq c-basic-offset 8)))
En los nuevos Emacs o con el nuevo cc-mode, puedes ser capaz de hacerlo más simple con:
(add-hook 'c-mode-common-hook
          (lambda ()
            (c-set-style "linux")))

El estilo de indentación de GNU es el predeterminado para Emacs, así que no es necesario agregar nada en el archivo .emacs para habilitarlo. Si deseas seleccionarlo explícitamente, sustituye «gnu» por «linux» en el ejemplo anterior.
Si usas Vim, entonces puedes seleccionar el estilo de indentación del núcleo de Linux incluyendo el siguiente fragmento en el archivo .vimrc:
set ts=8
if !exists("autocommands_loaded")
  let autocommands_loaded = 1
  augroup C
      autocmd BufRead *.c set cindent
  augroup END
endif

Como alternativa puedes seleccionar el estilo de indentación de GNU en Vim usando lo siguiente en el archivo .vimrc[1]:
augroup C
   autocmd BufRead *.c set cinoptions={.5s,:.5s,+.5s,t0,g0,^-2,e-2,n-2,p2s,(0,=.5s formatoptions=croql cindent shiftwidth=4 tabstop=8
augroup END

Nota

Si sabe personalizar el estilo de indentación en otros editores populares, por favor háganoslo saber y así podemos expandir este documento.

Convenciones de nombres

Es importante seguir una buena convención de nombres para los símbolos de los programas. Es específicamente importante para las bibliotecas, ya que no debería ensuciarse el espacio de nombres global — es muy molesto cuando una biblioteca tiene símbolos nombrados desordenadamente que chocan con nombres que pueda querer usar en sus programas.
Los nombres de las funciones deberían ser de la forma modulo_submodulo_operacion, por ejemplo, gnome_canvas_set_scroll_region o gnome_mime_get_keys. Esta convención elimina las colisiones de nombres de símbolos entre módulos. Es muy importante para las bibliotecas.
Los símbolos deben tener nombres descriptivos. Como Linus dice, no use cntusr(), sino que use count_active_users(). Esto permite que el código sea más fácil de leer y casi se auto documenta.
Intente usar las mismas convenciones de nombre que tienen GTK+ y las bibliotecas de GNOME:
  • Los nombres de las funciones en minúsculas, con líneas de subrayado para separar palabras, tal como: gnome_canvas_set_scroll_region(),gnome_mime_get_keys().
  • Las macros y las enumeraciones en mayúsculas, con líneas de subrayado para separar palabras, tal como: GNOMEUIINFO_SUBTREE() para una macro yGNOME_INTERACT_NONE para un valor enumerado.
  • Los nombres de tipos y estructuras usan una mezcla de mayúsculas y minúsculas, tal como: GnomeCanvasItemGnomeIconList.
Al utilizar líneas de subrayado para separar palabras el código estará menos apretado y facilita la edición, ya que puede usar las secuencias de teclas que permiten navegar entre palabras más rápidamente en cualquier editor.
Si estás escribiendo una biblioteca, entonces puedes necesitar exportar símbolos que serán usados sólo dentro de la biblioteca. Por ejemplo, dos de los archivos objeto que componen la biblioteca libfoo.so pueden requerir acceder a símbolos ubicados en el otro archivo, pero se tiene la intención que éstos símbolos no sean utilizados desde los programas de usuario. En este caso, coloca una línea de subrayado antes del nombre de la función y haz que la primera palabra siga la convención estándar módulo/submódulo. Por ejemplo, podrías tener una función llamada _foo_internal_frobnicate().

Consistencia entre nombres

Es importante que las variables se nombren de manera consistente. Por ejemplo, un módulo que manipula una lista puedes elegir nombrar las variables que mantienen un puntero a la lista como «l», por elegancia y simplicidad. Sin embargo, es importante que un módulo que manipula widgets y tamaños no use variables llamadas «w» tanto para widgets y anchos («width») (como en valores de ancho/alto); esto podría hacer que el código sea inconsistente y difícil de leer.
Por supuesto, nombre muy cortos y elegantes solamente deberían ser usados para variables locales de funciones. Nunca llame una variable global «x»; use un nombre más largo que indique lo que significa.

Limpieza

El código de GNOME debe ser tan limpio como sea posible. Esto implica usar un estilo de indentación consistente y una buena convención para nombrar símbolos, como se ha indicado anteriormente. Esto también implica lo siguiente.
Aprender el uso correcto de la palabra reservada staticNo declarar todos los símbolos como globales. Esto tiene la ventaja de poder usar nombres más cortos dentro de las funciones en un sólo archivo fuente, ya que no son globalmente visibles y por consiguiente no necesitas emplear el prefijo módulo/submódulo.
Aprender el uso correcto de la palabra reservada const. Úsala consistentemente, así permitirás al compilador que atrape muchos errores estúpidos.
Si tienes una función que retorna un puntero a un dato interno que se supone que el usuario no debe liberar, deberías usar el modificador const. Este avisará al usuario si intenta hacer alguna operación incorrecta, por ejemplo:
const char *gnome_mime_get_info (const char *info);
El compilador avisará si el usuario intenta liberar la cadena retornada. Esto puede atrapar muchos errores.
Si tienes «valores mágicos» en el programa o biblioteca, usa macros que los definan en vez de usarlos directamente en el código:
/* Amount of padding for GUI elements */
#define GNOME_PAD          8
#define GNOME_PAD_SMALL    4
#define GNOME_PAD_BIG      12

Si tienes una lista de valores posibles para una variable, no uses macros para ellas, usa enum para darle un nombre de tipo — esto permite disponer de nombres simbólicos en un depurador. Además, no uses «int» para almacenar un valor enumerado; usa el tipo enum. Esto le permite al compilador atrapar los errores por tí, permitiéndole al depurador mostrar los valores apropiados y hacer obvios los valores que una variable puede tomar. A continuación un ejemplo:
/* Shadow types */
typedef enum {
 GTK_SHADOW_NONE,
 GTK_SHADOW_IN,
 GTK_SHADOW_OUT,
 GTK_SHADOW_ETCHED_IN,
 GTK_SHADOW_ETCHED_OUT
} GtkShadowType;

void gtk_frame_set_shadow_type (GtkFrame *frame, GtkShadowType type);

Si define un conjunto de valores para un campo de bits, haz lo siguiente:
/* Update flags for items */
enum {
 GNOME_CANVAS_UPDATE_REQUESTED  = 1 << 0,
 GNOME_CANVAS_UPDATE_AFFINE     = 1 << 1,
 GNOME_CANVAS_UPDATE_CLIP       = 1 << 2,
 GNOME_CANVAS_UPDATE_VISIBILITY = 1 << 3,
 GNOME_CANVAS_UPDATE_IS_VISIBLE = 1 << 4
};
Esto hace más fácil modificar la lista de valores y menos propenso a error que especificando los valores a mano. También permite usar estos valores como símbolos en un depurador.
No escribas código ofuscado, intenta que sea espartano. Para clarificar una expresión, no uses más paréntesis que los necesarios. Usa espacios antes de los paréntesis y después de las comas y también alrededor de los operadores binarios.
No escribas hacks en el código. En vez de escribir un hack feo, reescribe el código para que quede limpio, extensible y mantenible.
Asegúrate de que el código compila absolutamente sin ningún aviso del compilador. Esto te ayudará a atrapar errores estúpidos. Usa los prototipos de las funciones en los archivos de encabezados de forma consistente.
Dentro de GNOME puedes usar la macro de Autoconf GNOME_COMPILE_WARNINGS en el archivo configure.in. Esto permitirá contar con un buen conjunto de avisos del compilador de una manera portable.
Comenta el código. Coloca comentarios antes de cada función para decir que hace. No digas cómo lo hace a menos que sea absolutamente necesario; debería ser obvio al leer el código. Si no lo fuera, entonces puedes desear reescribirla hasta que sea fácil de entender.
Cuando documentes las funciones de la API de una biblioteca, sigue las directrices indicadas en el archivo gnome-libs/devel-docs/api-comment-style.txt. Esto permite que el código fuente pueda proporcionar documentación en línea, que posteriormente se extrae mediante el sistema gtk-doc para crear un manual DocBook de forma automática.

Consideraciones de portabilidad

Se construye GNOME en muchas plataformas diferentes. Se puede asumir que serán plataformas más o menos tipo Unix; hasta el momento GNOME no ha sido portado a sistema no-Unix, así que se puede asumir que los servicios estándares de Unix estarán disponibles.[2]
Recuerda que el mundo no es tu propio equipo con GNU/Linux; las gente realmente usa otros tipos de máquinas.
Intenta no usar extensiones específicas de GCC debido a que éstas no funcionarán con otros compiladores. Si realmente debes hacer uso de tal cosa, ve la forma en que se hace en Glib con el conjunto de macros G_GNUC; asegúrate también de incluir código que funcione con compiladores ISO C. Si sólo tienes disponible GCC, aprende a usar las opciones -ansi -pedantic que permiten probar código sospechoso.
Recuerda que algunas plataformas no disponen de GCC o que GDB puede ser inusable en ellos, y se querrán usar otros compiladores y depuradores.

Tópicos relacionados con GTK+

GTK+ permite hacer mucha magia y ofuscación con manejadores de señal, pasar cerraduras y conjuntos de datos. Si te encuentras utilizando muchosgtk_object_set_data() en un mismo lugar, o estas pasando estados de forma extraña a través de manejadores de señales, reescribe el código. Si necesitas adjuntar muchos datos a un objeto en particular, entonces es un buen candidato para una nueva clase derivada, que no sólo hará al código más limpio, sino que también lo hará más extensible.
Mucha de la heurística en manejadores de eventos complicadas a menudo se pueden reemplazar limpiando el código a través de una máquina de estados. Esto es útil cuando se quieren implementar cosas truculentas como selección y comportamientos de arrastrado, y hará al código más fácil de depurar y extender.


 

examen de programacion