info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CVS and assesment


From: jrsmit2
Subject: RE: CVS and assesment
Date: Mon, 4 Jun 2001 11:37:13 -0500

>I fail to see why some(?) programmers are so reluctant to have their work
>analyzed and assessed. I'm a programmer myself, and I'm pretty sure that
>such a tool could benefit good programmers and maybe expose the bad seeds.
>Sound competion with fellow workers has never hurt anyone. I mean, a lot of
>employees out there have their work scrutinized and analyzed every day. Why
>should we be any different? Do we think we are irreplaceable no matter how
>much and what we actually do?

I think that point is that a script which did what you mention both
encourages bad practices and creates poor metrics.

>programmer is forced to check in once a week (preferrably with a specific
>tag indicating that the files are possibly untested/uncompilable). 

I have a hard and fast rule that programs checked into a repository are
tested and compilable.  You dis Extreme Programming in your message, but the
key quality control assessment in XP is that at any given point, the system
be buildable and runnable, albeit not with complete functionality.  All hell
would break loose in our development environment if people were checking in
code that didn't compile or wasn't tested.

>Properscripts could analyze the code regarding inter alia number of
>lines/words/bytes, 
>the scripts should also take into account the state of the
>archive last time the scripts were run, and analyze/provide statistics
about
>the change.

What would be the purpose of these metrics?  What quality increases could
such statistics provide?

>commenting, commenting rules, coding-rules, class cohesion, method-length,
class-length, parameter names, variable names.

I will agree that it might be good to have a wrapper script or tool which
warned of these issues BEFORE the changes were committed.   Better yet,
even, to run such a tool prior to CVS's involvement.

Having a developer check in potentially bad code so that another party can
judge "how good" a developer he/she is runs counter to how I feel a good
software development process should operate. 

Jer Smith







reply via email to

[Prev in Thread] Current Thread [Next in Thread]