Hello. I've been asking a lot of questions about a program I am making in this forum, and I think it is complete.
But since I am who made the code, it probably has a lot of blind points in the design, code, and many more.
How do I look for errors that are not quite obvious like compile or runtime exceptions? I'd like to know some principles, because my code got huge and separated in many files and is now very difficult to review.
I suggest you start by reviewing your design, possiably with a UML diagram, to see that the number of classes match what you wanted originally.
Once you have done that, remember that one idea of programming is to modularise the code. That applies to functional, object‑oriented and procedural programming alike. So you should be able to go through each class and each method and work out what it does.
You can look as long as you like for compile exception but you won't find any because there is no such thing. You shouldn't have any unexpected exceptions. The one that will surprise you is null pointer exception. You need to be aware of all situations where nulls can occur; it is probably best to get rid of all nulls by assigning the variables with “real” values.
I’m guessing you’re asking along the lines of “How do ‘professional’ programmers know when they’re done?”
If that’s what you’re asking, here are some criteria for a “professionally DONE” job:
1. All your tests pass. If you have no tests, then your program basically doesn’t exist.
2. The code expresses its intent clearly. People need to be able to read your code and easily understand what it does. If it’s difficult to review like you said, then there are a number of “code smells” that need to be addressed.
4. The design has the fewest/smallest possible elements. If the code is huge and has more code than is absolutely necessary to provide the functionality needed, then again, it needs to be refactored so it’s simpler and more streamlined.
These are Four Rules of Simple Design that professionally written code must adhere to, at least in my book. Unfortunately, there are many programmers out there who get paid to write code who don’t follow these rules or even know about them. Hopefully, you’ll not turn into one of them.
Post your code so we can comment on it. A nose for code smells only comes with experience so it’s best to have other people tell you what you might be missing.
If you are looking for principles, there are a few I’d recommend considering. The Four Rules of Simple Design I just explained are a great place to start. They lead you to other principles. DRY is just one of those.
Here are some more good ones to consider:
SOLID - a set of design principles for object-oriented programs (Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle)
Campbell Ritchie wrote:Is the law of Demeter really a law?
That’s what they named it. I wouldn’t really quibble over this particular name. Speed limits are laws but are they really if everybody drives at least 5 over it? Both of these are good guidelines to keep everybody safe, at the very least. Even the Wikipedia entry for LoD says “The Law of Demeter (LoD)... are guidelines”