Dividing Code
quietus writes:
Programming style is not a matter of efficiency in a program. It is a matter of how easy it is to write or read a program, how easy it is to explain the program to someone else, how easy it is to figure out what the program does a year after you've written it; and above all, style is a matter of taste, of aesthetics, of what you think looks nice, of what you think is elegant.
Although style is mainly a matter of taste, a programmer with a "good" style will find his programs easy to write, easy to read, and easy to explain to others. ...
In particular, you may have acquired special programming tricks that you are very fond of, and that aren't used by other programmers, but that don't make your programs much more efficient. I urge you to stop using those tricks. As Samuel Johnson once said, "Read over your compositions, and when you meet with a passage which you think is particularly fine, strike it out."
In other words, make your style simple, not complicated, even though the complicated style may seem to have some abstract virtues. ...
(F. Black, "Styles of Programming in LISP," in The Programming Language LISP: Its Operations and Applications, ed. E. Berkeley and D. Bobrow (1964), p96 (p106 of the PDF))
When teaching an algorithms course, Craig Partridge, of Colorado State University, discovered that his students had little to no idea of how to divide their code into functions. So he wrote a short guidance paper (pdf).
What other advice, oh battle-hardened developer, would you give starting-out programmers/developers about how to approach a project/codebase?
Read more of this story at SoylentNews.