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, 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

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.

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.

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.