PHP Frameworks Code Complexity Comparison

Yeah, I've had this same complaint trying to get through it. Digging through Laravel internals can be rough.

Here's a small example where things are pretty segregated:

https://github.com/illuminate/support/blob/master/Traits/Cap...

https://github.com/illuminate/queue/blob/master/Capsule/Mana...

And then the queue capsule manager is not to be confused with the database capsule manager:

https://github.com/laravel/framework/blob/master/src/Illumin...

When you're looking through a bunch of things similar to that, it can be a bit confusing to take it all in and remember what is what.

Laravel is actually relatively simple, compared to Symfony "framework edition" where everything is compiled and cached into something else.You'd a dynamic language wouldn't need YAML or XML files for configuration like Struts or Spring... But the truth is that PHP isn't declarative enough to make it unnecessary. In fact Java is more declarative than PHP.

The other problem with anything built with Symfony components is that Symfony components never come with good defaults, they are a pain in the ass to instantiate manually, with huge object graphs because "decoupling". That's shouldn't be the case, one shouldn't have to create 15+ objects just to use a form factory for instance. Even Doctrine which is much more complicated than Symfony comes with acceptable defaults. Arrays/Maps of options passed as arguments of class constructors is a blatant demonstration that something is broken.

Agree entirely, it's one of the few 'real' complaints I have about Laravel, my other is that while the documentation is beautiful it's very terse and often lacks examples (a while back in the 4 days I sent a PR to add examples in a bunch of areas and they where all denied because he wants to keep the docs short, Symfony handles this better, they have multiple docsets with different scopes).

Why is the longest method size 13 lines? That to me is an indication that functions are actually not doing enough themselves, and rely heavily on delegation to other functions (e.g. far too many functions are simply a few lines consisting of calls to other functions, possibly far-removed from the context, with little or no logic "built-in" to the function itself). Usually when I see that sort of thing it's because the functions were designed for unit-testability instead of utility in a programming project.

In the case of Laravel vs Symphony, I think it can. Laravel packs absolutely everything you need to build a web app while still being less than half the size of Symphony, which has a lot less out of the box and expects a litany of third party packages to become functional.

From time to time, I need to understand what is going on under the hood of a framework to debug a problem or understand the best way to do things.

I find Laravel easy to understand when browsing code because of the short methods.

There are tradeoffs, of course, as sometimes it can take several hops through the code to trace down some functionality. But I prefer more short methods vs. one long method any day for readability.

> "Complexity": Cyclomatic complexity is a near-worthless metric, especially in a language like PHP. It's easy to convert a series of 10 if statements into one while loop by leveraging call_user_func and deterministic method names. The resulting while statement is infinitely more complex than the if statements and reduces the benefits of using an IDE. So unless your CC algorithm treats this kind of programming as wildly complex, then it's not giving you a true complexity value (in fact, it's actually lying to you).

Just because you have a way of cheating it, doesn't make it worthless.

I agree that cyclomatic complexity is good, but it's not enough on it's own, that's why you have other metrics, rules and manual reviews.

TBH not sure how they got that count.

https://github.com/illuminate/queue/blob/master/Worker.php#L... Here's 17 LOC in the first file I checked.

Not to say that's excessive or a bad thing, just seems the count isn't quite accurate.

If they aren't counting Illuminate components, seems somewhat unfaithful, since that's really the Laravel nitty-gritty.

It's also worth noting that 'static' doesn't feel like a good metric in PHP. There's certainly not a great correlation of static to pure when you're in global-DI-container contexts. So why do we want statics? Global static singletons, too, don't feel like a particularly good pattern.

If I'm writing PHP, I -do- try to make 'static' mean 'this function accesses no globals and has no side effects', because in my opinion it can make PHP a bit cleaner, but in most PHP frameworks that's not the pattern they're going for.

In that context, the more statics the better!

Side note: The queue-related bits of Illuminate were pretty difficult to decompose and work with outside of laravel context, though that's partly because PHP is a kind of unfortunate language for worker processes in general because of how the opcache works together with a kludged CLI.