4 bits blog

Una de las máximas de los programadores es que el código debe ser fácilmente legible. Suele decirse que no hay mejor documentación de un programa que su código fuente. Hacer lo contrario, programar deliberadamente de forma que no sea legible es una práctica de programación conocida como ofuscación. Un arte como otro cualquiera, que tiene sus propios concursos y todo.

Para las empresas es una práctica útil para complicar a la competencia el entendimiento del código decompilado (aunque sea ilegal decompilarlo). Pero como es complicado hacer grandes programas de esta forma, existen multitud de herramientas que lo hacen por nosotros. Para Java he encontrado este listado en la página del ProGuard.

Sin embargo, en ocasiones uno se encuentra con un programa doblemente ofuscado… porque está ofuscado por pura ilegibilidad. Imaginad el siguiente trozo de código y comprenderéis…

FileOutputSream ff = new FileOutputStream (
  String.valueOf (
    String.valueOf (
      (
        new StringBuffer (
          String.valueOf (
            String.valueOf (
              new File (
                String.valueOf (
                  String.valueOf (
                    (
                      new StringBuffer (
                        String.valueOf (
                          String.valueOf (
                            System.getProperty (
                              "java.home"
                            )
                          )
                        )
                      )
                    ).append (
                      System.getProperty (
                        "file.separator"
                      )
                    ).append (
                      "empresa"
                    )
                  )
                )
              )
            )
          )
        )
      ).append (
        System.getProperty (
          "file.separator"
        )
      ).append (
        "adm.conf"
      )
    )
  )
);

Es un trozo de código de un programa real y tenéis la suerte de que os lo he ordenado un poco, porque estaba en 4 líneas tan solo…

Aunque llego una semana tarde, tampoco pasa nada por animaros a ir a la segunda semana de las charlas del GUL de la UC3M.

Estas charlas tratan sobre el software libre, Linux, programación e informática en general, vamos que cubren un amplio abanico de temas, seguramente haya alguno que te guste. La entrada es gratuita y libre, es decir, puedes ir sin necesidad de registrarse en ningún sitio y sin pagar ni un euro, la dan miembros del grupo que tienen un nivel muy bueno de lo que hablan.

Aquí tenéis el calendario con las charlas, para que sepáis ir os dejo un enlace de google maps de la ubicación de la universidad.

Después de la pequeña discusión en el post sobre la mutabilidad de las clases en Java, me propongo aclarar un poco el dilema y las dudas sobre lo qué realmente ocurre al pasar parámetros por referencia o por valor.

La definición de un parámetro por referencia nos dice que es aquel parámetro cuyo valor se puede modificar dentro de la función y se propagará a la variable que se paso como parámetro fuera de la función, es decir, nuestra variable podrá cambiar de valor una vez ejecutada la función.

En cambio, la definición de un parámetro por valor nos dice que es aquel parámetro cuyo valor cuyo valor se puede modificar dentro de la función, pero que no se propagará a la variable que se paso como parámetro fuera de la función, es decir, nuestra variable nunca podrá cambiar de valor una vez ejecutada la función.

Normalmente (por lo menos con los lenguajes de programación que yo he tratado) lo que se hace es que en los parámetros por referencia se pasa la dirección de la variable usándose ésta dentro de la función, y en los parámetros por valor se crea una copia de la variable que se usará dentro de la función.

Leer el resto »