5 ms·

>When I'm stuck with a hard refactor to do, I like to print out all relevant files, take coloured pens and highlighters and keep drawing and annotating code unt

by Morgawr 12y ago

>When I'm stuck with a hard refactor to do, I like to print out all relevant files, take coloured pens and highlighters and keep drawing and annotating code until everything is clear in my hand. Paper is simply superior in annotating capabilities and high-level view (i.e. spread 20 pages in front of you to see everything). I haven't found any tool yet that would make doing this on computer even comparable. I can't agree more. I tried several ways to get a better overview of projects I work on, but ultimately it's all very klutzy and awkward. When you have 30 (or more) files with cross references and you need to get a global understanding of the whole architecture, working with code can be very hard. Even with visual tools like UML diagram or similar IDE features, even when ctrl+clicking offered by various editors to jump to definitions and jump around code, even with ctags and multiple buffers open in vim. I tried working with 4 screens but my eyes have to move all over the place to keep following, I can't easily re-organize my files next to each other to keep relevant portions of code close together (regardless of logical modularity in my implementation). Paper is really the best we have at the moment, maybe a more modern environment in the future will solve this (I recall LightTable promising something similar where you could move around small blocks of functions, during their Kickstarter, however that was never delivered unfortunately), but for the moment we are stuck with paper.

m_mueller 12y ago
Isn't it better to just draw a diagram and write by hand though? The process of mentally filtering out what's irrelevant to the problem is important as well I think. By the way this is one reason why I like big cubicles as programmer workspaces so much, you have lots of space to hang up your drawings to the sides of your screen.
ultramancool 12y ago
I think this is sort of the fact that IDEs are signed primarily for writing code, not for understanding existing code. If you look at a reverse engineering tool like IDA Pro, despite working with lower level code, you get powerful understanding tools, excellent cross referencing and diagram generation tools, graph views of code so you can see every decision made without having to read them all out and now even stuff like "proximity" view, which gives a nice way to understand calling structures. http://www.hexblog.com/?p=468 http://www.hexblog.com/?p=468

by Morgawr 12y ago

m_mueller 12y ago

Isn't it better to just draw a diagram and write by hand though? The process of mentally filtering out what's irrelevant to the problem is important as well I think. By the way this is one reason why I like big cubicles as programmer workspaces so much, you have lots of space to hang up your drawings to the sides of your screen.

ultramancool 12y ago

I think this is sort of the fact that IDEs are signed primarily for writing code, not for understanding existing code. If you look at a reverse engineering tool like IDA Pro, despite working with lower level code, you get powerful understanding tools, excellent cross referencing and diagram generation tools, graph views of code so you can see every decision made without having to read them all out and now even stuff like "proximity" view, which gives a nice way to understand calling structures. http://www.hexblog.com/?p=468 http://www.hexblog.com/?p=468