In the book you state:
“One aspect of bindings that is easy to forget is that they are difficult to understand when you are new to a code base. It is hard to see them all at once (there are no diagrams like Figure 8.8), so learning what bindings are present can take a lot of poking around.”
Excerpt From: Hillegass, Aaron. “Cocoa Programming for OS X: The Big Nerd Ranch Guide, 5/e (Big Nerd Ranch Guides).” iBooks.
Figure 8.8: i.imgur.com/YP4zyql.png
What about if programmers start making diagrams like that, you think most companies do?
In what program did you make that diagram?
Is there any application you’d recommend to diagram code?
I would like more information on code organization and best practices for code readability, is there a book for that?
Oof. Don’t do it. Here’s why: The code doesn’t lie. My senior and mentor is against documenting in this way. Even via comments in code. Because if you’re documenting like this, as your code changes, you’d also have to document all the changes: NOT feasible! There’s no way as a programmer trying to be productive, if you were to add a property to a class, there’s no way you’d want to dig up a UML chart or some kind of chart, edit it, then get back to work. Remember DRY—don’t repeat yourself? The same thing applies here in my opinion. Don’t duplicate the amount of work—either additions or deletions to charts—that you’d have to do. A change in code leads to a change in a chart? Forget about it. I finally understand why so many fellow student complained about diagramming in college, saying none of the places they interned for used them.
