Code reviews?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
A bit of googling shows that code reviews are a "good idea"
Fine

Q:
How do you review your own code, ie as a 1 man self employed dude?

Its so easy to miss things when reviewing your own code.



martin

 Serious error.
   All shortcuts have disappeared.
      Screen. Mind. Both are blank.

Re: Code reviews?
Quoted text here. Click to load it

So true. Have someone else you know (a programmer)  look at the code. Another
way is to put the code away for a few days, then come back to it.

Find good coding standards and use them. Don't try to write one routine that
does a bunch of stuff. That makes it easier for you to see whether it is doing
its task correctly depending on inputs.

In general, watch the complexity. It's hard to strike a balance sometimes. If
you have too many routines, that can be hard to keep track of too. Having
decent documentation helps there.

Also having an overall document on the goals of the project is good. Sometimes
when coding, you can stray off the path or forget about a goal or three,
especially if there are a lot of goals (as I found when trying to make a
canonical Palm OS app).


Re: Code reviews?

Quoted text here. Click to load it

In a nutshell: you don't.  You simply don't have the necessary
resources to do it.

Which leaves you with three options:

1) Become a "Real Programmer"(no TM).  I.e., you could such a god-like
perfect code that reviews are futile.

2) Get external consultants (including your customers), to review your
code.

3) Become a >1 person shop.  Marry another programmer, hire one, team
up with one, anything, just make sure you're no longer all alone.

Of course, we all know that 1) is a non-option, realistically speaking
--- insuring against it is what reviews are about, after all.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Code reviews?

Quoted text here. Click to load it

In a nutshell: you don't.  You simply don't have the necessary
resources to do it.

Which leaves you with three options:

1) Become a "Real Programmer"(no TM).  I.e., you could teach yourself
to become such a god-like perfect coder that reviews are futile.

2) Get external consultants (including your customers), to review your
code.

3) Become a >1 person shop.  Marry another programmer, hire one, team
up with one, anything, just make sure you're no longer all alone.

Of course, we all know that 1) is a non-option, realistically speaking
--- insuring against it is what reviews are about, after all.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Code reviews?
Hans-Bernhard Broeker said
 
Quoted text here. Click to load it

Just a thought - it's a lot easier to "unhire" a helper than it is to
divorce one.


 
Casey

Re: Code reviews?
Quoted text here. Click to load it

Hmm, make it open source? (That's how Linus Torvalds gets his
code reviewed..)

If thats impractical: Try leaving it alone for at least a week while
working on something completely different, then look at it again.

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Code reviews?
Quoted text here. Click to load it

Do you need it? Assuming you're not in the rocket lauch
business like everybody else here, you can rely on the
experience with your previous projects. If you didn't
have too much problems with that, why bother.

I don't really review my code. I test. I improve if performance
demands it. Sometimes, when I borrow a piece of my older code,
(if I can find it quick enough) I may say to myself 'You can
do better than that' and still use it as is ;)

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Code reviews?

Quoted text here. Click to load it
C'mon Frank, you can't be serious. We're talking good and
honest professional software development here. Companies
can't afford to ship products that may be flawed because the
software wasn't submitted to at least one review. Oh, I know,
it happens all the time, I'm not that naive... But mentioning
medical applications, traffic control, automotive control,
you name it... All those critical applications that may cause
injury or worse if malfunctioning... I bet you your head that
software like that is reviewed till it croakes.

Waldemar



Re: Code reviews?

Quoted text here. Click to load it


When I said 'assuming you're not in the rocket lauch business' I
actually meant to say *all* applications where failure does not
result in truly big trouble. Extreme critical applications aren't
typically the area where one-man-businesses find their bread and
butter. Many one-man-businesses develop solutions for other (small)
companies, often to improve production and often very unique to the
situation at hand. Not sold in the thousands, low risk etc.

In other words, I was very serious. If you are in that kind of
business, and the stuff you deliver works reasonably well, it
makes little sense to change your methods. Although I have to
admit that it sometimes would be nice if someone else would
review my code, just for the sake of getting some feedback.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)








Re: Code reviews?

Quoted text here. Click to load it

It's not quite the same thing, but one way you can get another "opinion"
on your code (if it's C) is to run it through lint.  Gimpel's PC-Lint is
very good, and for open source, there is Splint (
http://lclint.cs.virginia.edu/ ).

Another way to approximate a real code review that is to use a checklist
(there are many on the web).  For each checklist item, if you go through
the code just scanning for that one thing, you can do a pretty fair even
on your own code.

I've done both of these on code I've written as a one-man-job.  It's
also a useful habit to get into when you get into the situation that
you're actually getting real code reviews with other people, because
your code will be that much better going into the review.

Ed


Re: Code reviews?
Quoted text here. Click to load it

Yes, (sp)lint is nice to catch some pitfalls. But often I found it
quite a hassle to configure it for a particular compiler.

Quoted text here. Click to load it

I will look into that, and test myself ;)

Quoted text here. Click to load it


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Code reviews?

Quoted text here. Click to load it

And I feel I will waste a lot of time on silly red tape:

g.       Structuredness:
1)      Is each function of the program recognizable as a block of code?
2)      Do loops only have one entrance?

1) - of course, if it compiles it has an end.
2) - I never have done this, and if I had, I have a bloody good reason
to do so.


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Code reviews?
Quoted text here. Click to load it

Not the same thing.  The question here is whether each *function*
corresponds to a block of code.  If you have an embedded system which
has an LCD display, is the function responsible for driving that LCD
recognizeable as a block of code?  Or is the code which talks to the LCD
littered throughout the source code?  That's what that first one means.

Quoted text here. Click to load it

In assembly language, it's much easier to make this kind of error, and
in fact, there usually is no good reason to do so, as evidenced by the
fact that you've never done it!

In any case, you need to create your *own* checklist which retains only
relevant items.  For example, "conforms to coding guidelines" might be
irrelevant if you don't have any.  However, I'd argue that the better
fix to that particular one would be to invent and follow consistent
coding guidelines.  You probably don't write randomly formatted code
now, but you might not necessarily have written down the "rules" for how
you write code.  That's all the coding guidelines are, and they're only
important because they eliminate the distraction of poorly or
inconsistently written code.

My rule of thumb:  if you have a good reason to break a rule, do so.

Ed


Re: Code reviews?
snipped-for-privacy@mindspring.com says...
Quoted text here. Click to load it
Just document why so you don't wonder later. :)

Robert

Re: Code reviews?
Quoted text here. Click to load it

Yes, that's true, there's another reason why I avoid assembler ;)

Quoted text here. Click to load it

Yes, over the years I have developed my own guidelines or adopted
ones from others. While I haven't written them down, it does help
a lot. But my latest bug would not have been caught by merely code
review, not very likely anyway. Only by testing, I'd think. And I
had tested it, but obviously not thoroughly enough ;)

Quoted text here. Click to load it

Sounds like a good rule. Let's stick to that, before we break more ;)

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)




Re: Code reviews?
Quoted text here. Click to load it

It's easiest to start out with "-weak" and just work on that first, but
you're right that there is work involved in configuring it to work with
a particular compiler.  Unfortunately, there is still no such notion as
"interrupt" in standard C.

Quoted text here. Click to load it

It works for me.  I have also found that if I find an error (of any
kind) the best thing to do is to look for more just like it.  In some
cases, I have written quick Perl scripts to automatically go through my
code and search for certain kinds of things (e.g. free() of space
allocated by alloca()).  If I were more organized, I'd have saved each
of those and made a nice collection, but I'm sad to report that I didn't
have the forethought to do it.  Maybe you will.  :-)

Ed


Re: Code reviews?
Quoted text here. Click to load it
That's why it is worth buying PC-Lint. Inn most places time==money. So a
"free" tool can cost more than a commercial tool by the time you have
set it up.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Code reviews?
martin griffith said

Quoted text here. Click to load it

Yes, it is.  Been there, done that, still doing it.

Regardless of all the good reasons why code reviews are considered
necessary, the ugly truth is that sometimes you just can't do one.  
I've done a lot of one man jobs and sometimes there really is no one
else available or the weeks of time to allow someone to dive into your
creation and understand it.

Out of necessity, I end up relying on others to torture test the
product instead.  Those people are usually far more readily available.  
It's amazing what someone will try that you'd never dream of.

I've been doing embedded work in the telecom industry for the last 16
years and never seen a code review yet.  Granted, I've worked with
smaller companies and products, but between tight schedules, looming
deadlines, and overstretched budgets, it's just never happened.

I can just hear the screams now ....


Casey

Re: Code reviews?

[...]
Quoted text here. Click to load it

If you program in C, I would say you _need_ lint.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Code reviews?

Quoted text here. Click to load it
Lint doesn't understand functionality, to me it's just another C beautifier
;-)
(Oops, shouldn't have said that.)

Former collegue of mine (in one of his more exuberant moods) is known to
have said:
"...if you need lint or similar crap, you just can't program and you never
will..."
He was reprimanded by his boss, who prided himself with some 10 years of
programming
experience (a decade, ha ha ha ha ha! impressive). Boss dictated that every
piece of
code head to be submitted to lint every day and the logs be forwarded to
him. Boss left
the company a couple of months later.   :-p

Seriously now... Lint flags ambiguous constructs and stuff like that, (don't
need to tell you
that, do I?), which is good (no question about that) but it can not and
never will explain
why you ordered the statements in that particular way, nor will it explain
the functionality
and the creative process behind those statements. It's a tool, not a means.

Waldemar



Site Timeline