Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Dec 27 '10 at 16:41

This question came from our site for professional and enthusiast programmers.

Does this belong on programmers.s.c instead? – derobert Dec 27 '10 at 16:06
It may. I don't exactly know, when my question should be put on programmers, rather than SO. Can it be moved? – gruszczy Dec 27 '10 at 16:11
@gruszczy: Yeah, it can be moved. Close -> off topic -> belongs on programmers. If enough people do that, it'll be moved. – derobert Dec 27 '10 at 16:16
Ok, I have voted to close and move to programmers. – gruszczy Dec 27 '10 at 16:17
Managers tend to think that projects with more lines of code are better. – Alexandre C. Dec 27 '10 at 16:22
up vote 2 down vote accepted

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.

alt text

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).

share|improve this answer

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.

share|improve this answer
Actually, I have done that, though I didn't intend to :-P First, I have written some python tests for new features (some of them still fail) and then I started writing the actual code. I am familiar with TDD, but wasn't really conviced to do it. It just happened, that I had :-) – gruszczy Dec 27 '10 at 17:11

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.

share|improve this answer
It is not only an aesthetic principle: when you repeat yourself, whatever you change in one place (for instance correcting a bug) must be changed in some other place, what you easily forget. – Alexandre C. Dec 27 '10 at 16:25
Is there any tool for detecting duplicate code? – gruszczy Dec 27 '10 at 16:53

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)
share|improve this answer

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.