• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

What should I look for in my code before calling it "Finished"?

 
Ranch Hand
Posts: 55
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks.
 
Marshal
Posts: 77291
371
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 77291
371
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you can't go through each method and work out what it does quickly, you should refactor your code and simplify it.
 
Sheriff
Posts: 17443
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

3. The code contains no duplication. That is, the code doesn’t violate the DRY Principle (Don’t Repeat Yourself). If it does, then that’s another code smell that needs 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.
 
Junilu Lacar
Sheriff
Posts: 17443
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)

SLAP - Single Level of Abstraction Principle

Law of Demeter

POLA - The Principle of Least Astonishment (or Least Surprise)

Many code smells come from violating the above.
 
Campbell Ritchie
Marshal
Posts: 77291
371
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is the law of Demeter really a law?
 
Junilu Lacar
Sheriff
Posts: 17443
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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”
 
Campbell Ritchie
Marshal
Posts: 77291
371
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would appear we are thinking the same way, just expressing it differently
reply
    Bookmark Topic Watch Topic
  • New Topic