Smart hack about using a space after the function name (before the next bracket)

    As you know, in the use of a space after a function name (before the next bracket) there are two ways in all those languages ​​in which there are brackets after the function name (for example, in C, in C ++, in PHP, in JavaScript ...).

    The first way is to refrain from such use. The second way, on the contrary, is to steadily put a space after the function name and before the next bracket.

    Guided by considerations of saving space, most authors of coding styles and standards come to the idea of ​​the correctness of the first of these ways. You can verify this using the PHP coding standards as an example : PEAR ([ 1 ], [ 2 ]), Zend , Symfony ,CakePHP , DB Medialab , evolt.org , GForge , as well as nIx0iD 's own standard - all, all of them recommend by their example to refrain from space.

    However, relatively recently, I saw on the Internet (either on Habrahabr or on another similar site) a third way sermon: put a space after the function name (and before the next bracket) only in the definition of this function, but do not put a spacewhen calling a function. The author of this recipe guessed (and quite rightly) that following this third path opens up the possibility for the programmer to type in the search the string FunctionName ( with a space in order to immediately find the definition of the function in the source code without wading through the thickets and jungle of its calls.

    Over time, I came to the conclusion that such a smart hack will always be useful whenever the IDE is not at hand, but there is a simple text search - or when the IDE is not smart enough for her to be able to look for exactly the definition of the desired function. An empty space allows the programmer to achieve what he wants without being selected.

    Alas, I came to this conclusion too late. When I saw this recipe for the first time, I allowed the question “How many gaps to fill up ?!” to emerge from the lazy depths of the subconscious, an issue that seemed to me rather rhetorical and prohibitive. Since then, I have ripened to see for myself that this recipe actually saves a lot more time when searching than it would take time to put spaces in the function headers; which means that saving on these gaps is no less a false saving than saving on comments or than bukasoid documentation (from the English “bukazoid documentation pattern”; in my translation, if you like - “buddany documentation”, according to Scherba's phrase “ glitch cousinsteko budlanula bokra ... "). The problem is that while I was convinced of this, I completely forgot the author and the source of the recipe.

    Reader! didn’t you come across it?

    Also popular now: