Computing desk
< October 7	<< Sep \| October \| Nov >>	October 9 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 8

Code review tool - each source line is annotated with all the authors who ever touched/created/deleted it

Hi, is there any existing software which can show up source (such as C/C++) and annotates each source line with all the authors who ever touched, created or deleted the source line?

It may look like this. Some function pretty much like what 'git blame' provides. But according to git's man page, git blame only shows authors for a specific revision. What I want is to show a list of authors for ALL revisions (or a range of revisions) in the history. Such that we can quicky identify the potential person who broke the code during code review process and find authors in charge to discuss.

Or any suggestion about the alternative tools? - Justin545 (talk) 03:25, 8 October 2014 (UTC)[reply]

As I recall git blame will give you which author made the most recent change to a line, which should allow you to see who changed the code from non-broken to broken. If that won't do the job, git bisect will allow you to find which commit broke your application.--Phil Holmes (talk) 09:38, 8 October 2014 (UTC)[reply]

Such a tool would also have to somehow indicate missing and moved lines. For code that had been edited much it's difficult to imagine a good line-by-line visualization for its entire history.

However, you might check out [Gource http://code.google.com/p/gource/]. It at least looks interesting. APL (talk) 23:32, 9 October 2014 (UTC)[reply]

Source code available but no design documentation—how do you study the code?

Open source software comes with source code, but generally no design documentation. If you want to tweak it, how do you study the code to find out how the software works generally and what parts you will need to change? If you've done it in the past, is there a process you find helpful to follow? Are there good tools for doing this kind of code study/analysis? Thanks. --173.49.79.201 (talk) 12:07, 8 October 2014 (UTC)[reply]

It depends entirely on the project. When I worked on the open-source code for MediaWiki (the program that Wikipedia uses), I used the documentation that was available to the project. The code itself is well commented. I worked on the Linux V4L code. It had no documentation to use (at the time - I wrote a lot of it), but I knew what it did and I was able to locate the problem. I already knew what the problem was, so I knew what I was looking for. I tried to work on a bug in the nouveau driver for X.org, but it isn't commented well and has no documentation that helps developers. So, even though I know exactly what the problem is, I have to trace through the code function by function to find the location of the problem. All in all, it requires experience. I've been programming since the late 70's. It isn't hard to read through code. If you are a new programmer, it will likely be more difficult. I suggest trying it though. Being able to read code requires spending time reading code. The more you do it, the better. 209.149.115.99 (talk) 13:10, 8 October 2014 (UTC)[reply]

When I've done this, I generally open the code in an IDE and trace through it with a debugger. You can also copy some of the procedures into a new source file and try to compile and run it: this is good for revealing non-obvious dependencies. I would also Google the software to see if anyone else has modified it, since they may be willing to share their documentation or experience. OldTimeNESter (talk) 14:17, 8 October 2014 (UTC)[reply]

I find that there are a few tricks that help:

Top down - start at 'main' or the functions exposed in the API. Find what those call...find out what those call...culling out the branches of this tree that don't seem important or interesting to what you're trying to do.
Bottom up - start at some function that you can identify as a 'leaf' that does something recognizable to you...find what calls it, find what calls that...and so forth.
Find a string - for programs that display textual messages, use 'grep' to find the function that contains that string...you can generally browse up and down the call heirarchy from there.

But there isn't really a hard-and-fast way. Incidentally, it's not just OpenSource that has this problem, I've been faced with reams of undocumented code in most of the jobs I've had over the past 35 years - and it's never very easy. SteveBaker (talk) 20:46, 8 October 2014 (UTC)[reply]

What you really need is one of those ancient line printers. Print out the full code and put it under your pillow. Ponder it every few days. Change some trivial things and find out why this breaks first the build, then the program. After about 6 months, throw the program away and start from scratch ;-). --Stephan Schulz (talk) 20:51, 8 October 2014 (UTC)[reply]

Sometimes Doxygen is a useful tool in this regard. It tries to generate HTLM documentation from code itself, and from comments in the code. Ideally, if the code's comments have been written to specifically support Doxygen it can generate full documentation. But even with completely uncommented code, it can provide a useful reference. APL (talk) 23:28, 9 October 2014 (UTC)[reply]

How to split a browser page into two horizontal regions ?

One frequent problem I have with web pages is that the headings for the columns have scrolled off the screen by the time I find the item in question. Here's an example: [1]. Obviously smart web page designers would repeat the headings every so often to prevent this, but many times they don't. So, my question is if there's a way to show both the headings and the item I'm interested in, at a scale where I can read both. I'm on Windows 7, using Chrome, but could use another browser if needed. My current workaround is to do a couple screen grabs and use Paint to stitch them together, or to just write down the headings. StuRat (talk) 20:08, 8 October 2014 (UTC)[reply]

Urgh...I know what you mean! I don't know of a way to split a window in current browsers. I generally right-click the tab, hit "Duplicate" then tear off the new tab to make a new window - then stack the two windows vertically above one-another. Not by any means perfect...but better than nothing. SteveBaker (talk) 20:49, 8 October 2014 (UTC)[reply]

Firefox has two "Split View" add-ons, which allow you to split the current view into two, which is marginally better than SteveBaker's suggestion. Apart from that, unless the author uses, and the browser respects, the <thead> and <tfoot> HTML tags, I've got no other suggestions. CS Miller (talk) 09:33, 9 October 2014 (UTC)[reply]