7 ms·
At my last job I wrote a script to walk over git-log and add up all the line number differences (skipping merges). By the time I left, my net code contribution
by zwegner 13y ago
At my last job I wrote a script to walk over git-log and add up all the line number differences (skipping merges). By the time I left, my net code contribution was something like -290kloc. I was the only person with a net negative, though it was a smallish team.
With the sheer amount of bad code people write, I expect to do a lot of deleting, refactoring, and rewriting, and I'd hope managers/fellow team members would be able to see the value in that. But sadly, they usually don't.
- taybin 13y agoI'd like to see that script.
- rav 13y agoHere is a sample implementation: git log --author=rav --numstat --no-merges --pretty=format: | awk -e '{ a += $1; b += $2; } END { print a; print b; print a-b; }' produces this output (sum additions, sum deletions, net line additions): 112529 85383 27146
- zwegner 13y agoHa, nice, there's two options that definitely would've simplified my code (--numstat and --no-merges).
- porges 13y agoTo count by author: git log --numstat --no-merges --pretty=format:%an | awk ' author == "" { author = $0; next } /^$/ { author = ""; next } { added[author] += $1; removed[author] += $2 } END { for (author in added) { print author, "added", added[author], "removed", removed[author], "sum", added[author]-removed[author] } }' | sort -n -k 7
- taybin 13y agoThat is great! Thank you.
- zwegner 13y agoUnfortunately I forgot to grab it off my work laptop when I got laid off. I would've liked to have stuck it up on github... It wasn't really all that tricky though, it took me a few hours to write. git-log has options for only displaying the status line of diff-stat for each commit, and then displaying the parents of each commit, and the author. You look to see that there's only one parent (so it's not a merge), parse out the X added, Y deleted numbers, and stick them in a dictionary keyed by name. A lot of the script was just getting statistics like average/min/max/stddev line counts, and printing them nicely.
- jw2013 13y agoSome people just don't understand that it's harder to maintain the code than to write new ones. They are probably not appreciating your refactorizations because they have not got to a point that it is almost impossible or super hard to write new code because the codebases are a large mess (they probably haven't got to this point because of your great refactorizations). But one day when they reach that point, I think they are probably going to miss and appreciate your past work.
- PaulHoule 13y agoPeople also leave dead code around instead of deleting it. That dead code is poison to the maintenance programmer because he's spend plenty of time trying to understand what role it plays in the system of tracing a complicated bug. I'd say it is open season on commented-out code. If code has been commented-out since a few weeks it is good to delete it just as a matter of course.
- aparadja 13y agoThis is actually one of my favorite things about version control. If I know it's been committed at one point, I can delete anything and breathe the sweet air of clean code.
- clarry 13y agoBut how does the next guy know it's been committed at one point?
- jballanc 13y agoYou should never commit commented-out code. That's what version control is for. If you need that code back, just fetch it from the repo.
- wmil 13y agoThis is a bit of a tangent but I've been on teams that demanded you rebase everything so that there's a linear history. Of course this leads to nasty conflict resolutions, so they solve that by squashing all of their commits before rebasing. Now your code is no longer in the repo.
- zwegner 13y agoWell, I definitely prefer the rebasing route, but with the caveat that everyone's working on the same branch, so there's not much divergence. The only rebasing occurs when somebody commits before you do, and it's only your own local commits that need conflict resolution.