Fw: greetings all!
Steven T. Henderson
stevenhenderson at prodigy.net
Tue Apr 13 11:14:34 CDT 1999
~sdpm~
i guess some of you had problems with my mail attachments <insert plea for
mail standards here>.
anyway, i have added a download to my website
http://www.stevenhenderson.com ), just click on the 'download cabin source'
button. i'm hoping everyone can read a ZIP file (i belived there is a LINUX
util that can do this). additionally, i am including the source i hope to be
reviewed. it should make enough sense even out of context and obviously best
viewed with a non-proportional font.
see you all wednesday night.
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
# FUNCTION: dPrintMonth
#
# Systematic printing of HTLM table defining a month/year pair.
#
# params
# $_[0] = month to be printed, format: mm
# $_[1] = year to be printed, format: yyyy
#
# returns
# none.
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
sub dPrintMonth
{
# Param is passed as mm,yyyy
my($date_month) = $_[0];
my($date_year) = $_[1];
# TODO: perform some checking here
# determine week number that starts the month
my($tmp_week) = 1;
my($tmp_cnt);
my($tmp_str);
# Next extract day/week info from date struct
my($prim_month);
my($prim_day);
my($prim_year);
my($end_month);
my($end_day);
my($end_year);
my($tmp_flag) = 0;
my($tmp_day) = 0;
# Boldly print requested begining month
print "<H2>$month{$date_month}, $date_year</H2>";
# Print header info
print "<div align=\"left\"> ";
print "<table border=\"1\" cellpadding=\"0\" ";
print " cellspacing=\"0\" width=\"100%\">";
print " <tr>";
print " <td><B>Monday</B></td>";
print " <td><B>Tuesday</B></td>";
print " <td><B>Wednesday</B></td>";
print " <td><B>Thursday</B></td>";
print " <td><B>Friday</B></td>";
print " <td><B>Saturday</B></td>";
print " <td><B>Sunday</B></td>";
print " </tr>";
while($tmp_week <= 52)
{
$tmp_date = &GetWeek("$tmp_week.$date_year");
# Extract day values from week
($prim_month, $prim_day, $prim_year, $end_month, $end_day,
$end_year) = split(/[\.&]/, $tmp_date);
if(("$prim_month" eq "$date_month") ||
("$end_month" eq "$date_month"))
{
# Begin new row for every week
print "<tr>";
# Print each day of the week in its own cell
$tmp_dt = "$prim_month.$prim_day.$prim_year";
for($tmp_cnt = 0; $tmp_cnt < 7; $tmp_cnt++)
{
# First and last lines may contain days from other months
($tmp_month, $tmp_day, $tmp_year) = split(/[\.&]/, $tmp_dt);
if("$tmp_month" eq "$date_month")
{
# Build date string
# $tmp_str = "$short_month{$tmp_month} $tmp_day";
$tmp_str = "$tmp_day";
}
else
{
# Otherwise, don't print the date
$tmp_str = "";
}
print "<td><p align=\"right\" valign=\"top\">";
print $tmp_str, "<br>";
# Check for any reservations
if($tmp_str && $res{$tmp_dt})
{
my($tmp_name);
my($tmp_email);
while($res{$tmp_dt})
{
($tmp_name, $tmp_email, $res{$tmp_dt})
= split('\|', $res{$tmp_dt}, 3);
# Make sure '@' is transposed
$tmp_email =~ s/%([\da-f]{1,2})/pack(C,
hex($1))/eig;
print "<a
href=\"mailto:$tmp_email\">$tmp_name</a><br>";
}
}
print "<br><br>";
print "</td>";
$tmp_dt = rGetNextDay($tmp_dt);
}
# And close out this row
print "</tr>";
$tmp_flag = 1;
}
else
{
# Once found, no need to process rest of dates
if($tmp_flag)
{
goto StopProcessing;
}
}
$tmp_week++;
}
# End this table
StopProcessing:
print "</table>";
print "</div>";
print "<br><br>";
}
-----Original Message-----
From: Steven T. Henderson <stevenhenderson at prodigy.net>
To: san-diego-pm-list at happyfunball.pm.org
<san-diego-pm-list at happyfunball.pm.org>
Cc: stevenhenderson at prodigy.net <stevenhenderson at prodigy.net>
Date: Tuesday, April 13, 1999 8:06 AM
Subject: greetings all!
>in our last meeting, it was decided that i would share what i know about
>code reviews. the others thought i might be able to pass along some of the
>experience i have gleened. we'll see.
>
>
>i want to keep things simple so we will be reviewing a section of Perl code
>that prints out a calendar feature of a simple app that i wrote. to give
you
>some context, check out:
>
>http://www.stevenhenderson.com/demo
>
>to give you context of the code, i have attached:
>
>1. review.txt -- actual code snippet to be reviewed
>2. demo.zip -- full source code to demo app
>
>if you check out the demo app at the URL above, this function is
responsible
>for printing out the 'month' table located in the bottom frame. this was
>written some time ago and is likely riddled with bugs, should make for a
>good review!
>
>please print out the review.txt and bring it with you. i will try and
>remember to bring extra copies, but i don't have a printer so i gotta run
to
>kinkos.
>
>
>i have been looking through my old documents and could not find a short and
>concise description of this process, so i will just wing it for your
>benefit below.
>
>
>CODE REVIEW DEFINED:
>a code review is a short (always less than 1 hour) meeting involving
>developers interested in improving programming code quality. it can be
>viewed as a 'peer review' your code is analyzed by others in your
>development group as well as other programmers outside your group.
>
>
>WHY:
>the goals for the code review is simple: to improve code quality and avoid
>potential bugs. the main purpose is to find bugs in the code you are
>reviewing, but other benefits include learning logic & process strategies
>from people smarter than yourself.
>
>WHO:
>reviewers: anyone interested in the code review. generally they are part of
>your development team and sooner or later integrate with your module. a
>'floater', or person not involved with your project should be invited as
>they often can see the forrest through the trees and can bring a new
>perspective to the table.
>
>reviewie: person hosting the meeting and who's code is under scrutiny.
>
>thus there must be at least two developers attending, and as many as 10.
>however, be cautioned that any number of five is generally unpreductive as
>it is too hard to keep the review on track.
>
>
>WHAT:
>everyone invited should be provided both electronic and hard copy of the
>code to be reviewed. this printed hardcopy should be brought to the code
>review and should be formatted in a standard way (depends on the company).
>the code review begins with a quick q&a and then proceeds to pick the code
>apart line-by-line.
>
>the meeting proceeds as every line is 'checked off'; ie: everyone agrees
>that the line is ok and no potential problems are lurking.
>
>very important: these sessions should move along as quickly as possible and
>NOT focus on stupid problems such as:
> . misspelled comments.
> . formatting style (should be standardize within the company anyway).
> . variable name choice (unless its a bug or confusing)
>
>remember that you only have 1 hour to get through the entire code segment.
>additionally, it is equally important that the reviewie does not get
>defensive when people criticize thier code. this is harder than it sounds
>when you are under the microscope, but egos must be left at the door!
>
>
>WHEN:
>a code review must take place before any ship-critical code is complete.
>generally they should occur as often as peoples schedules will allow. i
>found them much more benificial to have several smaller code reviews more
>often than wait to have a huge monolithic block of code to be reviewed.
>
>(note: in my last team, we had a conf. room scheduled every thursday at
>1:00pm. there were 5 of us and we would alternate a code review every week.
>this kept things small and we dreaded CR's a lot less).
>
>
>WHERE:
>any type of meeting place that can hold the invited parties. obviously its
>best to keep distractions to a minimum making confrence rooms ideal, but
>CR's can be held anywhere. i found attendence to my code reviews improved
>when i held them in the cafeteria and advertised snacks would be provided.
>
>
>
>don't be defensive.
>
>
>
>
>
>
>
>
>
>
>
>
>
~sdpm~
The posting address is: san-diego-pm-list at hfb.pm.org
List requests should be sent to: majordomo at hfb.pm.org
If you ever want to remove yourself from this mailing list,
you can send mail to <majordomo at happyfunball.pm.org> with the following
command in the body of your email message:
unsubscribe san-diego-pm-list
If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-san-diego-pm-list at happyfunball.pm.org> .
This is the general rule for most mailing lists when you need
to contact a human.
More information about the San-Diego-pm
mailing list