Cita: Si digo que un paradigma es un conjunto de normas que se siguen al intentar programar ¿está bien?
No, un paradigma es un modelo, no un conjunto de reglas.
De la definición del modelo se pueden inferir reglas prácticas de trabajo, pero las reglas no son parte del modelo.
La definición de
modelo y
paradigma llevan mas o menos cuatro clases de discusiones en una materia de la facultad, y dan mucha tela para cortar, pero en esencia, es un modo coherente de representar la
realidad o
sistema.
Existen múltiples formas de modelar los sistemas, y cada uno de ellos está contenido dentro de uno o más paradigmas.
Ese nivel de abstracciones es algo complejo de aprender a manejar.
Cita: Llevado a mi ámbito, creo que "usar frames" es un paradigma y "no usar frames" es otro ¿es así?
Usar o no frames es un tema de tecnología, no de modelo o de paradigmas. Es la forma en que algo se
implementa, pero no es parte del modelo.
En tu caso se trataría de programación imperativa, aunque como ya te dije, al no funcionar el AS sin compilación fuera de un entorno de una determinada aplicación, incluirlo entre los lenguajes de programación es discutible.
Cita: Pero me parece que "lo que te resulta más simple" está bien, no hay necesidad de seguir normas a priori SALVO para ser comprendido por otros que las siguen al pie de la letra o lo que sea, y también para comprender los propios códigos si se ponen muy difíciles.
Improvisativo =)
Nota: Para que termine en ativo como imperativo y declarativo, pero si vamos al caso sería improvisación o algo así sí...
Seguir las normas es necesario para comunicarse y transmitir las cosas a otros. Si no deseas obligarte a ti mismo e imponerte respetar las normas comunes a todos, no esperres que el resto entienda lo que preguntas o pueda comprender lo que haces.
Nadie es una isla, y todos debemos hablar un lenguaje común, una
lingua franca. Y esa lengua está dada por las reglas y normas de programación que son comunes a todos los lenguajes.
Queda a tu criterio.
En cuanto a lo de "improvisativo", probablemente lo que estés haciendo esté más relacionado con las técnicas ágiles, con lo que en realidad no estás inventando nada sino usando algo ya inventado... solo que con otro nombre.
Cita: Eso, lo importante es saber la técnica no cómo le dicen...
Nop. Es importante saber cómo se llama, y usar ese nombre, de lo contrario nadie te entenderá cuando preguntes algo.
Cita: Debo copiarlo en modo normal. Pero en definitiva si el código tiene muchos ifs o dows dentro de otros entonces no entrará en la pantalla y aparecerá una línea debajo de la otra ¿no? ¿qué puedo hacer en esos casos?
Deja que nosotros nos preocupemos por ese salto de linea. Pero procura no usar 2l "CODE" para poner código, es un etiquetado espantoso. Usa el resto de los Highlight, para que se formatee mejor.
Cita: Me gusta usar variables cortas,
para escribir menos,
para que el código sea más corto,
para que ocupe menos espacio -supongo-,
para que funcione más rápido -supongo-,
creo que eso es todo.
- Ni las variables cortas (vicio heredado de BASIC) ayudan en nada, ni hacen el código más comprensible.
- Que el código sea corto, hace que sea proclive a errores de interpretación por otras personas. Te insisto en que nadie es una isla. Si luego pides ayuda, no te vas a poner a "agregar" lo faltante, eso te lo puedo asegurar, vas a hacer un Copy+Paste y seguiremos con el mismo problema.
-
Acostumbate a escribir códigos claros y limpios. Ayuda a desarrollar una metodología de fácil mantenimiento.
Además, es una cuestión de costumbres, al principio tienes que pensarlo, pero luego es un reflejo condicionado y lo haces correctamente sin dudar.
- Finalmente: hacer el código más corto no hace que compile más rápido ni funcione más agilmente. Porque lo que luego queda al compilar, no es el nombre de las variables. Eso es para que los seres humanos lo entiendan. La PC no lo ve.