Un cuestionable legado de C / C++

Muchos lenguajes diferencian los conceptos de procedimiento y función, pero los creadores de C decidieron unificarlos, supongo que en un intento de simplificación, llamándolos indistintamente funciones. El procedimiento pasó a ser una función que no retorna ningún resultado (o lo que es lo mismo, con tipo de retorno void). La unificación va más allá, en tanto que C permite invocar cualquier función como si no retornara un resultado. Es decir, cuando sólo interesa lo que la función hace y no lo que retorna, se invoca a la función como procedimiento y el resultado es descartado automáticamente. Quien haya intentado esto con otros lenguajes, como BASIC, se habrá visto obligado a guardar explícitamente un resultado irrelevante, y probablemente considere feliz la iniciativa de C.

C++ mantuvo el criterio de C, aunque empezamos a hablar de funciones miembro, o métodos. Más tarde llegaron Java y C#, donde seguimos hablando de métodos. Todos reconocemos que detrás del concepto de método subyacen los de procedimiento y función, pero es como si nos hubiésemos puesto de acuerdo en mantener medio difusa esa distinción.

Idealmente, a una función hay que llamarla por el resultado que arroja y no por lo que hace. La llamada a una función debe poder ocupar el lugar de un valor, una función es un valor. Por otro lado, a los procedimientos se los llama por lo que hacen. La propuesta es: escribir métodos que son claramente una cosa o la otra, manteniendo los efectos colaterales bajo control.