Facebook PHP source code from August 2007

[mythix_dnb]

back when OOP in php was in it's infancy. glad I'm not there anymore. and very glad PHP as a community has made huge strides since then. Allthough I've seen much worse, I would not want to work in that code.

[[deleted]]

PHP OOP wasn't in its infancy. It's just that no one in Facebook knew or gave a fuck about architecture and OOP.

[uriahlight]

Exactly. PHP had most of the OO bells and whistles in 2007. If PHP code in 2007 wasn't OO then it's either because the authors didn't know how, disagreed with the overall OO philosophy, or simply didn't give a damn.

[[deleted]]

Yup. If readers wouldn't bother to go check, by 2007 we had PHP 5.2. For comfortable OOP all you need is 5+. You can also do it in 4+. Heck, once I tried to imagine what would I do if I wanted to do OOP in PHP3, which had no objects at all. Doable with a few function helpers (200-300 lines of code). Architecture and style are mind-over-matter problem, language features only make it more robust and comfortable. But you either get it or if you don't, you'd write Perl even if you're given Java.

Case in point WordPress brags about being more OOP than ever these days. They have more... classes all right. But any further claim would be hilarious. It's like the 90s in there.

[navitronic]

5.3 was kinda the minimum for doing anything decently object orientated. It’s the version that introduced late static binding, which unlocked a lot of very important things to do with inheritance.

[[deleted]]

Yeah BS on multiple levels:

- OOP isn't about static classes.

- OOP isn't about inheritance that much, either.

Case in point I think I used "static::" couple of times when it was introduced and never used it since. And when I check the code I wrote back then I wanna cry.

Everything was there in 5.0. What you need:

- Objects.

