Code reviews?

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.

Reply to
martin griffith
Loading thread data ...

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

Reply to
Gary Kato

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

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
 Click to see the full signature
Reply to
Robert Kaiser

"martin griffith" schreef in bericht news: snipped-for-privacy@4ax.com...

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)
Reply to
Frank Bemelman

Hans-Bernhard Broeker said

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

Casey

Reply to
Casey

martin griffith said

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

Reply to
Casey
[...]

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

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

"Dave Hansen" schreef in bericht news: snipped-for-privacy@News.individual.net...

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

Reply to
WaldemarIII

"Frank Bemelman" schreef in bericht news:419df889$0$568$ snipped-for-privacy@news.xsall.nl...

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

Reply to
WaldemarIII

In article , martin griffith writes

1 Static analysis. Ie Lint. 2 After that leave it for a week. Look at the spec (not the code and write some test scripts for the ICE or SIM to unit test the code.

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

You would have this problem with reviews of documentation other than your code methinks. The person that reviews your documentation and/or your code need not be in your own company. You can always employ a reviewer to look over the code. However, you will want to progress the code to a point where it hangs reasonably well together.

As one who has worked as a lone consultant I maintained a small group of contacts that I could trust who would assist me in the review stages. It cost me a small amount to retain their services but I did not need them full time (often doing the reviews in the evenings or at weekends and combining it with a social meeting). Many of my reviewing colleagues I had worked with in larger organisations so I was well aware of their capabilities and their thinking.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

Everyone who programs in C NEEDS lint

Robert

Reply to
R Adsett

I thought the truth was that sometimes you feel it may not be worthwhile doing a review. In actuallity it is always worthwhile and you may get to the point of wishing you had when an un-reviewed bit of code bites you back hard. Of course, up to now you may have just got away with it but one day...... ;>

If you keep to small simple modules of documentation and code, you can merely drip feed it through the reviewer. Other respondents have already mentioned the benefits of keeping it simple.

OK if it is a product that has no safety implications.

Is that why we get glitches on the phone line from time to time??? ;>

No screams. Just the gentle sounds of "tut, tut, tut".

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

"WaldemarIII" schreef in bericht news:419e51f2$0$46979$ snipped-for-privacy@news.wanadoo.nl...

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)
Reply to
Frank Bemelman

Really? I certainly didn't say or imply that.

You can't if there is "the reviewer" doesn't exist. Keeping things simple is great, but there are real-world cases where you just don't have the time, money, or luxury for a review.

Products with safey implications are of course in a different category.

Client asks you to do the software for a new product - the budget is tight, the schedule almost impossible. You're presented with a choice

- take the job and do your best or refuse the job. "Tut, tut," doesn't enter into the equation. The fact that you have a teenaged son that eats a lot might weigh heavily on your mind.

Btw, I just finished one of those jobs.

Casey

Reply to
Casey

"Paul E. Bennett" schreef in bericht news:cnlo3m$cao$1$ snipped-for-privacy@news.demon.co.uk...

What about products that cause a lot of damage. If a CNC machine drills holes in the wrong spot, it can ruin quite a bit, truly upsetting people.

This is all kindergarten talk. We all know that some parts of our software are more critical than others. And not all bugs have desastrous effects. Nobody ships code without at least some confidence, and most 'bugs' are only a nuisance, not more. Hell, I even ship code with known bugs. Work in progress.

A few months ago, somewhere in the UK, an ATM machine was spitting out twice the amount of money. In no-time the entire village was queing up in front of the machine. Software bug? Nah. A bank employee had swapped the bins by mistake, and 20 pound notes were ejected instead of 10 pounds.

I am a bit amused that the majority here exclusively works on applications that launch rockets, keep satelites in orbit, control heart-lung machines, or are used in airplanes (and I am not referring to the sensor that detects if the toilet seat is up or down) and god knows what have you. As a result, malfunctioning software always let the rockets explode, satelites get lost, patients die by the dozen, and airplanes burry themselves in the ground. For some reason we never hear of that button that pops up the wrong menu and confuses the operator, the vending machine that thought it was empty while not, the weird message in the logfile, the panel light that didn't go off, the christmas lights that sometimes changes it's blinking pattern, etc....

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

Martin,

It can be done, although it is usually more helpful to have someone else review the code, design, or behavior. When I have to do that I mentally put on my 'review hat' and set aside time for just that. It can't be done after you've coded it because all the details are still fresh in your head. Give yourself a little time and approach it as trying to find ways to improve what you did.

I've had to work alone on several projects and it helps to have a definite routine to follow as far as requirements, design, coding, testing, verification, validation, and so on. I rely heavily on version control systems for all my code, build procedures, and documents. One of my absolute rules is that all code must be reviewed before it is checked in. Everything must be complete, correct, development tested, and changes documented. If I must check in code between complete feature implementations, I leave unique markers thoughout the code as to what needs to be finished. Those are checked for again later (as a rule) before I would attempt to build the project.

You've taken the first step and recognized the need for improvement in your process. Decide how to fill that role and improve again as needed.

If you'd like an email buddy for such reviews I can occasionally spare some time. If you are interested I'll send you my real address; this one is obviously not real.

David

Reply to
David

Safety is an issue in all CNC machines so I would hope is not the type of product that does not see a code review, not only for the basic executive code but also for the machining code to produce the product. In the latter I know there is some tool assistance. Not only is it expensive to damage the tools but it can also launch shrapnel if it shatters (hende you are then hoping that the guards are actually closed and adequate to the task of catching the bits).

True.

I would hope that it is more than merely some confidence. I tend to require a greater element of certainty about what I ship. Just for my own peace of mind if nothing else.

If I know I have a bug in the code it is not shipped until the bug has been removed. Mind you, most of them are eliminated very early in the coding segment of development.

Some examples of my involvements:- Hydrolastic Mixing Facility (25 years at issue 1 - 6800 Assembly) Gas Analysis (for automotive industry - GA Assemmbly) Peripheral Test Programs (Pr1me Assembly, BASIC and Fortran IV) Gas & Oil Production Well Head Controls (WesDAC SCADA) Railway Signalling Equipment (Ada) Automated Battery Charging Systems (6309 Forth) Paraplegic Electric Wheelchair (RTX2001 Forth) Nuclear Fuel Re-processing equipment Train Safety Monitoring System Coal Stacker Reclaimer (Mitsubishi PLC) Warship Compass Data Distribution System (D3 and 1553B) Army Tank Equipment Test Rigs (Gun and Suspension) (Forth) Nuclear Power Plant Fuel Handling and Recycling Equipment (S80) Plutonium Pick and Place Crane (6309 Assembly, Literal and Forth) Medical Anesthesia Ventilator Software Certification (Forth) Multihead Weighing System (Forth) Medical Sterilisation Fluid Manufacturing Facility (Forth) Fusion Reactor Fuelling Systems (Allen Bradley PLC and Forth)

Naturally I wasn't on my own for all of those. Some of the projects are only done from within a larger company. However, some of the more critical ones were handled by a team of between 5 and 9 people filling all the engineering and project management roles.

No matter how good we all become at our jobs, no matter how perfectly produced and debugged our software becomes, there is always the chaotic element that will unravel our best efforts. However, the chaotic element does not need to be given a helping hand to disrupting our lives just because we failed to review our work and let the bug we should have spotted through the net.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.