Back in the days when I was learning my craft, text mode operating systems were all the rage. Well, it wasn’t so much that they were fashionable, just that there wasn’t really much in the way of a choice. At that stage, the university wasn’t even teaching object oriented languages, but at least it was teaching C!
Having been a truly nerdy child, my programming experience prior to university was restricted to self-taught BASIC . The power of GOSUB and RETURN were at my disposal, but the performance overhead of using them simply meant they weren’t exactly popular in my home-spun code. Thus, the notion of functions and procedural programming was a big step and completely new to me when it was raised in about the third week of Introduction to Programming. Mind you, I also remember how much of a big step that programming without line numbers and using something called a compiler was too!
One of the earliest lessons regarding functions and procedures (for this subject, we were using the “educational” language Pascal, after all) was we were taught that each function should do one thing and one thing only. As a guide, we were given the following metric:
Each function should be no more than two screens long.
This actually meant something on text-based screens. For the benefit of you young whippersnappers still humouring the old-fogey by paying attention: that meant each function had to fit in 80 columns by 50 rows – tops.
These days, a lot of programmers I deal with still pay lip-service to this notion of keeping functions short / readable / single purposed. Despite this, there seems to be an awful lot of functions with an awful lot of code in them.
Short, readable, concise functions still make a lot of sense. I’m sure, just like middle aged spread, code bloat is assisted by laziness. Where multiple people work on the code-base, the responsibility for keeping the code in tip-top shape should fall on everyone’s shoulders, but without the right team dynamics and encouragement it’s easy for this point to be lost. When that happens “code improvement” tends to cease – functions get longer, they get subverted for other causes – in short, they get less maintainable. Next time you maintain a function, don’t be a lazy programmer.
Graphical editors don’t have the restrictions of 80 x 25 that the old text mode editors did. Fonts, designed for readability on LCD monitors can throw an amazing number of characters on one screen full. Using eight point Consolas font, on a 1400 x 1050 pixel LCD monitor, I have no problems getting 226 columns and 67 rows on one screen. How much bad code can someone shove on a screen now?! The fact that the text is readable on a 14 inch laptop screen doesn’t mean that the code will be!
Something I do when I code, (which seems to fly in the face of convention) is to run a big goofy font in my IDE… Next time you are writing code, try running 13 point Courier New (or similar). I dare you. In all the years I have done so, I’ve never been tempted to write hideously long functions and have never found maintaining existing ones a “pleasing experience”. That’s exactly the sort of irritation you need to inspire you to keep the code neat and tidy. I will warn you though… When you first switch to “big and goofy” it will offend you. Be prepared to squint at the monitor in shock and horror (as opposed to squinting because the text is so small). Give it the benefit of the doubt for a couple of days and let me know how you find the experience…