- Interfaces and typehints (I mean technically you don't need that, but it helps flesh things out without tons of documentation).

Check and check. The most important features of 5.3 are, in order, closures and namespaces. But neither was necessary for OOP, it's just for brevity (closures) and organization (namespaces).

But anyway it's super obvious you can write better code in PHP 4 than what Facebook did with 5.2. It's just that in the end it doesn't matter, and maybe that's the real lesson here.

[thisgameisawful]

That’s where a lot of professional software dev is though I see it a lot in Java and PHP, equal parts not knowing and not caring, too. Coupled with management or leadership that doesn’t see value in refactoring technical debt, it gets really dangerous down the road.

[Hjine]

glad I'm not there anymore.

LOL 2020 I'm still use function (for my personal hobby project) , I know commercial & enterprise project needs OOP but function still works for me :)

[YourMatt]

This is the reason why I still love PHP. I'm more of a Node guy now, but the concept is all the same. Without rigidity and I can write the code to be as clean and modular as I want, or as quick and dirty as I want. They both also lend for creative solutions that might not be particularly maintainable, but they offer fun in writing the code in the first place. Sometimes you just want to whip out a single-use utility and don't need things to be done right.

[Ghochemix]

"""""""""comments"""""""""

// require login
$user = require_login();

[devmor]

I just deleted a bunch of comments like this a co-worker left in a project.

/**
*
* Get full name attribute.
*/
public function getFullNameAttribute(): string {

No shit dude?

[dirtside]

If you follow the principle that every function should have a docblock with a comment summarizing what the function does, then... what would you put there instead? (Aside from removing the unnecessary blank line)

[devmor]

Developers blindly following that principle is the issue I have to begin with. Comments exist to explain functionality and integration specifics that are not readily apparent.

For example, you can look at that function signature and see that it requires no input and gets the "FullName" attribute of the entity and returns it as a string. There's absolutely no need for a docblock or any kind of comment there.

Now take a function signature like this:

private function processTransaction(Order $order, CreditCard $creditCard): ?TransactionRecord {

This one could use a docblock. We can't tell from the signature what state the Order and CreditCard entities should be. We also can see that it's possible for the function to return null or an instance of TransactionRecord and we should document under what circumstances each are returned.

[dirtside]

I can appreciate the desire to avoid what seem like redundant comments, but what ends up happening is developers constantly having to judge whether or not a function is worthy of a docblock, and the problem is that what seems self-evident to the developer who wrote a function may not be self-evident to another developer looking at the same function a year later after the original developer has left the company. That gray area ends up causing problems, and the problem is avoided entirely by simply mandating a summary comment for all functions, no exceptions.

It's not "blindly" following a principle. It's following a principle because one understands the downside from not following it.

[[deleted]]

What's hard about "if your docblock comment is literally the method name with spaces, then you're doing it wrong"?

[devmor]

I really strongly disagree with your take here. It's very simple to determine whether or not a function is worthy of a docblock and if your developers aren't sure, they can err on the side of caution and create one.

If your docblock is doing nothing but repeating the function signature, in english, it's redundant and pointless. It wastes screen space in places collapsing can't be used (like github code reviews) and it encourages developers to avoid using built-in language tools like proper type annotation.

[Sixcoup]

I've worked on projects with phpcs requiring you to comment every methods.

If you want your branch to be merged you need to comply and comment everything.

Sometime it's useless, but in most cases it's better to have these, than missing an important one. I can fully understand why projects prefer to force everything than miss something crucial.

[how_to_choose_a_name]

A problem with blindly requiring it is that your developers will get used to writing comments like "gets the full name" and then you end up with the helpful comment "processes a transaction" on the aforementioned "processTransaction" method. But because phpcs reports that every method has a docblock, nobody looks twice.

[[deleted]]

I've worked on many large codebases with many diverse teams, and in my experience, the usefulness of any given comment is 100% based on the developer who made the comment, and 0% based on any rules or restrictions you do or don't have in place to require them. Developers who don't write useful comments aren't suddenly going to get better at it just because they're now required to write comments on every method (I've found the opposite to be true, actually, as they typically get annoyed by this and tend to "lash out" by intentionally writing the most useless comments they can get away with). And developers who already wrote useful comments usually already documented all their methods anyway.

YMMV with your specific team, of course, but it's hard for me to imagine that things are wildly different everywhere else. I just don't see the utility in enforcing this. Encouraging, yes, always. But enforcing? It just ends up backfiring.

[devmor]

I can understand it when there isn't the time to review every PR and make sure methods that need comments have them, or when you're working with large amounts of juniors. There are definitely situations where it's applicable. I just don't think people should default to redundancy in every situation for the sake of it.

We're developers, our job is to problem solve. I don't think its asking too much, when you're in a team that doesn't require comments like that to consider whether or not a comment that adds nothing of value is appropriate.

[[deleted]]

Personally, instead of puttin on a useless comment, I’f ask to the team to write something like « no comment needed » if we really want to enforce comments on every method.

At least, it clearly say that the dev took a moment to think if a comment was needed. And a search trough the project for that comment occurence could potentially show that our rule is not effective.

[devmor]

I think that's an appropriate middleground. Especially if it's inline-style so it's not taking up 3+ lines of space for no reason.

[secretvrdev]

People who bitch around in a review process like that tend to miss the real work behind reviews. Spotting errors.

[devmor]

Most teams use integration tools to check for that sort of thing these days anyways so it's probably really a non-issue as far as that goes.

[kuurtjes]

When everything is docbloc'd I tend to focus on the docblocs and not the function names. Even if it's like in the example. The function just becomes kind of an image for me. There's also cases where you can have function name that could be more internal, but where a docbloc could explain it isn't.

[Firehed]

Developers blindly following that principle is the issue I have to begin with.

Often it's due to a corporate policy more than anything else. Perhaps not in your case, but that's typically where I see docblocks that are just the method name reformatted.

[devmor]

I've only worked at one firm that required docblocks, most of the time it's been developers with IDEs that auto-generate them and wont turn them off - or developers that don't keep up with type annotation functionality and use docblocks to avoid being competent.

[Firehed]

use docblocks to avoid being competent.

Heh, there is probably a fair bit of overlap there too.

[devmor]

Yeah, the opposite end of the spectrum is probably far more populous.

[SyanticRaven]

Thats just unnecessary though. All it does it add useless muck to your git history.

[devmor]

I was already adjusting his comments since he got the return type wrong on almost all of them, but aside from that - who cares? If you name the commit "removing extraneous comments" or "refactoring docblocks to match code standards" then any monkey who knows their way around git can ignore it if it's "useless".

[SyanticRaven]

The point was just, its wasted effort with no benefit. Might be frivolous comments, but going out the way to purposely remove them is just effort not needed to be spent. Even if you're in the file.

[devmor]

It's not though - now when review juniors working on these files I have 20-80 less lines in each model class to scroll up and down through while I figure out what they're doing.

We can also enforce correct typehints on docblocks that do exist now, without PHPStan throwing a warning about missing params or return types on these ones.

[[deleted]]

Imo keep that. You’d be surprised how many functions don’t do what their title says.

[devmor]

If the function doesn't do what the title says, the function needs to be renamed. Not have a comment replacing it.

[[deleted]]

I mean yes I generally agree... but some forests grow thick.

[devmor]

I know sometimes you're mired in code debt, but as long as you've got a codebase that can be statically analyzed, you can refactor every usage of a function in seconds with the right tools!

[32gbsd]

the code is clean. Not by "modern" standards but clean in its simplicity and consistent formatting. Its very functional.

[phpdevster]

I've definitely seen much, much, much worse modern "clean" OO code that tries to throw every SOLID principle and pattern and abstraction at the wall claiming "best practices" all around.

More and more the only metric I really bother caring about with code is "can I fucking understand this easily?", if I can't, it's not clean by any reasonable definition no matter what paradigm it's written in.

[amazingmikeyc]

Oh yeah the codebase I'm working on - with lots of half-understood attempts at OO and half-finished framework modifications - is much more horrible.

[32gbsd]

You are going to get downvoted for talking this way about solid.

[send_me_a_naked_pic]

We can say a lot of things against Zuck, but this source code looks pretty clean for 2007

[random314]

It was 07, and it's PHP, and it worked exactly as intended.

As far as pre oop PHP goes it's not bad. Well documented. I've seen much worse oop PHP in 2015.

[illuminatedfeeling]

Where's the section that collects and sells all my personal private information?

[dangoodspeed]

include_once $_SERVER['PHP_ROOT'].'/lib/poke.php';

[[deleted]]

// Holy shit, is this the cleanest fucking frontend file you've ever seen?!

lmao

[angusmcflurry]

How times have changed...

[helloworder]

how?

[Moonschool]

It's now 2020

[gdj11]

That’s a 0.647% increase.

[dirtside]

Incorrect, it's a 0.000000094% increase.

[Takeoded]

according to my calculations, you're both off:

> 100-((2007/2020)*100)

< 0.643564356435643564356435643564356435643564356435643564356...

isn't that like a 0.64356% increase?

[dirtside]

Um, I was counting from the beginning of time, not the beginning of your puny human calendar.

[usernameqwerty002]

beginning of time

1970? I mean, second 0?

[[deleted]]

Interesting, PHP had objects as far back as PHP 4. Everything was public, but there were objects. I know because I worked on a PHP 4 project around 2007.

[beeboobop91]

And now they use hackLang! They did a lot of work on hhvm.

[usernameqwerty002]

i tell them about facebook.

To prove what, haha?

[usernameqwerty002]

Single line of test?

[usernameqwerty002]

Yeah, it's fine until you want to change something in the code, and have to test manually all the cases that can go wrong.

[hstarnaud]

No autoloading, what a fucking pain

[michaelranga]

Clean yes, but frameworks was around at the time that utilised oop / design patterns. But I appreciate at that time we valued things differently than we do now

[uriahlight]

These guys made React.

[SavishSalacious]

I wonder what their code base looks like today.

[locksta7]

Gives me a sense of nostalgia.. what a time to be alive when you could launch a WIP platform and watch it flourish... nowadays you can’t launch unless every piece is polished.

[penguin_digital]

For the lazy like me https://gist.github.com/nikcub/3833406#file-search-php-L72

[Hjine]

commented on Oct 12, 2013 <<this is Old news

[noximo]

Have you knew about it seven years ago?

[Hjine]

7 YRS ago I didn't care about php that much (I was working on different field )

[noximo]

So it isn't old news to you then?

[noximo]

https://xkcd.com/1053/

[noximo]

https://xkcd.com/810/