So you claim you don't know it perfectly, right? So, if you don't know it perfectly, then why don't you have a C++ or Java book at your side (or a good reference page bookmarked)?
When asked that, I'm sure most students think "The book is too heavy to carry around". And I might say, "But what happens if you forget something?". They usually don't have an answer. They ask a friend, or just guess at the syntax.
Among the most common errors you can make in programming is thinking you know how some function or language feature works, but in the end, you forget how it works exactly, and then just guess on the code. Guessing may save you a few pounds in the backpack, but it may add additional hours to coding. Think about it.
For example, I've had students say "I haven't programmed C++ in a year", and I'm thinking "What? You've already forgotten?" (and most forget after a semester). I haven't actively programmed in C in 3 years, and still I remember how to code in C. I haven't actively programmed in Java in much longer, but I have books I can look up, since it's been that long.
I'm not sure why students tell me they haven't programmed in a few years. Am I supposed to think "Well, in that case, just skip the project. You don't have to relearn anything!"? I hope not. This is why people keep old notes, old code examples, and their books. These days, if you find a good website (especially for Java), then you save carrying books too!
The lesson to be learned? Realize that you probably haven't memorized C++ nor Java. Have a good reference book to look things up, especially if you're not so sure how to do something. Random guessing is just wasted time.
To these students, beyond that, nothing matters. Good comments, efficient coding, good use of functions, good classes, good divisions. To be a good coder requires looking at good code. It requires having some idea of what others think is good code.
Sometimes I envision having discussion groups in CS like they do in history or English. Your assignment would be to take someone's code, explain what went wrong, and then find at least one way to improve their code. You might even give them a score on their code, A-F, which doesn't really count, but gives feedback to the students, anyway.
The point is that good code is more than code that simply works, regardless of what way you wrote the code. For example, writing a non-fiction book is more than having the facts written down somewhere. Usually, you want to make it compelling reading, so choice of words, choice of presentation order, all make a difference.
Let's look at one idea for writing better classes. There's this idea called MVC, which originated back in the language, Smalltalk. 'M' stands for Model, 'V' for View, and 'C' for control.
Think about implementing a GUI version of checkers. The model would be a class that represents the checker board. It would have methods to tell you where the pieces are, to move a piece, and to tell you if a method is valid. However, there would be no methods to display the board.
The "view" is the GUI display of the checkersboard. Given the information it gathers from the model, it can display the board. This is a class.
The "control" is the part of the GUI where you can manipulate the pieces. For example, you might be able to drag a piece, etc. This is also a class, although frequently, it's combined with the "view" class.
The "control" class translates actions taken in the GUI, to method calls to the "model".
Why do it this way? If you write code that separates the GUI aspects from the model aspect, then you should be able to replace the GUI with some other GUI, and leave the model alone. This gives you more flexibility when coding. It doesn't tie down the model to a specific GUI.
What's the point? Just because you know "how to program" doesn't mean you know how to program. You might get the code to work, but it may have bloated code, code that is unnecessarily repetitive, and that doesn't use a lot of OO techniques.
For example, if you're programming in Java, the latest advice is to program using interfaces. Interfaces are like abstract classes, however, they lack implementation and data members. The idea is to declare interfaces, such as SortedList, which has methods for adding elements, removing elements, and traversing the list, then instantiate the interface to an object that implements the interface. Thus, you might have BST, a binary search tree, that may implement the SortedList interface.
By using interfaces, you can again, switch out the actual object instances, and use different objects that have the same interface. The code does not have to be changed, when you switch interfaces.
What's the point of this discussion? It's to tell you that there's a lot to know about object oriented programming (OOP). Reading books on OOP and on design patterns will help you become a better OO programmer. Just knowing how to declare and use classes is not enough.