- Classes are used to stuff functions in for organizational purposes and called statically throughout the application.
This creates a hard dependency on the class name itself, and eliminates any possibility of extension without modifying the code of class file itself, which is a huge no-no because it can have adverse consequences on the rest of your codebase that relies on it.
Never use static method calls. The only valid use for static method calls is for singletons and (maybe) a registry. The reason is because they are extremely inflexible and create hard dependencies on the class name itself.
- New objects are instantiated within functions of other objects instead of being passed into the function or object constructor upon instantiation.
This creates hidden dependencies where objects you try to use out of the context of the larger application are dependent on several other objects and static classes you have to take along with you. Then those objects have hidden dependencies on others, etc. and the cycle continues until you end up just copying or referencing the entire code library to your new project.
- There are no interfaces to enforce what controller or model methods are required for the section to function properly.
People new to the project get extremely confused and irritated when something isn't working right and there is no code enforcement to help them figure it out - just weird and obscure errors that appear when you don't do things right.
- Class hierarchies more than 5 levels deep in many cases.
This is a huge point of contention between me and some of the other developers that setup the codebase. Essentially, every time a new section is created, they make an "Abstract" controller or model for that section that everything in that section will extend from (and I put it in quotes because the class is never actually defined as abstract in php). That new abstract class of course extends the subsection abstract class, which in turn extends the type abstract class, which extends the base abstract class for that type, which extends the base class. And no, I'm not kidding. Code re-use doesn't equal moving it down to a lower layer and creating more layers of abstraction.
This makes it extremely frustrating to troubleshoot bugs and other issues when you have to trace the problem back 5 classes deep, and then can't change it because everything else extends from it, so you have to copy and paste(!) the whole function (sometimes without calling the parent) and make your modification in your concrete class for it to work. It's our built-in bug generation suite.
There is so much more, but I don't really have time to continue. It's almost as if the original authors of the codebase read How to Write 3v1L, Untestable Code, thought it was serious instead of tongue-in-cheek, and followed every "suggestion" perfectly. A recipe for disaster.
Stackbox CMS - Full edit-on-page drag-and-drop CMS
Autoridge - Vehicle information & maintenance part numbers
On closed projects TDD removes the need for comments as assertion messages are used instead, unlike comments when the functionality changes they shout that it has changed and either the code needs to be fixed or the assertion ammended to reflect the change. It is semi forgivable to not update comments as they lack conciseness, vary on quality and appearance due to the writers belief on what is an important comment so end up being ignored. The more internal comments written the less value the real needed comments have( usually ones due to code that has to circumvent behavioural anomolies so looks wrong but should not be carelessley refactored). Quantity of internal comments due to a general need can be a sign that the code is obscure and needs reworking.
TDD can also become a crutch for bad naming and implementation by the writer if they prioritise writing the test over those who will come back and read the test and code. Too much thought is directed in the wrong area, usually to get the test over and done with to get to the code. The test works but it is big and ugly, sometimes magnifying the over complicatedness of the code and sometimes just because of too much copy and paste. I don't know why sensibilities can change when it comes to tests or views but it seems to in some, readability goes out the window.
Bad code( code that has distinctive code smells ) I do not trust without reading closely so I definitely do not trust it's comments, both rely on the ability of organising thoughts. Weakness in one implies weakness in the other. Writing comments for other people is no different than writing code for other people. The code is just the harder way.
Comments on public interfaces are okay as when calling them IDE's display them( parameters, catachable exceptions and return types are very handy). It removes the need to enter the code and forcing someone to enter code and understand impleementation they do not need to is wasting their time and distracting them from their current task. In open projects this is more important as the users probably have very little instinctive ability with the code base until they become heavy users and have got to grips with it's coding conventions.
Writing bad code with comments is far easier than writing good code without. What is good code and how to refactor towards it is a far bigger set of arguments with many opposing camps. Though there is a large concensus that code should read like english as much as possible, IDE's allow this as the speed benefit of terseness is greatly reduced.
Not sure how the quality of Joomla is as a coding reference point. If you feel the need for a comment the question should be what is wrong with the code for it to be needed. It might seem academic in some ways but after a while the ugly in the code starts to show very quickly( before anything else is read ) and as comments can be seen as the collaborators of uglinesses stopping comments helps stop the ugliness. It causes headaches for the writers of the ugliness who use comments for crutches and a bit of discomfort can be very good for learning/rectifying behaviour. Personally I'd prefer a more direct dog whisperer approach as well but that is not embraced by common working culture.
The developers of Joomla may of gained a pack instinct that has caused a shared instinctive understanding of what they communially write with little understanding of those who do not have that instinct, pack thought makes them believe comprehension of their code is easy. This is actually quite a common thing with any group of people, there would be a lot more arguments without it as it is a binding force.
Black and white rules usually appear in teams as blanket reactions to commonly occuring problems that do not require thought while doing, it stops many creative resolves being formed without good backing argument. Like any blanket rule some may follow blindly incurring other problems while others will argue for refinement of the rule so those new problems will not occur or stop occuring. That refinement can become more of a political point within a team as it relies on everyone to think and agree. Not everyone really likes to think or being forced to think and will argue that is just the way we do things, sometimes possibly the reason was never really understood or maybe has now even been forgetten. Monkey see monkey do.
Comments definitely are not architectural plans whatever their level of occurance. For an OOP coding style this may be quite interesting.
Efficiency over readability is not something to be done lightly and should be a specific reaction to a specific problem that has been thoroughly explored. There is a higher level of comprehension at the moment of writing than a later moment of reading so that also has to be taken into account. If large amounts of effort are needed while writing in the now to sustain comprehension due to current eyeball level complexity, an impossible level may be required of someone reading in the future. This applies to procedural or OOP.
Though as experience grows what was hard can now be easy and what was easy can now be hard in comparison so is definitely not a personal rule to set in stone as it requires constant personal revisement.
I take too long to type stuff and a lot of it comes from reading material like Clean Code which has been mentioned earlier
Code reuse when there are lots of hierarchies. Those kind of code which goes down deeper and deeper into cannot even reuse for the project they have developed. Because no one dare to see and understand those project.
but i know many people who like those kind of code in the name of modularity / code reuse etc
I've been doing some reading on this HipHop and it's not just a PHP to C++ compiler. It's a Web server replacing Apache. I'm not sure how many Web hosting companies would allow it to run.
To be honest, I think if you have the type of application where the idea of using hiphop becomes a reality, you are likely to be running a dedicated server anyway.
C++ isn't web code on it's own - and without writing an apache extension, it wouldn't be able to interface with a web server, and there are several speed enhancements that can be gained from running the site as a separate application that listens on port 80 for traffic and responds accordingly. It can be optimised for the site in question rather than having to support many different possibilities and applications.
That's what it sounds like, currently.
However, I've been involved in their group discussion and it sounds like they would appreciate some help incorporating this into the open source community.
I have volunteered to re-write some PHP extensions in C to be thread-safe, since I've written UNIX and Windows device drivers. Converting some libraries to pure-functions, examining dependant function calls source code for their same pure-function support, using a mutex for share resourses, etc. Testing for dead-lock conditions, race conditions, and using stack instead of heap resourses, re-entrant functions calls, etc.
Since it's contributing to the global open source community, it will be that much more rewarding.
As has been mentioned before blaming objects for the speed of an application is like blaming a car's rear view mirror for an engine missfire.
The real problem is poor code built by programmers that don't really understand objects or for that fact databases.
I've just hacked my way through a Joomla site and the code I found was nothing short of hideous and as pointed out by the OP their commenting is nothing short of a joke. Some people build 'objects' (for lack of a better description) just to build objects. I think they attempt this just because they heard objects are cool but when you look at these so-called objects you really have to wonder.
I've done OOP in both Java and PHP for many a year now and have yet to see an object itself cause 'speed' issues (that's objects I have built). What I have seen in many of these OS projects is code that doesn't allow each part of the application to do it's own job. One example I can come up with off the top of my head is an object that retrieves and sorts data from a database when in fact the database itself can do this work 100 (if not 1000) times faster. Another that comes to mind is something another 'developer' asked me to look at. He needed to determine the age of someone using their birth date and the date they died (which came from the database). He had over 900 lines of code parsing the data six ways to Sunday when in fact it could have been done using the database in 4 lines of code.
People that feel they have to 'reinvent the wheel' in their own objects when there is already a tried and true method of doing something cause a LOT of this slowness you see in some of these things.
PHP's OOP approach is more like as the racing light turns green, let's start assembling an Indy car for a drag race, then disassemble it at the end of the race. Op code caching seems to address this problem though.As has been mentioned before blaming objects for the speed of an application is like blaming a car's rear view mirror for an engine missfire.
I agree. I've also, like you, come across questions at this site that demonstrated processing on data in PHP that should be done on the database server, as simple as counting rows.I've just hacked my way through a Joomla site and the code I found was nothing short of hideous and as pointed out by the OP their commenting is nothing short of a joke. Some people build 'objects' (for lack of a better description) just to build objects. I think they attempt this just because they heard objects are cool but when you look at these so-called objects you really have to wonder.
thats the problem...The real problem is poor code built by programmers that don't really understand objects or for that fact databases.
i'm coding oop since php supports it and never had speed problems! if you are planning right and THEN implementing object oriented, nothing can go wrong and the project will be extendable and easy to handle...
oop never is the problem, it's the "BUG" 25cm in front of the screen!
OO was always slower than structural programming. However OO has other strong points. The same principles applies to PHP imho.
Is the use of classes and oo concepts in PHP. The same happens in c++. If you write the same program in simple c it runs faster than in c++ even if you use the same language. Object oriented programming introduce an extra layer that slows the program.
Stating OOP > procedural programming is a gross oversimplification of the whole issue.
It is easy to theorize about these things but in the end it depends on this: is it practical or not.
to continue with analogies it is like saying that since a Ferrari is fast it can save you much more time in a highway than a regular car. In theory, yes. Or saying "yeah! I can modify my car and compete in a F1 circuit" yeah.. maybe... but what's the point? is it worth the effort? Comparing raw speed against nothing is always a win.
When people claims that C++ should be used in sites like Facebook... really? don't you think someone would have already tried it? speed is is important but is not the only thing to consider in a project... same for OOP.
Small medium systems may not need full OOP capabilities... bigger systems yes, maybe.. it depends. Frameworks in the other hand provide a base platform but you are always conditioned by the framework's structure. There is no universal solution.
Just look at Linux (an an operating system, not just the kernel), the vast majority of that is written entirely in procedural C code. It works well because the design is good.
Another important aspect is that it is perfectly possible to write object orientated code in procedural languages. It is quite common to see object orientated C programs (note: not C++). Just take a look at GLib.
Much of this discussion has been mis-focused on OOP as the villain. I didn't say OOP is the problem. I said the combination of three techniques combined at launch time is not efficient. Haiping Zhao of Facebook found this same inefficiency and compiled PHP it into C++. That's a solution!
But, the fact that #2 Web site that depends on PHP developers decided to go with the economic model found a need to decrease PHP's inherent inefficiency closed this thread, I think.
Time will tell.PHP is not for big sites like Facebook.