am i unusual (lucky?) in having to do very little of this? usually i am developing new projects or maintaining things i wrote. even when extending existing work, reading the existing code is only a small part (largely at the start).
You get the simplest code in the least effort if you solve each problem at the appropriate layer. People who never look down into the layers below them end up with lots of unnecessary duplication and cruft.
Well said. True in general, but especially when you're working on some middle layer of a large scale project, it really pays off to understand what's going on at least on the adjacent layers.
When you mostly work with your own code, do you still have that feeling of constantly improving your coding style and code quality (like looking at code that is X months old and knowing you would write it differently today)?
but also, i think it's just the nature of the work we do - typically i am asked to implement something new for a third party (i'm more a hired gun or "consultant" than part of a development team).
so probably it was a dumb comment of mine to post without reflecting more first. sorry.
ps to answer your last question - when i work on my own projects i do a lot of rework. at work i rarely get the chance, because one contract finishes and another starts. but not sure what you were getting at there.
But...
How do you use that? Once you start looking at s specific function, then you need to read that function, not see a prefix
It may be me but I just don't get it
TL,DR: No code viewing tool.
I completed a 10-week programming course (Hackbright) in SF this summer and am currently waiting for my visa to come through to come back to the Bay Area to start a job at a YC company.
There are lots of resources out there for picking up a language (or coding, to begin with), eg, codecademy, treehouse, udemy, even offline courses like Hackbright, DevBootCamp. Beyond that, what are some of the best ways to go from a programmer to a good programmer?
I find writing code a couple hours a day and working on my personal projects helpful, but only to a certain degree as I feel I am re-using a lot of my existing knowledge (or hitting some kind of roadblock).
Hence, reading more quality codes has been one of the priorities for me to keep up the learning. The major challenge though is to find good code to read. Perhaps a weekly curated "reading list" akin to StartupDigest but for coders, instead of startup related articles, they can be handpicked "codes of the week" on github / other sources? Or, do these things already exist out there?
In my experience, reading and working with bad code has proven to be extremely valuable too. Until you realize why something is bad (e.g. extremely long methods), you won't appreciate "good code". So, I suggest picking a medium-sized open source project in a language of your choice and start contributing some bug patches. You will come across plenty of both good and ugly code.
Thanks. What's the best way to find medium size (what is considered medium sized) open source project? I code mostly in python and have several repos on github/michellesun.
Edit link: http://www.stanford.edu/class/cs140/projects/pintos/pintos.h...
If you believe this (and I do), then it follows that reading fluently is absolutely critical. One cannot judge writing without being a good reader.
You don't learn to write novels without reading a whole lot of them first. And someone who hates to read is never going to be a great writer.
I disagree that any special tool support is needed. If you depend on any open source library or platform at all, just don't stop bug hunting at the API boundary. Go down inside and see what's really going on.
When you come across pieces of code that may seem esoteric, doing a "rubber ducky" debug (talk through the code line by line with ann inanimate object) on it I find helps tremendously with both understanding what's going on along with the author's mental approach to the problem.
In the event they may just not be a great programmer you can still learning something from the way they approached the challenge.
Of course anyone remote working has problems trying to do this in Starbucks.
* Express - https://github.com/visionmedia/express - I don't like TJ's coding style, and general trolling of CoffeeScript, but this is a really great, clean and tiny codebase. (As well as all the connect middlewares - https://github.com/senchalabs/connect)
* Async - https://github.com/caolan/async - is very readable. Async is a great library for async ops handling in JS, and it's really neat seeing the implementation patterns.
* Ray - is a games DSL in Ruby - https://github.com/Mon-Ouie/ray - I love it, and it's a great read especially if you are interested in DSLs as much as I do.
* Jekyll - https://github.com/mojombo/jekyll - really helped me going forward with my ruby skills. It's nice, clean, commented, not too big, and useful.
* Redis - https://github.com/antirez/redis - lots of data structure implementations. Antirez just writes C so nicely. anet.c has networking, TCP bits, ae.c is an event loop. Lots of great code there.
I'm not sure that the solution in the article achieves this in a coherent manor, and is only of relevance to one particular code repository (albeit a very popular one!), although it's never the less useful.
There is a class or two of tools that already exist and do help in this top to bottom process, doc generators and profilers (and sometimes debuggers). These work across all types of code repositories and all variations in quality of code. For instance, see the chap recently on HN who was trying to read and get to grips with a large code base [1] and my comments to him [2].
Granted these tools are versatile and go beyond just "reading" the code, perhaps there is some space for derived products which use these to create a "story" of the code from a top to bottom perspective.
[1] http://news.ycombinator.com/item?id=4557919 [2] http://news.ycombinator.com/item?id=4558801
It is a vicious cycle: if a program source code is bloated, i won't be able to read it and understand it. If I don't understand it, I won't be able to use. Being not able to use it, I will reimplement its functionality in my program. Then, my program becomes bloated.
I have tried to understand a large Linux kernel patch series by starting at the beginning and trying to go through the commits. I didn't make it far. Maybe I would have, if I had had a good tool to help (besides just git).
Businesses have been built on reading code. We (Architexa) are one such example, but there are lots more companies trying to help you browse/understand code. One of the older companies in this area is SciTools, which makes the 'Understand' product.
Beyond the above trivial point. The problem with books is that they are often designed to start from only one place (the first chapter). Blogs overcome this by letting you start reading at any post. If there really is a tool that is needed, it is a tool that helps you pick a way to start reading code. It is NOT to give you the one annointed way to read code (from where the writer started writing the code). You sometimes care about the code from the start to finish, or MUCH more likely you would want to read the code in a manner that aligns to your tasks - perhaps by seeing how the code responds to some event (by looking at the event hook), or seeing how the code uses a library or subsystem like the filesystem (by finding dependencies to the appropriate library).
Code reading/understanding is a big problem. And I am biased, but there is a lot of work that needs to be done here.
By the way, I would love your thoughts on what we are doing. Please check the video on our homepage (http://www.architexa.com/) and let me know either here or via e-mail what you think.
I think the main benefits would actually be in the area of teaching. Just have people that learn to program watch replays of stuff in the language they want to learn and pick up on certain things via patter matching :)
At the very least even pretending to record your commits (rubber duck version) could probably improve your development process quite a bit. I think I'll actually pretend to record all my commits from here on out and give a running commentary to myself :)
Google for "program comprehension tool," and you'll see there's no shortage of tools to help people read code. Rather than create another one, someone should really just look at a bunch of those and create a "Top 10" list.
That's one of the main reasons I dislike pull req squashing (or doing large compound "clean" commits in the first place). It destroys this information.
