Hi Alberto! I understand your point and you are right, but I think the scripts I look for will take out the trivial parts to check, so reviewer can focus on more important things. I just see automatical checking as an supplement not as an stand-alone review. Greetings Bjorn 2007/9/21, Alberto Dell'Era <alberto.dellera@xxxxxxxxx>: > > On 9/21/07, Bjørn D. Jensen <bjorn.d.jensen@xxxxxxxxx> wrote: > (snip) > > The scripts are not so important, it's more important for me to get some > > ideas about what could be of value to check. > > IMHO, you should establish a review process instead of relying on > automatic scripts: have the most experienced developer(s) review > the code, in a joint session with the author. > > This costs almost nothing (it doesn't take a lot for an expert to spot > critical points in the code) and the benefits are invaluable, since there > will be a lot of knowledge transfer between the two parties - "why > you didn't use a private procedure in this package, instead of > declaring it in the package header ? " - "Oh I didn't know it was > possible, > what are the benefits ? " - "Well, the benefits are ..." > > That would disseminate expertise very quickly in your company/team, > and the few things an automatic script might catch will be caught > as a by-product. > > Not to mention the networking benefits : the two developers will get to > know each other, and probably get in touch in many occasions, > consulting each other, thus further improving the quality of work. > > Oh, last but not least: knowledge goes both ways, even from a "beginner" > to an "expert" - so the "expert" will (not might, will) learn new > techniques, > new tricks, new features, that will be further disseminated in other > review > sessions to others ... "viral" knowledge transfer, the best thing a > company > may wish for. All for the negligible cost of a few hours. > > my 2 cents > Alberto > > > -- > Alberto Dell'Era > "the more you know, the faster you go" >