Earlier today I thought, "Hey, it'd be neat to list the number of posts in each category." It's not exactly rocket science. The categories are listed by some function called
list_cats
, and it takes a parameter for just such an occassion. It's called optioncount
because it controls the option of whether or not to list the post counts for each category. It defaults to FALSE
, or in other words "don't show the counts." Hey, I told you it's not rocket science.So I have just to send the function
TRUE
in that parameter instead of the default FALSE
. Now here comes the whacky part. I now have to specify all the parameters of list_cats
up to and including this one--even though I don't want to change any of the others. So the code must read:list_cats(FALSE,'All','name','asc','index.php',TRUE,FALSE,TRUE)
There's only one other parameter in there that's not taking the default value. That's the one
'name'
which says to sort by category name (it defaults to category ID--why!). So with named parameters, it could look as simple as:list_cats($sort_column => 'name', $optioncount => TRUE)
Now I must ask you the reader a few questions. Which one is more readable? It's certainly not clear what all the parameters in the first one do. Furthermore, which ones are important? For example, which ones differ from the defaults? Which ones are there because the author intended them to be set, and which are just there because the language is braindead?
While we are at it, which line is more maintainable? If you write this and come back to it five years later, or even two days later, you'll have to scour the documentation to figure out what all the parameters of the first line do. You can make an educated guess (and probably be right!) for the second version. (Maybe PHP developers are envious of Perl developers for being able to create morasses of unmaintainable, illegible code! Just a theory.)
This shortcoming is nothing new. I used to use PHP all over the place. So when I encountered this flaw again, I thought, "Hey, maybe they fixed that in the latest version!" So I googled. Unsurprisingly, I found this guy Adam who thought named parameters would make his life easier. I'm sure there are many such people out there though. He had a nice link though... Apparently the PHP people did think about adding named parameters pretty recently. Laughably, they did not. The link gives three reasons:
- There is no real need.
- It's not simple enough.
- It makes code messier.
Now, certainly in my example, and in Adam's, it makes code simpler and easier to follow. What's more, it leads to maintainable code. You could actually read some lines without having to continually return to the manual or documentation. You can imagine how difficult it must be to actually figure out what's going on in a reasonably-sized PHP script. So really, that only leaves their first one: there is no real need.
I suppose. Other languages respect developer time. They try to help one make simple, legible, maintainable code. Ruby and Python stand out. Even Perl has named parameters. So in the sense that one can just use a decent language, I agree.
(If this seems like a bit of a rant, I suppose it is. I just see no reason to purposely thwart developers--even if they do use PHP. Given the option, the PHP language gods could add named parameters. It'd lead to better code, and save time for everyone. But they choose not to... WHY?)