TL; DR

For me if you are not using the oop pillars you are not doing OOP. And for me almost every project that says OO (not programming) in the background calls OO because it is fashionable. Some people disagree with this. Cohesive and non-coupled designs are always desirable and this can be obtained in the procedural, especially if applying modularization, people take this as something of OOP simply by not knowing paradigms , only decorating the cake recipe they find by there.

Detailing

I have already answered about procedural programming. We try to answer what is object orientation (about the term can help). Note that there is not even consensus of what this is and everyone thinks that their definition is the right one and that of others is wrong. Be sure to see about modular programming because I'll talk about it. As there is confusion about structured programming in other answers read also ( plus).

I like definition of the title of this question: meaning of "the code acting on the data"and" the data controlling access to the Code " , I think this question can be asked for you to identify what you are doing, I do not know if it helps so much, but it is good. And a analysis comparing both can help answer quite broadly.

If you want a practical example of analysis you have a question: my code is oriented to object?.

So telling what OOP is or isn't depends a bit on who's talking to you. This is the reason I think no one can give a good answer. Perhaps if following the pillars of oop is a form. Some will say no. Some will confuse object-oriented design with Object-Oriented Programming. Got more confused? Yes, it is. One of the reasons I abhor UML is because while it's designing it uses terms and preaches different things than people use in programming even because it disregards performance and specific characteristics of the technology used.

There are chains that preach certain rules and others that preach others. For example the controversial use of getters and setters (yes, you have to read all links there to understand well), just to cite an example.

A common mistake is to mix abstraction with encapsulation. I did a lot of this myself and I need to review my answers to see if I still there's nothing wrong with that.

What many err think that using a class is Object-Oriented Programming. Class by itself is a simple data structure that has something similar in non-object-oriented languages. The way you create the class will define if it is OOP. A simple class at most is a modular procedural programming. And OOP does not require to have class .

Out there you can already see that the least voted answer speaks of things without commitment to accuracy. She is not strictly wrong, but does not mean anything.

The most voted answer (so far I write here) gives some code style rules (even good overall), but that has nothing to do with OOP, you should follow that in procedural programming as well. Even what else you have to understand to put together a good design code is about cohesion and coupling , which in the background is the origin of SOLID (it's just a different way of marketar the concept original, it is a "Miojo tip") and the first items of the answer after it is summarized in the last when it speaks in SOLID. SOLID is not the same as OOP. The answer also does not say anything that helps.

The most recent answer is full of errors:

• she thinks that having objects is something unique from object orientation, and it's not.
• speaks in exchange for messages, which is not an error per se , but today no one programs thinking about it, it is a theoretical concept that lost because it makes no difference.
• having an object graph has to do with data structure and not with OOP.
• a sequence of steps is something about imperative and non-procedural programming.
• the rest of the paragraph without a clearer definition does not mean anything.
• already linkei something about cohesion and coupling, this is much older and is something applied to oop or procedural or modular, it is not unique to OOP, it is concept of design of systems (and does not even need to be programming).
• any complex project requires significant effort, the problem with OOP is that if you make a mistake in the design it is not so easy to correct afterwards (I already answered to the AP about this I did not find in which question it was).

I think the presence of the tag programming-structured may have helped in the confusion.

Pure procedural today is not much used except in script languages since there it has no complexity and oop without complexity doesn't make much sense (I talk about this in one of these links). In general we use procedural with modular. Then it becomes more difficult to see differences because the module can be a class.

Some people are so dogmatic with OOP that if you do as they want you will have an ideological code and not always meeting the actual demands of the system.

If people don't even understand what all these things are, Do you think they're going to apply it right? OO is something so poorly defined that people use the term without even knowing if they are doing it.

Tips for evaluating

Some people talk that the fact that you access the methods by the object is OOP, something like this:

objeto.metodo()

As opposed to this procedural:

Method (Object)

Swear that only this detail is Object-Oriented Programming?

Others say that it is almost that, but looking from the class side, then they say that it is the methods that are close to the state. In fact it is a unique way that the " OO paradigm has, so even could, but only that defines? Maybe. But some tend to put together things that shouldn't be there. So they began to create rules for making smaller objects, so small that it becomes clear that the cohesive object is practically no objects (have some clear, in all paradigms there are objects).

But people talk a lot about doing object orientation in the right way. There is a set of rules that people talk about, not all of them are consensual, but essentially all are rules of good design that must be applied in any paradigm. Again, the fact that people don't understand this says a lot how they learn in a very crooked way.

There are those who say that it is simulating the real world, but today many people consider it silly, including because it means little,besides not being able to do this, the world is much more complex.

Some people say that only encapsulation matters, because Alan Kay defined it that way. But even he admits today that what he described and called Object-Oriented is actually message-oriented. And outside of OOP this always existed and was called abstraction. And then there's the fight about whether it's valid to encapsulate with getter and setter or not.

Probably object-oriented programming is utopian, so everyone has their own way of accepting it.

What I'm sure of is that a lot of people do design very bad because they only know how to follow the rules that do not help her at all, she only decorated them and did not understand the motivation.

Conclusion

OOP is not understood by people and this has to do with how the subject is taught and how the concept was created. A lot of what people believe to be OOP is actually just good design code, that's when it's actually a bad design but people think it's good because it decorated the wrong cake recipe. So I always finish my lectures with:

A lie repeated 1000 times does not make it true

This has to do with the idea propagated by Joseph Goebbels. I'm not saying oop proponents are Nazis, see? : P

I know I can answer better, probably showing examples, maybe one day I will, but I had to answer here at least to make it clear that it is not as simple as some think to determine this.