I would like to measure performance of my developers using KPI (Key Performance Indicators). Which KPI would best help me distinguish between good and "needs improvement" programmers?
For any measurement you use, programmers will figure out how to game it. The only true measure is whether they are delivering quality software on time.
I think you're better off just being an active part of the team. Don't rely on numbers, rely on actual observation of how they perform, perhaps combined with comments from their peers. If you have a well functioning team, it should be obvious which are the high performers and which need improvement.
Over the course of a year, how many times did another team member ask this person for help, get it, and still was not afraid to come back and ask for help again?
Over the course of a year, how many features did this team member ship, to customers, that are used and were relatively free of bugs?
During the last live site incident, how did this person respond? Whether or not this person was the cause of the incident.
Regardless of your current team size, if you had a team of three, would you want this person to be one of them?
Every year when I'm asked for input on my peers, this is my personal checklist for completing that open-ended space on the form for "any other comments."
This is a hard one. You shouldn't really rely on raw stats (as others have said), and relying on things like lines of code, number of bugs etc, don't really give the fully picture.
If they are assigned specific pieces of work, I would measure productivity based upon whether they are delivering work according to client expectations (100% done, not 70% etc), and contributing to the work of the team as a whole.
You can, of course, also measure sickness levels, timekeeping etc, but that's a slightly different matter.
I think the other answers have neglected an important part of your question:
"...distinguish between good and "needs improvement" programmers?"
I concur with the other answers that there may be better ways to look at this problem.
All known programmers need improvement. This isn't a binary "good" vs "needs improvement". The challenge here is to match the right opportunity to the right individual. I think KPI would be a bad fit for this; KPI are impersonal and standards oriented, and what you should be seeking is something very individual. One programmer may need to flex his skills in a new language/framework/environment. Another may need exposure to more database code. A third may need training in how to refactor their own code, while a fourth may just need some tandem time to practice coding to the team standards. My experience is that few people are comfortable asking for what they need; you're going to have to listen to them and to their teammates over time.
If you're trying to distinguish between the adequate team member and the team member who may need a performance plan, KPI will not help. (or by the time KPI reveals a result, you'll probably have dealt damage to your team that cannot be recovered. This is a John Galt solution). Listening to the team, spotting patterns of late delivery/quality problems, etc. will spot this.
Take "programming" out of the mix. If you were supervising construction workers or cooks, or circus performers or ... you'd be constantly looking at everyone's performance, looking for where they best fit on the next project, and for opportunities to improve that individual with training/coaching/whatever.
As others have said better than I, KPI are designed to detect whether you need to intervene on the project, to refine your confidence that the project will be delivered on time, to measure and predict performance at a team/deliverable level. Distinguishing between the individual who urgently needs improvement, the adequate performer who could be exceptional with intervention and the excellent programmer who you need to train to retain is a soft skill involving leadership and listening, and I'm not convinced that KPI is the ideal tool to support those activities.
Apologies if I'm stating the obvious.