9 convenciones de nombres confusos para principiantes

Especialmente cuando se comienza con varios lenguajes de desarrollo web, puede resultar una tarea difícil aprender todas las convenciones de nomenclatura de un idioma a otro. Esto puede resultar aún más confuso cuando los desarrolladores no están de acuerdo con lo que se considera una mejor práctica. Para ayudar a facilitar la transición para los principiantes, esta lista describirá algunas de las convenciones más comunes.

1. Subrayar antes del nombre de la propiedad

Cuando te encuentras con una variable o método que es precedido por un _, no se realiza magia vudú detrás de escena. Es simplemente una convención de nomenclatura que le recuerda al desarrollador que la variable/propiedad/método es privada o protegida, y no se puede acceder desde fuera de la clase.

Método en PHP

1

// This variable is not available outside of the class

2

private $_someVariable;

3

4

class MyClass {

5

   // This method is only available from within this class, or

6

   // any others that inherit from it. 

7

   protected function __behindTheScenesMethod() {}

8

}

Ten en cuenta que, en el código anterior, el guión bajo no es lo que hace que la variable o el método sean privados; la palabra clave private/protected hace eso. ¡El guión bajo es solo un recordatorio para los próximos seis meses!

Método en JavaScript

1

var Person = (function() {

2

   var _trueAge = 50,

3

        _trueWeight = 140;

4

5

   return {

6

      age : _trueAge - 15,

7

      weight : _trueWeight - 30

8

   };  

9

})();

10

11

Person.age; // 35

12

Person.weight; // 110

13

Person._trueAge; // undefined (cause it's private, yo)

Al hacer que Person sea igual a, no a una función (function), sino al objeto devuelto, podemos crear variables privadas. Nuevamente, el prefijo de subrayado nos recuerda esto.

2. Constantes en MAYÚSCULAS

Una constante es una variable con un valor estático, que no cambiará. Por ejemplo, si tu proyecto requiere la necesidad de multiplicar un valor por el impuesto estatal, puedes asignar esta tasa, $.0825 a una constante. Sin embargo, no todos los lenguajes tienen estos tipos de variables integrados. Como tal, es una buena práctica usar todas las letras mayúsculas para recordarnos que estamos trabajando con una constante. Esta es una convención común en el mundo de JavaScript y se usa en sus objetos nativos, como MATH.PI.

Método en JavaScript

1

var TAXRATE = .0825;

Método en PHP

1

define('TAXRATE', .0825);

3. Prefijos de una sola letra

Seguramente, en algún momento, te has encontrado con una variable precedida por una sola letra, como "s" o "i".

1

$sName = 'Captain Jack Sparrow';

Esto se conoce como notación húngara y ha caído en desgracia en los últimos años, aunque sigue siendo una convención que utilizan muchas empresas.

La notación húngara es una convención de nomenclatura que le recuerda al desarrollador el tipo de variable con la que está trabajando: cadena, entero, etc.

Particularmente en el mundo de JavaScript, esta práctica está mal vista, debido al hecho de que es un lenguaje poco escrito. Un lenguaje de tipo flexible es aquel que no requiere que declare el tipo de datos de una variable. ¿Por qué es tan importante? ¿Qué pasa si, usando la convención de notación anterior, declaramos una cadena con el prefijo "s", pero luego cambiamos la variable a un número entero? En ese momento, esta forma de notación funcionaría en nuestra contra, no a nuestro favor.

1

var sName = "Lieutenant Commander Geordi La Forge";

2

typeof(sName); // string

3

....

4

sName = undefined;

5

typeof(sName) // undefined

El símbolo del dólar

Usuarios de jQuery: antes de pisar tu pedestal y felicitarte por no usar esta forma de notación, pregúntate si prefijas las variables, envueltas en el objeto jQuery, con un símbolo de dólar. Si es así, es una forma de notación húngara. Es un símbolo con el prefijo de un nombre de variable que tiene el único propósito de informarte sobre el tipo o las cualidades de la variable.

1

// The dollar symbol reminds me that this variable

2

// has access to jQuery's various methods. 

3

var $container = $('#container');

¿Deberías usarlo?

Eso depende totalmente de ti. Incluso muchos miembros del equipo de jQuery usan el método de prefijo de dólar. En última instancia, si funciona para ti, eso es todo lo que importa. Personalmente, hace aproximadamente un año, ya no uso el prefijo del símbolo del dólar, pero solo porque me di cuenta de que no era necesario para mí. Decídete por ti mismo.

4. Primera letra en mayúscula

¿Qué pasa con esos nombres de "variables", que escriben en mayúscula la primera letra del nombre?

1

$response = $SomeClass->doSomething();

En el código anterior, $SomeClass está en mayúscula porque es una clase y no un nombre de variable. Nuevamente, esta es una convención de nomenclatura que utilizan la mayoría de los desarrolladores. Al volver al código un año después, es una pequeña bombilla que les informa que están trabajando con una clase, que tiene objetos y métodos disponibles.

1

// Note the capital M in the class name. 

2

class $MyClass {

3

   function __construct() {}

4

}

El mundo de JavaScript

En JavaScript, realmente no tenemos clases; pero tenemos funciones constructoras.

1

var Jeff = new Person();

La razón por la que escribimos en mayúscula el nombre del constructor (Person) es porque a veces puede resultar fácil olvidar la palabra clave new. En estas circunstancias, JavaScript no arrojará ninguna advertencia, y puede ser una pesadilla rastrear el error. El uso de mayúsculas es una alerta útil para el desarrollador durante la depuración. Douglas Crockford es un gran defensor de esta convención.

Alternativamente, si deseas protegerte contra el olvido de tu yo futuro, primero puedes asegurarte de que el constructor sea, de hecho, correcto, antes de continuar.

