According to a computer science teacher, it is beneficial to create methods that fit within a single screen. While I understand the importance of crafting concise and straightforward functions that can be easily comprehended at a glance, the question arises: why is the limit set at precisely one screen? How should one approach writing a switch-case condition with multiple lines of code or handling substantial hardcoded data?
2
- 3$\begingroup$ One size doesn't fit all. What matters is legibility. and sometimes creating more space helps. $\endgroup$A.bakker– A.bakker2023-11-27 11:20:07 +00:00Commented Nov 27, 2023 at 11:20
- 1$\begingroup$ I haven't heard the "one screen" function size limit recommendation before. This seems pretty arbitrary. Nowadays, with high res vertical monitors, "one screen" can probably fit 500 lines of code or more. In general, it's good to approach any sort of one-size-fits all rule like this with suspicion. Regarding the switch-case question, usually use a lookup table in whatever language you're using, preferably populated by raw data (JSON, typically). But it depends on your specific use case. switch-cases may be calling functions rather than accessing simple data. $\endgroup$ggorlen– ggorlen ♦2023-11-27 20:23:05 +00:00Commented Nov 27, 2023 at 20:23
Add a comment |
2 Answers
$\begingroup$ $\endgroup$
There are lots of different coding standards. Typically, every workplace and project tends to have its own. So, "fit within a single screen" is not a universally-adopted guideline, but something that can quite plausibly be chosen regarding method size and complexity.
While I understand the importance of crafting concise and straightforward functions that can be easily comprehended at a glance, [...]
That's the point. If you allow for methods to exceed the screen size, it's no longer possible to even see all of it at once.
Of course, "screen size" is hard to define. Which screen resolution? Which font and size and line spacing? How much space dedicated to task bar, window frame, toolbar and so on?
It's all about readability, and these rules should be taken as guidelines. Typically, in a method that spans e.g. 100 lines of code, you can identify subtasks and give them names that describe the task, i.e. to introduce methods for these subtasks.
Or from another point of view:
By introducing classes and methods, we create the problem-specific language that we want to use when writing our higher-level solutions. Don't take the language as a fixed thing. No, every class and method that you write adds a word to the vocabulary of your problem-specific language, and it's your choice what that language finally looks like.
So, if there is a method that you do not like (e.g. because it is too long or otherwise too hard to understand), then:
Either this method in itself does too much. As a hint, look at its name. Is that a word that you would like to have in your vocabulary, expressing some concise action? Or is it a mess of things that just accidentally happen one after another in a given program?
Or the steps necessary to fulfill its jobs are just so complicated that they cannot be expressed in a few lines, using the language at hand. If you were free to invent your own language, how would you write the method? It's quite possible that you can come close to that language, by introducing the appropriate methods and letting the method under consideration call them.
To your concrete questions:
A switch-case condition with multiple lines of code, I'd break down in one method call per case. E.g. in a
paint()method that switches on type, the methods might becomepaintRectangle(),paintLine(),paintCircle()and so on. Then thepaint()method still has the switch-case, but the individual blocks are only one-liners now, with a name that clearly states their purpose.If you need substantial handcoded data, make sure the array/structure/whatever gets a name, either by making the data a constant or a read-only static field (whatever your programming language calls it) or the result of a
createMyHandcodedData()method. And if it isn't obvious why the data have exactly the content you handcoded, explain it in a comment.
$\begingroup$
$\endgroup$
There is an issue beyond screen size that is important to consider. In fact, "screen size" seems awfully long and would be for the (Java, Python,,,) code that I write. Anything longer than five lines or so is too much and much (not all - see below) of my code is like that. But, it isn't artificially broken up just to be short. Each method captures a single idea and the code isn't complex (no/few nested structures for example). The complexity is in the interactions of objects.
The real problem is that our minds have a limited ability to juggle deep complexity with many parts. But deeply nested code structures are like that, so writing short(er) methods makes it harder to exceed the magic rule of seven. Then keeping a method to a single page (actually much less) is easy and natural.
So, I would state a somewhat different rule for my students: minimize the nesting of code in any given method. If it is more than two it starts to be harder to grok and easier to introduce errors. That is also the KISS principle.
So, while it is useful to be able to see a method all at once without scrolling, the more important thing is that you can understand the method yourself without needing to take notes or re-consider or wander off into dead ends.
Some code doesn't work that way, however. The logic of a program can usually be constructed with (very) short methods using modern design patterns.
But GUI code, depending on pre-built libraries is often long and fairly boring. There may not be much structure to the code, but it can require long sequences of statements to build a user interface. That code can be long (pages, perhaps) but is easy to understand.
Note (joke) about short methods. Have a team of 10 people write a 1000 line program by having each person write 100 lines, independently. Person A writes the first 100 lines while person B writes the next 100 lines, etc, all together.
