Pascal Case under_scores, camelCase y PascalCase – Las tres convenciones de nomenclatura que todo programador debe conocer

Los distintos tokens de tu código (variables, clases, funciones, espacios de nombres, etc.) pueden ser nombrados utilizando uno de estos tres estilos, a grandes rasgos:

  1. CasoCamel (ex: algunaVar, algunaClase, algúnPaquete.xyz).
  2. CasoPascal (ex: algunaVar, algunaClase, algúnPaquete.xyz).
  3. Subrayas (ex: alguna_var, alguna_clase, algún_paquete.xyz).
  4. En el caso de las mayúsculas, los nombres comienzan con minúscula pero cada palabra propia del nombre se escribe en mayúscula, así como los acrónimos. Por ejemplo, tokens de uso común en muchos lenguajes como toString, checkValidity, lineHeight, timestampToLocalDateTime, etc. son todos ejemplos de camel casing.

    El casing de Pascal es similar al casing de camello, excepto que la primera letra también comienza con una letra mayúscula (SomeClass en lugar de someClass).

    En el casing de subrayado, todo está en minúsculas (incluso los acrónimos) y las palabras están separadas por guiones bajos (some_class, some_func, some_var, etc). Esta convención también se conoce popularmente como snake case.

    La idea general es que puedes utilizar cualquier convención en tu proyecto siempre que seas coherente al utilizarla en todas partes. Pero cuando codificas para un proyecto o equipo grande, debes ajustarte a la norma de lo que se usa allí. Por lo tanto, es útil ser consciente de las convenciones típicas en varios lenguajes de programación.

    La práctica general para un lenguaje de estilo C como Java o JS es utilizar camelCase para todas las variables y miembros de los objetos (propiedades & métodos), y PascalCase para los nombres de clase y constructores. Los espacios de nombres (o paquetes en el mundo Java) suelen estar en camelCase.

    Pero algunos lenguajes hacen una excepción a esto. C#, por ejemplo, utiliza PascalCase para los espacios de nombres e incluso para los métodos públicos. De ahí que la función principal (o punto de entrada) sea siempre static void main() en java pero static void Main() en C# (Nótese la mayúscula de la palabra «Main»).

    Algunos lenguajes que no derivan su sintaxis de C (como Python & Ruby) utilizan guiones bajos para casi todo excepto para los nombres de las clases. Por lo tanto, siempre es sys.base_prefix en lugar de sys.basePrefixdatetime en lugar de DateTimestr.splitlines() en lugar de str.splitLines() en python.

    En el caso de la librería estándar de python, me he dado cuenta de que incluso las clases usan guiones bajos a veces lo que es una incoherencia. Por ejemplo, datetime.datetime es una clase y también lo es csv.excel_tab. Sin embargo, los frameworks y librerías más populares (como django y flask) utilizan el camel case para las clases.

    Una inconsistencia similar se da en PHP. El lenguaje está evolucionando de guiones bajos a camel casing en los últimos años, pero algunos viejos tokens todavía persiguen ese lenguaje. Por ejemplo, mysqli::set_local_infile_default vs PDOStatement::debugDumpParams.

    Así que, en última instancia, se reduce a su propia preferencia cuando usted está comenzando un proyecto. Pero ayuda a saber cuáles son las convenciones que se suelen seguir en proyectos populares de código abierto en el idioma de tu preferencia.

    Actualización

    Hay un cuarto caso también como señala @ovais, a saber, el caso kebab. Es muy parecido al underline casing, excepto que los subrayados son reemplazados por guiones (dashes). Así, some_func se convierte en some-func, lo que obviamente no está permitido porque el guión no se utiliza para nombrar tokens, ya que está incorporado para el operador menos en la mayoría de los lenguajes de programación. Donde más se usa el kebab case es para crear clases en tus hojas de estilo css. Nombres como main-divmain-navbar y article-footer son comúnmente utilizados por los desarrolladores web al escribir su HTML/CSS. Esta convención es básicamente el caso del kebab.

    Actualización

    Como dice @patrykrudnicki, las constantes se manejan de manera diferente. En mi experiencia, los guiones bajos completos (SOME_CONST) es una convención popular para las constantes en muchos lenguajes, incluyendo Java, PHP y Python.

    Actualización

    Para resumir, esta es la convención típica o generalmente seguida en los lenguajes de programación de código abierto más utilizados:

    .

    .

    Token python Java/JS PHP
    variable under_score camelCase mix (avanzando hacia camelCase)
    función under_score() camelCase()) mix (avanzando hacia camelCase())
    constante UNDER_SCORE UNDER_SCORE UNDER_SCORE
    clase PascalCase PascalCase mix (avanzando hacia PascalCase)
    namespace under_score camelCase mix (avanzando hacia PascalCase)

    Algunos enlaces útiles:

    1. https://softwareengineering.stackexchange.com/questions/196416/whats-the-dominant-naming-convention-for-variables-in-php-camelcase-or-undersc
    2. https://stackoverflow.com/questions/149491/pascal-casing-or-camel-casing-for-c-sharp-code
    3. https://www.c-sharpcorner.com/forums/when-to-use-camel-case-and-pascal-case-c-sharp
    4. https://softwareengineering.stackexchange.com/questions/53498/what-is-the-philosophy-reasoning-behind-cs-pascal-casing-method-names

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *