Thread: How to get a code review

Hi everyone. I have spent the last 12 days writing a Wikipedia bot in C99. It's 5300 lines in 160 files, and it's finished. It's a fully featured bot with 12 command line options, it recovers from every recoverable error and does everything a Wikipedia bot should do. I stuck as closely as possible to Standard C, so it should run unmodified on any UNIX-like operating system and on Windows with one trivial modification. I'd be open to the idea of donating it to the GNU project. However, C is not the most natural language to write a Wikipedia bot in, and it handles XML manually instead of using an XML parser like it should, and it was written by just one guy in less than 2 weeks, so I'm not sure that it's good enough.

How do I get a proper code review? Is there a way to get someone or several people to look over my code for errors and better ways of doing things?

Richard

Get some cojones, toss it on source forge or somewhere-- people will review it.

Sure, but it depends, if you want to share your idea, if not........ try it on your own :-)

Originally Posted by Richardcavell

Hi everyone. I have spent the last 12 days writing a Wikipedia bot in C99. It's 5300 lines in 160 files, and it's finished. It's a fully featured bot with 12 command line options, it recovers from every recoverable error and does everything a Wikipedia bot should do. I stuck as closely as possible to Standard C, so it should run unmodified on any UNIX-like operating system and on Windows with one trivial modification. I'd be open to the idea of donating it to the GNU project. However, C is not the most natural language to write a Wikipedia bot in, and it handles XML manually instead of using an XML parser like it should, and it was written by just one guy in less than 2 weeks, so I'm not sure that it's good enough.

How do I get a proper code review? Is there a way to get someone or several people to look over my code for errors and better ways of doing things?

Richard

Test if for a couple of months first...

I can guarantee that if you wrote 5300 line in 160 files in 12 days
a) you didn't get much sleep
b) that software is totally untested except for your test runs after compiling
c) there are at least 10 bugs in there waiting to get you.

Pretty simply, nobody writes GOOD software in that short a time.

Tater,

Thanks for your support in my leet coding skillz. Yes, my code must be thoroughly tested, and yes I am exhausted after those 12 days, and yes I'll put it on sourceforge.

Richard

My idea is to make the program as modular as possible. All the functions are designed to be standalone, re-entrant, etc. Now that I've got the code working, I'm reducing the number of translation units.

And yes, my code is brilliant.

Originally Posted by rogster001

Haha, similar thoughts here, I have spent six months on a similar sized project! Maybe a little bigger i not counted the lines much, but still, the main code was in place around two months ago and since then it has been 'destruction' testing

Exactly... after writing the basic code the next phase is to see how easily it can be broken. Testing often takes longer than the main creation task and, if my personal experience is any guideline....

Rule #1: Just because it compiles does not mean it works.

But 160 files? Thats an average of around 33 lines a file? And how much of that is actual code? That seems crazy to me. I am quite happy with a hundred lines or more in a 'larger' file. I dunno, maybe those short files are appropriate for a bot project though..ni idea amigo

I'm getting a headache trying to picture the maze of #includes at the top of each page...

Originally Posted by Richardcavell

and yes I'll put it on sourceforge.

Any idea how much bad code has gotten out into the world that way?

All interesting and good ideas there.

How does one go about a good code review? Do you start from main () and follow the program step by step, or do you review source code files alphabetically, or what?

Richard

Well, when I do it to my own code, I generally go section by section.

I write my programs so that a given module of the program is all in the same source file... for example, my "setup" dialog will be one .c file. So my code is broken down by logical functions.

To review a piece of given code I will ask myself a number of questions:
1) Can I simplify this without losing functionality?
2) Can I rewite it to be more easily maintained?
3) Are there any conditions where it can fail?
4) Is the code clearly organized and correctly indented?
5) Will I be able to still read this when I come back in 5 years?
etc.

In general the goal is to make better code...

As part of the review I also run the program, examine the display of that code section, looking for errors in setup, bad spelling, improved ease of use etc.

Section by section...

I see what you mean. Of course, I'm just one guy and I'm a relative newbie at C, so I think my ability to conduct a code review of my own code is limited.

Originally Posted by Richardcavell

I see what you mean. Of course, I'm just one guy and I'm a relative newbie at C, so I think my ability to conduct a code review of my own code is limited.

If you can't look at your own code and say "Hey... I can do (this) and (this) and make it better", then either A) you are beyond perfect or B) you didn't learn a thing writing the code.