Cómo utilizar nombres con espacios en Java

¿Existe una razón técnica por la cual los espacios no están permitidos en nombres de constantes, variables, métodos, clases y namespaces o se trata de un acuerdo de cualquier convenio? Esta pregunta también se puede aplicar en relación a los dígitos, los cuales, como ya sabéis, no se pueden colocar al principio de cualquier nombre.

La razón principal de seguir una estandarización con los nombres es el de reducir el esfuerzo de leer y entender el código fuente. Los desarrolladores deben centrarse en cuestiones más importantes que discutir sobre la sintaxis y los estándares de nomenclatura. Por esta razón, no existe una regla estricta para el uso de mayúsculas y minúsculas. Un nombre puede ser cualquier identificador legal - una secuencia de longitud ilimitada de letras Unicode y dígitos, comenzando con una letra o el carácter guión bajo. No están permitidos los espacio en los nombres.

Los espacios en blanco no solamente se eliminan del nombrado por cuestion de entendimiento del código fuente. El compilador necesita saber el significado de las palabras. Este trabaja mediante un método de "State Machine", y necesita distinguir las palabras clave. Sin embargo, existen lenguajes como SQL o Maple donde los nombres pueden contener espacios en blanco. No tal cual, pero es posible utilizarlos si los encerramos entre comillas: como por ejemplo "[" y "]" en SQL. En C#, los corchetes se utilizan como indexadores de items de colección. Pero el caracter acento puede utilizarse como símbolo adjunto.

Vamos a escribir un código en C# utilizando nombres bastante largos que contengan espacios y, vamos ver qué pasa.

Ejemplo de código

[`Custom Serialization Attribute`]
public class `Config Data File Repository` : `Configuration Repository Interface` {
  public enum `Data Visualization Format` { `2D`, `3D` }
  public `Data Visualization Format` `Visualization Format` { get; set; } 
    = `Data Visualization Format`.`2D`;
  ... 
  private readonly string `repository file name`;
  public `Config Data File Repository`(string `repository file name`) {
    this.`repository file name` = `repository file name`;
  }
  public `Configuration Data` Load() {
    using(var fs = new `File Stream`(`repository file name`, `File Mode`.Open)) {
    return `Load From Stream`(fs);
    }
  }
  public void Save(`Configuration Data` `current configuration`) {
    using (var fs = new `File Stream`(
      this.`repository file name`, `File Mode`.`Create New`)) {
      `Save To Stream`(`current configuration`, fs);
    }
  }
  ...
  public const string `DEFAULT REPOSITORY FILE` =
    "Default Config Data File Repository.config";
  
  public static `Config Data File Repository` `Create Config Data File Repository`(
    string `file Name` = `Config Data File Repository`.`DEFAULT REPOSITORY FILE`) {
    return new `Config Data File Repository`(`file Name`);
  }
}

Ya que nos ponemos, vamos a escribir un código en Java que trate sobre problemas del mundo real.

@Entity
@Table(name = "[PERSONAL CONFIGURATION SECTIONS]")
@EntityListeners( { HierarchyListener.class } )
@NamedQueries({
  @NamedQuery(
    name = "`Personal Configuration Section`.`find All`",
    query = "SELECT cs FROM [PERSONAL CONFIGURATION SECTIONS] cs"),
  @NamedQuery(
    name = "`Personal Configuration Section`.`find By Configuration Section Id`",
    query = "SELECT cs FROM [CONFIGURATION SECTIONS] cs "
      + "WHERE cs.[configuration Section Id] = :`configuration Section Id`")})
public class `Personal Configuration Section`
  implements Serializable, `Hierarchy Element Interface` {
  private static final long `serial Version UID` = 1L;
  @Id @NotNull
  @Basic(optional = false)
  @`Generated Value`(
    strategy = `Generation Type`.SEQUENCE,
    generator = "global_id_gen")
  @`Sequence Generator`(name = "global_id_gen", `sequence Name` = "GLOBAL_ID_GEN")
  @Column(name = "[CONFIGURATION SECTION ID]")
  private Integer `configuration Section Id`;
  public Integer `get Configuration Section Id`()
    { return `configuration Section Id`;  }
  public void `set Configuration Section Id`(Integer `configuration Section Id`)
    { this.`configuration Section Id` = `configuration Section Id`; }
  
  @Column(name = "[FULL NAME]")
  private String `full Name`;
  public String `get Full Name`()
    { return `full Name`;  }
  public void `set Full Name`(String `full Name`)
    { this.`full Name` = `full Name`; }
  
  @Column(name = "[EXPERIENCE, SKILLS AND ARTIFACTS]")
  private `Collection Interface` `experience, skills and artifacts`;
  public `Collection Interface` `get Experience, skills and artifacts`()
    { return `experience, skills and artifacts`; }
  public void `set Experience, skills and artifacts`(
    `Collection Interface` `experience, skills and artifacts`)
    { this.`experience, skills and artifacts` = `experience, skills and artifacts`; }
  
  @`Many To One`(fetch = `Fetch Type`.LAZY)
  @`Join Columns`({
    @`Join Column`(
      name="[PARENT ID]",
      `referenced Column Name`="parent Configuration Section Id"),
    @`Join Column`(
      name="[PARENT VERSION]",
      `referenced Column Name`="parent Configuration Section Version")
    })
  private `Personal Configuration Section` parent;
  public `Personal Configuration Section` `get Parent`()
    { return parent; }
  public void `set Parent`(`Personal Configuration Section` parent)
    { this.parent = parent; }
  
  @`One To Many`(fetch=`Fetch Type`.LAZY, `mapped By`="parent")
  private Set<`Personal Configuration Section`> children;
  public Set<`Personal Configuration Section`> `get Children`() { return children; }
  
  public `Personal Configuration Section`() {}
  
  public `Personal Configuration Section`(
    Integer `personal Configuration Section Id`) {
    this.`personal Configuration Section Id` = `personal Configuration Section Id`;}
  
  ...
}

Sin duda, es posible hacer que el compilador analice este código. Sin embargo, el código es mucho más ininteligle. Este problema ha existido desde el origen de los lenguajes orientados a objetos. Según mi punto de vista, siempre tenemos que tener en mente a otros desarrolladores que puedan leer este código después que nosotros. No hay nada más molesto que picar código mal documentado y que no se entienda. Es por eso que siempre hay que nombrar bien las variables, constantes, namespaces... Esto te ayudará no solo con el naming de tus proyectos, sino a que tu código sea más legible sin escribir una documentación y comentarios innecesarios. Si un nombre es demasiado largo, entonces es posible que esa parte del código cuente con múltiples responsabilidades que deban ser escritas por separado. En otras palabras, el código debe estar re-factorizado.

Pensando en todo esto, me asalta una pregunta, ¿cómo mejorar la legibilidad y dónde utilizar esta característica?. Las principales áreas de la aplicación pueden ser definidas como clases de pruebas unitarias y clases que contienen propiedades de internacionalización de strings implementadas por la configuración de recursos o la configuración de la sección de ajustes de las clases contenedoras. La legibilidad podría mejorarse mediante las características del IDE. Por ejemplo, los nombres con espacios en blanco destacan por un borde fino de puntos. Este enfoque permitirá a los desarrolladores identificar nombres de manera visual y rápidamente, y restringirá el uso irreflexivo generalizado de nombres con espacios en blanco.

Vamos a tratar de escribir una unit test sencilla en C#.

Ahora lo reescribiremos en Java.

Como véis, el resultado es totalmente legible...