Sorry it took me so long to answer … 💬

🚭  Ceci n’est pas une fonction

Regarding your question about die, I regret to note that you’ve (knowingly — or otherwise?) picked a pessimal example for use with this particular question. So I’ll first briefly answer the question you asked, and then at greater elaboration I’ll answer the question I shall assume you actually meant. 😜

The reason that die is neither a function call nor a subroutine, method, procedure, or anything else of that ilk is because of what subroutines at their machine‐level foundation really are. When you factor out matters of register allocation and arugment transmission, they all of then do one key thing: they push on the (per‐thread, per‐intepreter) sᴘ the address of the next ᴘᴄ to be executed after the intended subroutine call eventually returns.

This would work a bit like -(SP) = PC; PC = FUNCNAME. Then at the end of the “call”, the subprogram pops the return address off the stack and hies itself thither with PC = (SP)+. There exist simpler solutions involving fancier instructions like JSR and RTS, but you must get the central idea here. And die just doesn’t work that way — at all. Functions that return fewer times than they’re called, and in some cases, even return more times than they’re called, are sneaky little buggers that strain any reasonable definition of what a function call really is.

Other functions that break the function model outlined above and therefore give call‐graph analysis programs serious conniptions include not just exit but even moreso longjmp and setjmp. That’s because setjmp returns more times than it’s called (as so too can open!), while longjump, like exit and die, never bothers to return at all.

Interesting though all that may be, I suspect that wasn’t what you were really asking. I recognize that I may be wrong, though, and so it is just barely conceivable that you really were asking the subtler question, not the simpler one.

👾  Begone all yᵉ hobgoblins of little minds!

Even though code I’ve written ever since v1.0 of Perl for the most part looks pretty much as it always has, my own coding practices have changed a little over the years. I like to think they’ve converged on a degree of stylistic consistency that facilitates not just the reading of my code, but also its predictability.

Yes, that does mean that today’s code does not always quite match up exactly with yesteryear’s in all possible regards, so please do not go digging up prehistoric Perl code of mine to tout as though it were someone an examplar of cavalier inconsistency. It wouldn’t be. More importantly, it just doesn’t bear discussing.

🐪  Predictable parsing of argument lists

Nevertheless, I believe that if you examine any of my recent code, such as the many examples found in my Unicode Tool Chest, you will quickly see a clear and consistent style used not religiously, but consistently in all of that code.

In fact, I would even go so far as to say that if ever you find exceptions to larger stylistic patterns in that code, you have either discovered a more specific rule than the general rule you had believed you had been previously operating under, or as is more likely, you have discovered a style bug that I myself would prefer to see updated for consistency’s sake.

🐪   paren() || !paren

I use parentheses much more consistently and rigorously now than I ever used to. This is closer to Damian’s style and further from Larry’s. I even use them on function calls of no arguments, although I confess to some vascillation with method calls of the corresonding signature.

I am not fond of using parentheses for functions and methods whose dative (or ablative (or instrumental)) slot is occupied, because the result looks disconcertingly Lispish. That means I avoid parens for things like print, printf, map, grep, and sort — just to name a few. Additionally and for precisely the same reason (although somewhat moderated by pipelined, left‐to‐right listop stacking and on certain perlocentric syntactosemantic exceptions discussed below), I also tend to avoid parentheses on methods‐qua‐listops.

I recognize this runs somewhat counter to the bashfulᵃʰᵉᵐConventional Wisdom that spooks up an intensely aversive reaction in many novice Perl programmers who just don’t know any better. But since I actually do know where their peculiar ambiguities lurk in stealthful ambuscade, I simply do not write them in an ambiguous fashion, and the payoff is improved readability. It really is a nonissue for me, and I have never once been gotchaed as so many others report having befallen them.

It is also a tiny niche in one little corner of the language, one which for me does not even arise with any great frequency. Given that, it generates a level of controversy I feel wholly unreasonable and disproportionately larger than it has any business doing. This is itself distressing. Why do that? Let’s not and say we didn’t. Just let it go, ok please?

⚠ Where parens really do matter, and why

One place not to “let go” is when the precence or absence of parentheses meaningfully changes something other than precedence. Just off the top of my head, these are

1. eof vs eof() — the first is for all of <ARGV>; the second just on the last file read from, so can occur multiple times in an <ARGV> sequence
2. Whether to include empty parens ( ) on a use statement — if you do include them, no ->import() is invoked, (all but) guaranteeing that your caller’s namespace won’t be polluted with unasked‐for imports. If you don’t include them nor any other import list, then the module is free to plaster your namespace with whatever aliases it pleases, and may even change this list from one revision to the next, thus changing your code’s syntax (protototypes) and semantics (what gets called). Very bad idea.

👀  My eye→brain processor craves parens

I know that many others, including even Larry, are different from me. I wrote 100,000 lines of C code before I even started grad school. Larry, on the other hand, seems to have been tortured by a Lisp interpreter as a small child. We each have our own unique cross to bear. We should be a lot more forgiving of people who were victims of (programming) abuse and torture than as a community I feel we for the most part often are.

For me, the parens are needed to tell my brain where the argument list stops. A semicolon or a close round/square/curly bracket will all do this. But if you expect the argument list to stop for any other reason, I get nervous. I am far too aware of the ways that prototypes change the parse to trust any funny business there. I do not like trailing English words changing the parse, either, since the function likely started as a leading English word. That’s why I’ll write:

pod2usage(0)                                 if $Opt{help};
pod2usage(-exitstatus => 0, -verbose => 2)  if $Opt{man};

@ARGV = (1) unless @ARGV;

pod2usage("$0: missing arguments")           if @ARGV == 0;
[download]

As in the point that you yourself have raied, there are times I relax that, and indeed it’s usually on things like print or die. As should be immmediately obvious from the code fragment cited above, one thing that’s especially important to me is interlineal vertical alignment. That isn’t quite properly stated, but the idea is that if the code that looks the same should be in the same column despite being on different lines so that the eye can quickly pick out the parts that are different. We’re very good at that as humans.

---

🐪  Exemplary Code  🐪

My basic principle is that only if there are no other operators or function calls to the right, then I may sometimes elide the parens; otherwise they go in, every time. One‐shot command‐line work may be different, because I’m as lazy a typist as the next, but that’s different. Look at my code to see what I mean.

That’s just one of the many reasons I always use the more readable form of the vexing Logical-ᴏʀ, although there are other reasons for that, too. Please note very very carefully, that even without the alternate, hard‐to‐parse newfangled construct anywhere to be seen or unseen, my own code — mirabile visu! — is simultaneously safe, clear, and unconfusing. “They” tell this can’t be done, but “there” are demonstrably wrong, considering how I never, never, never make the pernicious and pervasive operator precedence errors that seem to plague most Perl programmers, especially those who put too much stock into contemptible mindless cargo‐cult pseudo‐rules instead of in actual thought.

Do things for reasons other than because you were told to: learn the whys and wherefores, not the rules. But if there is one rule to follow without giving it further thought, please make it this one:

---

Please, please, please think of those who’ll come after you — preferably before they do so — and use parentheses to delimit the arguments to your functions calls.