+1 > You are right that comments should explain the "why" and not the > "what". But not every single tiny little method needs to explain the > "why" of its existence. Do you think hundreds and hundreds of > #initialize methods need to explain themselves with a comment? I > don't. > >> Also a big issue I have with smalltalk in general. All this spaggeti mess I >> see unfold before my eyes in every library I see. >> One method calling another method which calls (excuse me, I should have said >> "sends a message") another and before >> you know you forget where you started and where is the end. Its the >> definition of Code Labyrinth. All this hectic browsing >> around could have been avoided so easily with a single comment. > > Your frustration about use of the Composed Method pattern is due to a > tool shortage, not a shortage of comments. Above, you're talking > about getting "lost" as you trace through senders and implementors. > When each sender/implementor either opens up a whole pane or, in some > cases, a whole new window, then yes, it's very easy to get "lost" and > forget where what you were doing due to following side-tracks. > > That's why I use Squeak's MessageTrace, it handles this better than > anything else in any Smalltalk. It is a "lightweight" way, in terms > of gestures and UI elements, to trace through code without getting > lost. I wish Pharo would consider implementing a tool like this.
Can you explain it? This is the screenshot? The top line the sender for ensureSecondaryLinkConfigured then see its senders? Its self sends? Because I want (and I was thinking about that too for long time) something like that. > >> I would like to note here that I am also a big fan of small methods and that >> my question is not related to whether methods >> should be kept small and readable but whether comments are really needed for >> those methods. >
