6 ms·
Functions should be short and sweet, to an extent, because by thinking in terms of functions you're building a new language in which you write your program. If
by yason 13y ago
Functions should be short and sweet, to an extent, because by thinking in terms of functions you're building a new language in which you write your program.
If you're writing big functions by habit then you're just laying more code after existing code to build a program. If you split your code in functions and, instead, start talking in the language you've just invented then you're composing a program. And I think compilers should do the building while I refrain myself to composing.
Of course, one-line functions don't have inherent value but sometimes they're needed. For example, to present a higher-level concept that just effectively happens to be a simple assignment or an inc.
Short functions themselves don't have an inherent value either: if you manage to write your function with less tokens, possibly due to composing it out of other functions, then that's all good but isn't the real value of doing it. Shortness for the sake of shortness only matters until you're down to a screenful or so.
The real value of defining and writing functions is thinking of the proper words for your language. As soon as you're making your own language, then you're just using functions as vehicles to represent words in that language. Some words might take 30 lines to code, some words might take 3 lines. It doesn't matter as you've got your language together in a way that is concise and beautiful which is the real point.
- jboy 13y agoThis is an excellent answer, and (in my opinion, at least) really gets to the heart of the matter. I'm not unduly obsessed with classes or design patterns in object-oriented languages, but to me the key benefit of functions, classes and design patterns is about defining a shared language of named abstractions. These abstractions take care of details, so you can think at a higher level. The names are a common vocabulary shared between the designer/implementer and user/client of the code; and as yason says, if you choose your abstractions at an appropriate level, you can "talk about" (or describe/define) the problem+solution in terms that are best suited to the problem+solution. And to note one more benefit of short functions: When you're talking about functions (operations) and classes (encapsulated state), you rely upon these abstractions to behave in a certain way. Shorter functions and simpler classes generally have fewer moving parts, thus making it easier to verify the correctness of the implementation of the abstraction concept.
- sergiosgc 13y agoExcellent answer. Another view (dual and equivalent) is that you are climbing the abstraction layer. You should do it with clean abstractions, that do not leak. It's easier to write clean abstractions if they are limited in scope, so it is better if each function does one thing and does it well.
- TeMPOraL 13y agoRight to the heart of matter. This is something Abelson & Sussman were trying to teach us in the 80-s (stacking abstractions-as-languages on top of each other is one of the main themes of SICP). Unfortunately this insight got somehow lost in between people parroting design patterns and repeating things without understanding them (programming pop-culture?). I've personally seen only a handful of programmers who know of this concept, and even less of folks who understand it.
- aufreak3 13y agoI disagree with supporters on the value of this comment and of the OP as well. Though the naming seems to give documentation benefits, naming variables and functions is one of the hardest things we do as coders. The practice of properly factoring your system comes more out thinking in terms of values rather than steps. When you think "what value am I computing?", you not only write short sweet functions naturally, but also build more robust code in the process. And yes functions are values as well.
- e12e 13y agoGreat comment. This also fits nicely with vpri.org's work on 20KLOCs for the whole system (possibly including logic gates). I'll just borrow this other great comment on vpri that I found googleing for the approriate vpri.org link: https://news.ycombinator.com/item?id=3292663 https://news.ycombinator.com/item?id=3292663
- jbeja 13y agoThis comment make so much sense to me.