ATS.H

ATS es un proyecto de librería para el lenguaje de programación C. ATS significa "Alternative to Standard" (Alternativa al estándar) y tiene como propósito recoger algunas funciones útiles y sencillas, pero pesadas a la hora de ser escritas.

---

Colaboradores:

• Creador: GNU_López (Sergio López)
• Colaborador: nicolas_cof
• Colaborador: Didacso
• Colaborador: eagle17
• ...

Discursiones sobre Funciones y procedimientos:

atsInNum() http://foro.elhacker.net/programacion_cc/atsinnum-t295749.0.html

/**********************************************/

Si quieres colaborar, envíame un MP y te añadiré a la lista.

---

¿Qué va a ser ats?

Mi idea es crear un archivo de cabecera libre para el lenguaje de programación C, que ofrezca varias funciones nuevas, y la sustitución de algunas estándar para poder darlas un mayor uso. Cualquier persona puede colaborar, tanto aportando ideas, como aportando código, corrigiendo fallos, escribiendo archivos de ayuda, etc.

¿Qué funciones podré usar?

(Esta explicación va a variar dependiendo del desarrollo de la cabecera) Lo ideal es ofrecer una lista de funciones matemáticas, y de entrada y salida de datos.

---

Página en SourceForge:

http://atshead.sourceforge.net/

Prototipo:

http://sourceforge.net/projects/atshead/files/prototype.c/download

---

Especificaciones de Diseño: (Escribiendo...)

En este documento es especifica la forma en la que se debe escribir funciones
para la cabecera ats. Esto es necesario para que no se mezclen todos los estilos
de programación de todos los colaboradores que escriban código; De esta forma,
se mantendrá un orden interno en cuanto a la estructura.

1. Comentarios

* Se debe especificar en cada prototipo de función, con un comentario, la utilidad
  de la misma. En caso de ser una función muy grande/usada dentro de la cabecera,
  el comentario debe especificar también la forma de usar los parámetros, el trabajo
  interno, y los valores de retorno.

* Es aconsejable también comentar en las variables muy usadas o importante, explicado
  para que las usamos.

* Es conveniente también que los comentarios estén en inglés, pues es el idioma mas usado
  en la programación, aunque, no estaría de mas que estuviera tanto en Castellano como en Inglés,
  siendo aśi de fácil lectura para un grupo mas grande de usuarios.

2. Identificadores

* Es conveniente usar identificadores que no puedan ser usados por otras librerías, por
  ello es recomendable seguir este modelo:

- Ejemplo de prototipo de función:

        int ats_pedir_enteros(int a, int b)

  Nótese el uso de 'ats_' al principio, y que el nombre de la función describe también el
  funcionamiento de la misma.

3. Funciones

* Todas las funciones usadas deben ser estándar, así como tienen optimizadas para ser usadas
  en la mayor cantidad de compiladores/sistemas. Es necesario no usar funciones como system
  o fflush.

4. Diseño

* La cabecera tendrá la siguiente forma:

Inicio
|
|_ Cabeceras estándar (#include...)
|_ Definidos (#define...)
|
|
|_ Preámbulo
|
|
|_ Prototipos de función
|_ Comentarios de funciones importantes
|
|
|_ Funciones
|
|
|_ Referencia para programadores (Explicación sencilla sobre el uso de ats)
|
|_ EOF

5. Algunos consejos

* Es conveniente no usar, bajo ningún concepto, bucles infinitos o descontrolados,
  así como intentar optimizar el código al máximo,de tal forma que intentemos ahorrar
  código y mejorar la funcionalidad. Así mismo, es importante intentar no usar recursividad,
  identificadores de variables repetidos, o funciones con semejante funcionamiento.

  Escrito y corregido por: Sergio L, Nicolás.

---

Proyecto


Preámbulo de la cabecera:

---

El contenido del post puede variar, acorde al desarrollo de la cabecera ATS. Los archivos de ATS están bajo licencia pública GPLv3.

últimamente estoy necesitando muchas de estilo entrada de datos(Sobretodo funciones con cadenas ) Y pensé en hacerme una buena librería para no tener que reescribir código tantas veces. Es solo un ejemplo, supongo que lo bueno sería ver que cosas suele querer la gente, e intentar adaptarlo..

Primero y principal hay que aclarar varias cosas:

Lo primero es quienes van a participar, de lo contrario cualquiera va a llegar y a poner un código sin siquiera tal vez conocer los requisitos para poner un código. Seria un desorden.

Por otro lado, respecto de los requisitos, lo ideal es que cada usuario que codifique su función haga como mínimo una documentación de como se utiliza, sus parámetros y su valor de retorno.

Otra cosa importante es que las funciones estén testeadas y elaboradas. Control de parámetros por ejemplo, valores de retorno útiles y demás. Nada de funciones void copiarcad y un for, por si va a ser así la verdad no tiene ningún sentido.

Como bien dijo Nico, hay que dejar en claro cual es el objetivo general de las funciones, para asi cada uno puede ir viendo que hacer y que no.

No se si tendré tiempo de codificar algo, tal vez el fin de semana. Igualmente pasare cada tanto para revisar los códigos.

Saludos!

Bueno, estuve pensado y he llegado a las siguientes conclusiones: Llevar un post en el foro con el source de la librería, llevar adjuntada la documentación de la misma, y las especificaciones de funciones y retornos. A la par, una lista de colaboradores y unas 'normas' para quien quiera aportar o corregir source. Como bien habéis dicho, todo debe estar testeado, y, a ser posible, que las funciones usen cabeceras estándar para poder ser mas portables.

En cuanto al contenido, me gustaría que fuera un sustituto de algunas funciones ya existentes (Matemáticas sobretodo) y algunas funciones de entrada/salida de datos. Claro, esta es mi idea, creo que lo mejor es que fuera de propósito general.

¿Qué os parece? Si os animáis, vamos creando el post con los primeros colaboradores, y vamos trabajando en las normas y tal.

No he leído las condiciones, pero me imagino que si XD Pero supongo que la gracia es hacerlo directamente desde el foro. Aún así, SF es muy buena idea.