checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry?
The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster.
HasaniK and Jakub have already identified some very valid reasons as to why it is unfair. However there are some very serious considerations to be given to the implications that can emerge as a result of introducing this as a performance related metric.
Using LOC (and in fact any other sort of linear metric e.g. bug fixing) for assessing the productivity or performance of engineers is fundamentally flawed, it essentially penalizes desired behaviors such as refactoring. If I developed a function point and committed 350 LOC to do so then I review it, perhaps after some collaborative work with a peer and discover it can be done in just 150 LOC am I going to do it? Unlikely if it’s going to impact on my perceived productivity or performance.
One of the worst examples I've ever seen in place was the use of both LOC and bug fixing as performance metrics, this essentially encouraged developers to commit reams and reams of appallingly buggy code and then fix their own bugs! Not exactly conducive to increasing velocity and quality.
In my view this approach can single-handedly be responsible for creating a culture of poor quality design, code, and documentation as engineers become increasingly focused on the committal of code rather than robust and sound design, collaboration and innovation. I've seen good teams of enthusiastic and quality engineers be converted into unenthusiastic robots dedicated solely to delivering what they consider to be the expected measure each day.
Needless to say that I left the organisation mentioned as soon as was humanly possible and since then have made it a point to ask at every single interview since then what PAR framework is in place, how can I expect my performance to be measured? If LOC is mentioned then I thank them very much for their time and if offered the post politely decline their kind offer.
I've personally found the best PAR frameworks for developers to be largely subjective, the use of 360 reviews can help to ensure that the desired behaviors e.g. communication, teamwork etc. are being adhered to and identify opportunities to improve (ensure that the 360 reviews contain feedback based on demonstrated behaviors and are not ‘complaining’). Code and documentation review are a genuine and unbiased method of measuring quality, completeness and accuracy of output.