Foro de elhacker.net

Hace poco que me introduje en el ambito profesional en IT.

Cuando haces todo por tu cuenta da igual si nombras una funcion como IndexOfArray o pedro_picapiedra con tal de que entiendas tu propio codigo.

En los entornos profesionales es obviamente diferente, y ademas si quisieras mejorar tus practicas en general tambien seria una buena idea tomar en cuenta la excelencia a la hora de nombrar cosas, la maldicion de algunos de nosotros.

He probado los tres enfoques:

ElEnfoqueDeLasMayusculas
elEnfoqueDeLaMinuscula
el_de_la_barra_baja

Esto_Ya_Es_De_Psicopatas

La pregunta es, fuera de bromas, ¿Cual es el mejor enfoque y por que?

Si crees que es un tema personal, entonces:

¿Cual es el mejor enfoque para ti y por que?

Hola!

El primer resultado de Google (https://www.google.com/search?q=camel+case+convention): https://en.wikipedia.org/wiki/Camel_case (https://en.wikipedia.org/wiki/Camel_case)

Saludos!

Hola, los nombres son muy importantes porque ayudan mucho a entender los códigos por ejemplo en las variables poder saber que tipo de informacion contienen.

Los nombres de las variables empiezan por minúscula y si son dos palabras entonces la primera letra es minúscula y la segunda mayúscula, ejemplo:

totalPuntaje = 1200

se pueden usar guiones bajos para separar palabras:

lista_usuarios = 3780

siempre es recomendable que los nombres sean cortos, precisos y no usar acentos u otros caracteres especiales.

Los nombres de las clases comienzan con mayúscula por ejemplo:

Puntajes


Saludos

pues depende del lenguaje o framework que utilices una manera está más utilizada (encouraged) que otra,

en C# .net se utiliza pascal case en los metodos, ejemplo TestConnection(),

en Java o javascript se utiliza camel case, ejemplo getName(),

en Python he visto que se utiliza el snake case, ejemplo get_connection(), aunque también he visto en algunos paquetes el uso de camel case.

Me resulta más cómodo utilizar camel case, me parece más rápido de escribir.

Yo todo lo que escribo lo empiezo con mayúscula a menos que sea una función como eval, if, etc.
Iniciarlo con minúscula me parece poco estético. El por qué de eso no sé, pero es costumbre que todo empiece con mayúscula, si no lo hace me resulta un poco chocante.

Luego, si la palabra me parece relevante la pongo con mayúscula, sino no.
Por ejemplo FuerzadeAlex. No le veo sentido a destacar lo que no es muy relevante, pero es un poco debatible qué lo es en ciertos casos: DistanciahastaRed ¿debería hasta llevar mayúscula? Para mí está bien así, toda distancia es "hasta" al fin y al cabo.
Usar rayas hace que los nombres sean más largos y también me resulta poco estético, e incómodo: Es como que pasas leyendo rayas en vez de texto xD

Algo ¿raro? que hago es usar palabras en español o inglés según se me antoje. Si el asunto me parece medio complejo o no acostumbro las palabras en inglés que debo usar, lo hago en español. Sino, si en inglés es más corto y me suena mejor o igual, lo hago en inglés. Más o menos eso.

Antes acortaba los nombres, o ponía nombres genéricos, especificaba en un comentario qué hacía cada variable, porque de ese modo ahorraba tiempo (más si escribía los códigos en papel, cuando no tenía computadora a mano) y de hecho me entendía más rápido en vez de andar leyendo palabrotas (grandes), por ejemplo sé que Sol es Solución... Pero eso a veces me llevó a no poder retomar mi código por no recordar los significados... En un caso ni siquiera había comentado, tenía anotaciones en un cuaderno, me tomé un tiempo por cansancio y luego ni idea en qué cuaderno ni nada.
Ahora en general pongo nombres completos y específicos, intento para que incluso otra gente lo pueda entender.
Creo que mientras uno piensa o para cosas sencillas puede convenir resumir (N en vez de Numero por ejemplo), pero si se quiere algo serio que toma mucho tiempo... Me parece que en general es mejor especificar, para poder hablarlo con más gente más fácilmente también.

Es recomendable también que los códigos estén escritos en inglés porque además de ser un idioma universal, es más corto también, es decir las palabras son más cortas.

Siempre también es recomendable escribir comentarios en los códigos porque eso ayuda a otros programadores a entender ciertas partes del código, procesamiento, operaciones, instrucciones, etc.

Personalmente prefiero 'Pascal Case', en el trabajo hay que adaptarse a lo que esté en uso en tu empresa (si no hay nada establecido tira de tu preferencia, pero siendo coherente, no mezclando estilos).

Nunca he dado demasiada importancia a la capitalización, por lo que 'Camel Case', no me aporta nada significativo a nivel personal.

El lenguaje Pascal inventó la definición de tipos por su inicial, así podías indicar que todo lo que comenzara con 'a' hasta 'k' eran tipos entero. Facilitaba las cosas, pues bastaban pocas declaraciones para los (pocos) tipos que había entonces, y además en una sola declaración ya incluías como declaradas todas las variables que utilizaras luego... ...y ahí empezó a enredarse todo.

Hoy, hay bastantes 'reglas' mediocres... ...para el español (y otros idiomas). Para el inglés pueden estar bien (de hecho suelen nacer pensado en ellos), pero no para el español, porque exige en muchos casos pulsar simultáneamente 2 teclas a la vez (cuestión de teclados), por ejemplo al usar la_barra_baja_tras_cada_palabra que ralentiza la mecanografía y más aún cuando por esta causa cometes un error al tener que corregirlo, aún así no faltan estúpidos que defienden a ultranza el sistema (y sí, tienen que usar a diario un teclado en español).

Sigue sin haber una solución que satisfaga todo, pues hay gente que quiere llevar en el nombre demasiados conceptos que no le pertenecen.

- Una función debiera ser siempre un verbo (o palabras que verbalicen) 'Comprimir', 'EstaListo', 'Calcular', 'Convertir', 'Existe', 'Guardar'...
- Una propiedad debiera ser siempre el nombre de un adjetivo: 'Color', 'Alto', 'Brillo', 'Edad', 'Precio', 'Ciudad'...
- Las variables privadas, deberían usar siempre una palabra compuesta: 'ColorTinta', 'AlturaVentana', 'EdadAlumno', 'PrecioLibro', 'NombreCiudad'...

Usando nombres coherentes, el tipo básicamente queda reflejado en la mayoría de casos deducible por su significado:
- El número de colores es de varios (pocos) millones (y todo el mundo sabe que dicha magnitud es un numero, aunque se utilice un sistema de numeración no decimal).
- Una ventana no va a tener una altura de millones (y si no fuera en píxeles, añadir el sistema al nombre). Lo mismo que la altura de un edificio tendrá valores en metros y sabemos que no son millones para ninguno. 
- La edad de un alumno, queda acotada dentro de un byte. Y reflejando un numero de años, es absurdo representarlo en texto.
- Un precio es lógico que tenga decimales, indistintmente de la moneda usada.
- Una ciudad siempre es un texto (si no, pondrías 'CodigoCiudad', por ejemplo).
etc...

Entre las propiedades y las variables, la distinción semántica no es suficiente, implican lo mismo, obtener o asignar un valor (de hecho puede invertirse mi anterior entrada), la mayor distinción es para tolerar el tipo de alcance que tienen, luego el nombre puede no distinguir suficiente, ahí si podría utilizar (por sistema) la capitalización, para distinguir unas de otras.

Una clase, es en sí misma un mecanismo, y como tal puede englobar tanto funciones como propiedades e incluso ser anidadas.
En realidad con la llegada de la programación orientada a objetos, el número de entidades de programación se dispara y entonces surje una idea (en realidad vieja, pero que ahora sí queda justificada), de usar 1-3 caracteres para identificar el tipo de entidad. 'strCiudad', 'clsVehiculo', 'fncAbrir'... y ahí parece adecuado que empiece con minúscula como señalando que no es parte de la identificación del nombre si no del tipo de entidad...
 
Luego gente que aprende a programar pero no conoce la base original se monta sus propios sistemas, a veces contradiciendo lo aceptado hasta entonces, suele no prosperar, pero si el individuo en cuestión se hace famosete por alguna cuestión, parece que su criterio 'va a misa' y otros los adoptan sin rechistar, porque al igual que él, no mantienen una memoria del asunto y por tanto 'su solución' les parece más acertada que su caótico quehacer hasta la fecha.

Y si mezclas diferentes casos de este tipo, entonces al final hay quien entra a valorar mejoras y problemas de cada sistema e intenta como resumen proponer el suyo propio donde intenta reunir las mejoras y evitar los problemas, por lo general la solución adolece de otros problemas que en origen cada conjunto no contenía y que por ello éste no contempla ni se le ha pasado por la imaginación, es decir no ha aplicado a su sistema el criterio aplicado a los otros de los que parte...

... y con ello llegamos a la sopa actual, hay de todo. Sírvase al gusto, el sentido común cada vez parece ser más menospreciado.

Serapis, gracias por la respuesta que estaba buscando.

Yo te voy a ser sincero, respecto a Pascal Case tengo mis prejuicios. Windows.

esto_parece_estar_escrito_para_el_kernel_de_linux YEstoParaElDeWindows. ¿Cual es mas bonito? Por alguna razon Snake Case para mi, sin embargo es tambien una cuestion de costumbre. Pero bueno, sin aburrir con cuestiones emocionales, el punto es que voy a adoptar todas las costumbres que tu mencionas independientemente.

Gracias y un saludo.

La mejor forma de nombrar es nombrar a todos los que respondieron a tu post y no a uno solo en particular aunque esa sea la única respuesta que te haya gustado... bueno, yo de programación solo se que existe y mas nada, pero de lo otro que te hablo si... son reglas elementales que nunca se ponen por escrito por su carácter obvio...

Saludos.

 :rolleyes: :o :rolleyes:

Prefiero que se tome por obvio solo que agradezco tambien cualquier otro aporte de informacion.
Si no es obvio, o no importa lo que prefiero, en otras palabras diria que estoy comodo indicando la respuesta que estaba buscando solamente, sin menospreciar cualquier otra ayuda, que es muy bien recibida.

Un saludo.

No habia visto tu respuesta.

Pues esta es una de las cosas que mas me intriga. Las convenciones.

Sinceramente estoy un poco confundido entre la idea de mantener un estilo o cambiarlo acorde al lenguaje.

Lo mas importante es la constancia y la congruencia interna. Es decir so usas camel case para tus estructueas o classes asegurate que todos Sean de esta manera. Aparte cada lenguaje tiene sus convenciones y si quieres ser muy correcto siguelas, por lo general estan en su documentacion. Por ejemplo python tiene PEP 8 o Java tambien tiene sus buenas practicas con respecto al nombre de variables.

Lo ideal es seguir las convenciones del lenguaje en que estés programando y nombrar muy detalladamente los diferentes elementos (constantes, variables, métodos/funciones, etc etc).

A día de hoy existen herramientas de autocompletado que facilitan esta tarea. Igualmente yo me aseguraría que el nombre sugerido es el adecuado para cada caso (en la mayoría lo es pero para algunos casos puede que quieras indicar un nombre diferente por algún motivo). Con respecto al nombre generado suelen basarse en el tipo al que representan y si el tipo pertenece a una colección suelen añadir una S al nombre.

Ejemplo tipo en java:

class Example {
  private Pelota (autocompletar, solo completa el nombre del atributo: 'pelota')
}

class Example {
  private Pelota pelota = new Pelota(...);
}

Ejemplo colección en java:

class Example {
  private List<Pelota> (autocompletar, solo completa el nombre del atributo: 'pelotas')
}

class Example {
  private List<Pelota> pelotas = new ArrayList<>();
}

Estos ejemplos son sencillos pero los identificadores pueden a llegar ser mucho más complejos:

class Example {
  private HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor hasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor;
}

Me gustaría añadir que debemos intentar usar los nombres más cortos posibles pero que sean completamente descriptivos. Que sean largos ahora no es un problema, que para algo existe el autocompletado.