2 ms·
I think that Yegge might have been somewhat inspired by a programming style that was widespread in Google at least when I worked there: get as much code into e
by bborud 15y ago
I think that Yegge might have been somewhat inspired by a programming style that was widespread in Google at least when I worked there: get as much code into each screenfull as possible.
I've worked with a lot of different programmers over the years. Some are capable of "running" large pieces of code in their head, keeping track of state transitions. Some need a more structured approach so they can concentrate of fewer moving parts at a time. I can to some degree keep lots of code in my head, but I know that the chance of mistakes increases when I do. It is a useful skill to have, but an exhausting and error prone way to work, so I prefer not to.
When I read my own code, I don't really read it as such. I scan it. Often can often look at just the silhouette of a paragraph, a method or even a class to be able to tell you what the code does. I tend to do "one thing per paragraph" -- which when I read code means that I can skip past the code I am not interested in at the moment quickly.
I often notice how other people actually read code, and it makes my skin crawl. I can't watch. It is so SLOW.
Yes, getting more code onto each screenfull is great -- but not having to read the code will always be faster.
- Roboprog 15y agoPut the comments above the routine, and try to keep the routine statements/expression/code to about one screenful of code (give or take, needs vary). Make the routine/function so that it indeed does one thing, and you can tell what the inputs and results are. Should you ever need to debug, you can check the data and avoid the internals until you know that this is indeed the broken routine. Contrast with the mega-routines that one of my former coworkers calls "stir the pot". Those are just broken by (lack of) design, and no commenting strategy can really fix.
- bborud 15y agoThis depends a bit on the type of comment. If we are speaking Java or something that uses the method comment to generate documentation, the documentation comment should not concern itself with implementation detail. However, documenting all pre- and post conditions as well as any side-effects is a good thing. (It is important to know when you are documenting the API and when you are saying something about the underlying implementation -- and what you should say. Again, the goal is to anticipate what will help your users or maintainers that come after you do the right thing). Occasionally you will need to make some comments regarding the implementation, and I usually make those comments at the start of a code paragraph. Usually to clarify intent when the intent can be misunderstood (to counter "I know what the code does, but not what it tries to accomplish"). Keeping methods short is a good thing, but I'm not dogmatic about it. Though I am allergic to long methods; occasionally there are methods that become even harder to read if you chop them up into lots of small bits. In that case guard-based programming and making use of paragraphs in your code really does help.