When you realize the legacy PHP code you're working in has a class you're extending with over 2000 lines and you think, "Nope, this isn't a class, it's a university."

Not sure if it's the worst code review but it's a recent one.

We don't really do code reviews where I work unfortunately but my coworker used my framework for the first time (build some nice composer libraries for cmdline projects) and asked if I could make them do autoloading.
He never used namespaces before so I was glad to help him out.

What I saw was a dreadful mess. His project was called "scripts" so good luck picking a namespace...

Than it was all lose functions in the executable file. All those functions are however called by a class in another file (if they where not calling eachother as a cascading mess). That class was extending an abstract class from my library as instructed. However I never imagined my lib being raped like that.

The functions themselves are a horrible mess. Nothing uniform completely different style (our documentation states PSR's should be used).
Parameters counts higher than 5.
Variable names like Object and Dobject (in calling function Dobject is Object but it needs a fresh one.

If statements on parameters that need basically split it in two (should simply be to functions)
If else statement with return of same variable as a single line (sane people use ternary for that)

Note that I said functions. All of it should have been OO and methods. Would have saved at least some of the parameter hell.

I could go on and on. Do I think the programmer is bad yes (does not even grasp interfaces, dep injection, foreach loops). Is this his best work no. He said that for a one of script like this it just has to work. Not going to be used elsewhere. I disagree as it is a few thousand lines of code that others have to read too.

TFW the mock class has way more code than the real one.
Testing big infrastructures can be a pain...
Or maybe my team is just not so good at it.

My time spent:
Adding new feature to the real class 15%
Extending the mock with the same feature 55%
Writing tests 30%

Lets take onlyfans system for example. They have fans and creators. How is database models supposed to be structured? Whats the correct way.

1) a User model that contains all users of all roles, but differentiates them by Role ENUM

2) a separate Fan and Creator model, each having their own unique attributes, while each extending an abstract base User model class that has all the common attributes that both models should use

The 1st approach is simple but gets very large and difficult to maintain and view all the attributes cluttered in 1 class. Not to mention how some attributes will never be used for a user who registered as a Fan.

2nd approach is more modular and easier to understand and maintain by knowing exactly what attributes to put for each model. However problems occurs when you try to join tables and stuff start to become overengineered

// new Rant("help")

I am currently writing my first 'real' Ruby project. I want people to be able to contribute through a module class by extending it and implementing the needed methods. This can (if done correctly) provide new commands for the terminal and new features.

But is this a good idea? I would download the code then by using git and keep it that way updated (similar brew does). At the start of the terminal app I would add all files recursively from the folder where I clone the modules into and lookup each class that extends module and then load the new content.

Is there another way of creating such a 'modular' application in Ruby?

They way I load the modules is through the inherited method, I just add the classes (not a concrete object created with new) to a list and retrieve it at runtime.

Would be nice to get some feedback going on here, not sure if my idea is good/bad.

Am I the only one having a really hard time grasping code when it involves more than just a few classes devided into several files?! I simply can't follow what happens when method a in class b instantiates class c and d while implementing interface e injection dependency f and extending class g...!?

Does this make sense?

Nintendo seems to use familiar naming conventions like in programming.😅

In a Phaser game, I was unknowingly overriding a method of a parent class. It must've been Phaser.Group or Phaser.Sprite that my class was extending, I was calling destroy() on it without realising I was calling the parent class' method too and was baffled about why shit wasn't working. Found out maybe two days later and changed the method 'destroy()' in my class to 'pokeItWithAStick()'. This was at a previous job, but I'm mostly sure that it stays that way in the codebase three years later.

TLDR: Wrote a custom class for writing apibtest cases for a project with zero code test coverage.

We have a project with zero test coverage. Recently, i was tasked with writing api test cases for said project, it might have taken me months to write tests for all endpoint, plus the main issue was that each endpoint needed to tested for all available user roles and permissions.

I tried the main stream approach of writing api tests, but ended up running into a lot of issues directly linked to our projects roles/permissions architecture (cherry on top some endpoint are apikey specific). Don't get me wrong in my opinion this is by far one of the best user roles architecture out there, but writing test cases keeping it in mind is pain in ***.

After trying out different testing methods and frameworks, i decided to write my own class by extending django test framework (which uses unitest)

- It has generator and validators for request and response.
- Supports testing for user roles and permissions.
- We won't have to make any changes to code after user role or permissions changes
- I just have to copy and past request and responses from postman api collection.😂