1

function Person(name) {

2

  // If the new keyword is absent, the constructor will be the window.

3

  // In this case, compensate, and return a new instance

4

  if ( this.constructor !== Person ) {

5

    return new Person(name);

6

  }

7

 this.name = name;

8

}

9

10

// Intentionally forgot the "new" keyword 

11

var Joey = Person('Joey');

12

Joey.name; // Joey

5. CamelCase contra under_score

¿Por qué algunas variables usan un patrón camelCase, mientras que otras usan un guión bajo para separar palabras?, ¿cuál es el método correcto? La respuesta es que no existe un uso correcto. Depende completamente del idioma y/o las convenciones de codificación de tu empresa. Ambos son perfectamente aceptables.

1

// camelCase

2

var preacherOfSockChanging = 'Lieutenant Dan';

3

4

// under_score

5

var preacher_of_sock_changing = 'Lieutenant Dan';

Sin embargo, con todo lo dicho, es una mejor práctica, cuando tienes la opción de seguir las convenciones comunes del idioma que estás utilizando. Por ejemplo, la gran mayoría de los desarrolladores de JavaScript utilizan la sintaxis camelCase, mientras que otros lenguajes, como PHP, tienden a preferir el uso de subrayado. Aunque, de nuevo, esto no está escrito en piedra. Zend Framework aboga por camelCasing como una mejor práctica.

¡Más importante que lo que usas es asegurarte de cumplirlo!

6. Estructura del directorio

Particularmente cuando se trabaja en equipo, es esencial que adoptes la estructura de directorio adecuada como tus compañeros desarrolladores. Pero, como mínimo, no dejes caer todas tus hojas de estilo y scripts en la raíz de tu proyecto, sin ninguna organización. Muchos desarrolladores prefieren colocar todas sus imágenes, scripts y hojas de estilo dentro de un directorio principal llamado Assets.

1

/ Project Root

2

  /Assets

3

    / js

4

      / min

5

        script_min.js

6

      script.js

7

    / css

8

      / min

9

        style_min.css

10

      style.css

11

    / img

12

      img1.jpg

13

  index.html

14

  otherFile.html

Además, ten en cuenta la convención de crear también una carpeta min, que contenga las versiones minificadas agregadas dinámicamente de tus scripts y hojas de estilo.

7. Semántica

Al crear el marcado, con suerte, se entiende ampliamente que los id's y las clases que elijas deben describir el tipo de contenido, y no los aspectos de presentación. Como ejemplo:

Realmente malo

1

<div id="middle-left-and-then-a-little-lower"> Justin Bieber is my homeboy section. </div>

Mejor

1

<div class="section"> Justin Bieber is my homeboy section. </div>

Mucho mejor

1

<section> Justin Bieber is my homeboy section. </section>

¿Cómo? ¿Qué pasa si, seis meses después, decides colocar tu sección de fans de Justin Bieber en la sección del medio-a-la-DERECHA-y-luego-un-poco-más-abajo? En ese momento, tu id tendrá poco sentido.

A medida que hacemos la transición a un mundo HTML5, deberías encontrarte utilizando muchos menos identificadores en tus elementos. Los id's son menos flexibles y muchas veces innecesarios.

8. Headers y Footers dobles

¿Sabes lo que apesta? Cuando se trabaja en un sitio web centrado que requiere varios fondos que se extienden por todo el ancho de la ventana (generalmente para el encabezado (Header) y el pie de página (Footer)), generalmente debes envolver tu contenido para que el elemento externo se extienda, mientras que el elemento interno puede permanecer centrado.

Como se trata de un problema común, es importante adoptar una convención común para crear el marcado necesario.

1

<div id="footer-wrap">

2

	<footer>

3

	  My footer content goes here.

4

	</footer>

5

</div>

La decisión difícil aquí es que, asumiendo que estás trabajando con los nuevos elementos HTML5, debes decidir si colocar el elemento footer en el interior o en el exterior. Todavía está en discusión, sin embargo, tiendo a sentir que es más semántico colocar el elemento footer real en el interior.

Los div's deben usarse solo cuando:

• No hay mejor elemento para el trabajo.
• Cuando tu necesidad del elemento es simplemente estructurar un diseño.

9. Atajos

Decide ahora si permitirás o no el uso de atajos en tu código. Escribir código limpio y preciso es siempre una batalla entre la legibilidad y el tamaño. Por eso es fundamental que los equipos de desarrollo sigan las mismas pautas de codificación. Para proporcionar dos ejemplos rápidos:

¿Está bien el operador ternario contigo?

1

var name = 'Joe';

2

3

// regular

4

if ( name === 'Jeff' ) {

5

  alert("That's me");

6

} else {

7

  alert("Nope");

8

}

9

10

// ternary

11

(name === 'Jeff') ? alert("That's me") : alert("Nope"); // Nope

¿Qué pasa con el && lógico para los condicionales de mano corta?

1

var getTweets = true;

2

3

// regular

4

if ( getTweets ) {

5

 alert('getting them now');

6

}

7

8

// Logical AND

9

// Right-side won't run, unless left-side is "true"

10

getTweets && alert('Getting them now');

Muchos desarrolladores desaprobarán el uso del AND lógico en este caso, insistiendo en que limita la legibilidad. Este es ciertamente un argumento válido, aunque, no obstante, incluso las bibliotecas populares como jQuery hacen un uso intensivo de este método.

Conclusión

Para reiterar, las convenciones específicas que elijas son mucho menos importantes que asegurarte de que sigas siendo coherente con su uso. De hecho, muchos equipos de desarrollo escriben sus propias pautas de convención para los nuevos desarrolladores. ¡Gracias por leer!