how to evaluate own project

Question

I am working on a open source project in pure C, that I have started some time ago, but only recently found time to add some features. I can clearly some weaknesses of my old design, so I am trying to refactor my old code. I have no idea however, how to evaluate properly my new code. Do you know about any techniques or tools for code evaluation? I am pretty good with object oriented design, but for about three years I had no contact with purely structural one. Therefore I don't have enough experience, to be able to discern between good and bad design choices.

Answer 1

The question is so general, that the answers will either concern one point (as "don't copy-paste code", "one method must do one and one only thing", "comment your code properly", etc.), or be also too general, like mine:

There are two ways to evaluate your own project.

• The first one is obviously to give this project to a more experienced developer, and to count the number of WTFs during review.

(source)

The problem with this approach that it is more the developer is experienced, better will be the review, but you will receive more criticism from a more experienced developer, so it may be really discouraging and depressing. On the other hand, if you choose a developer which does not want to criticize you too much or is not very experienced, their review may not be too useful.

• The second way is to wait when you will acquire more experience, then review your own project, thus optimizing, refactoring and modifying the code.

You can then determine a lifespan of your code, and try to review it regularly. For example, in my case, the lifespan is one year: it means that I may modify the code which I wrote six months ago, but if the code was written two years ago, it has a strong chance of being thrown, then rewritten completely, since it just sucks too much.

---

To resume, there are no ways to really evaluate your own code. It is perfect for you at the moment when you write it. But the same code is bad when reviewed by a more experienced developer, and this same code will be bad when you will review it after learning and understanding new things.

In other words, there is no objective way to evaluate the quality of code: you can only evaluate the quality of code (and so your skills) relatively to the code of other developers (and yourself after learning more things).

Answer 2

Do Test-Driven Development, not only it will help you to test everything is right and give your open-source audience a sense of stability, but also force you to write modular, better architected and more refined code.

Answer 3

If you are looking for a simple answer, I would always keep in mind D.R.Y. Don't Repeat Yourself. If you have copy and pasted code from one area to another, you are probably doing it wrong. Cut and paste is fine, copy and paste not so much. Also if your code is hard to unit test then I would be concerned about the design.

Answer 4

I think that when dealing with OOP one good idea to keep in mind is:

• Keep class lightweight, i read some where this quoute: "Keep it simple stupid"
• When facing some peace of code that you think might need flexibility. It's always good to give it some time and check for Design Patterns that may add some goodness to your solution (you wont regret it)

Answer 5

Somewhat of a second answer...

@MainMa Of course there is, actually there are many ways to evaluate and assess software quality, those are software development processes that go from the highly regarded Scrum, to the less practical and more rigid (but perhaps more objective) PSP (for personal code) & TSP (for team code).

First, one must define the type of software quality factor one is seeking, then pursue it with the right tools. For personal code, try the Personal Software Process but ditch the fugly paper forms for modern documentation such as UML, BPMN, etc., or even apply Scrum in a personal fashion.

@gruszczy Perhaps with your case, I'd seek a code repository hosting site that support a good code review workflow, such as github.

Code reviews and TDD, I think, are some of the best practices happening in open source projects right now, because they both keep the code alive and healthy