17 ms·

The 80/24 Rule

170 points by nreece 7y ago

AdrienLemaire 7y ago
> You've probably heard about the 80/20 rule, also known as the Pareto principle. Perhaps the title lead you to believe that this article was a misunderstanding. I admit that I went for an arresting title; perhaps a more proper name is the 80x24 rule. You got me there. The 24 lines convention is interesting. Made me realize that linting rules exist for function length: javascript: https://eslint.org/docs/rules/max-lines-per-function https://eslint.org/docs/rules/max-lines-per-function Can't find the equivalent for python though
whoisthemachine 7y ago
I prefer 120 characters of width, modern monitors are wide-screen, I think it's ok to adjust a little to accommodate this reality.
- mclehman 7y ago
  My monitor may be widescreen, but my editor typically isn't.
- JonathonW 7y ago
  Same here; 80 characters just feels too narrow to me in most cases. I'd rather see 100 or 120 characters of width and be less constrained, at the expense of maybe having to scroll if I've got multiple files open in my editor. I also usually run my terminals at 120 characters wide, FWIW.
  - AstralStorm 7y ago
    It's not like 80 is a hard width limit. The rule exists mostly to limit nesting and not text. More (nonredundant) text is better to a high degree. Likewise 24 line height limit should not include proper comments.
- gorgoiler 7y ago
  If you haven’t already heard the counter argument, then it’s less about screen width and more about being able to view multiple pieces of code side by side (split window editing, and side by side diffs for code review.) It’s also important to accommodate people wanting to do this with large type sizes, which becomes important as eyesight deteriorates.
  - manicdee 7y ago
    All the editors I use have supported soft wrapping, so line length isn’t such an issue. For me it’s mostly about being able to grow each line of code without frying my brain like Perl’s leaning toothpick syndrome does.
    - mark-r 7y ago
      I find wrapped code much harder to read, unless it's indented properly. The wrapping breaks the flow.
    - babuskov 7y ago
      I hate soft wrapping. It makes the code much harder to read and reason about. Especially if someone else wrote it. I rather choose to scroll to the right to see long lines when needed.
    - manicdee 7y ago
      (Extremely late edit: “grok” not “grow”)
  - PunchTornado 7y ago
    On most monitors today you can still have 120 characters and see 3 or 4 side by side tracks including the filesystem in another track.
    - forgottenpass 7y ago
      How big is "modern" these days? I have a multiple 22" 1920x1080 screens instead of one huge one, and after making the font as small as is still comfortable at my viewing distance I get 202 visible columns in maximized VS Code. At a still-workable but small enough size that I'll start unconsciously hunching at my desk I can get up to 271. Common laptop screen sizes are even more constrained. I also like to have one monitor turned to 1080x1920 for text editing and consoles. I'd never try to do a side-by-side diff on it, but it really makes you see just how many GUIs are downright wasteful of horizontal space.
- rypskar 7y ago
  You don't even need a wide-screen monitor for that. I like to turn my coding screen 90 degrees, to portrait mode, to get more vertical space and still can see the line at 120 characters. I call it the TIE-fighter setup, the screen in the middle is in landscape mode and the two others are in portrait mode, gives a lot of screen-space without having to turn the head much to see it all
  - bransonf 7y ago
    This is my favorite monitor configuration and now I have a handy name for it, thanks!
  - IggleSniggle 7y ago
    I also prefer the TIE-fighter setup, and didn't have a name for it until now. However, I find that 120 characters is too wide as soon as you want to do anything other than code on that screen.
  - enriquto 7y ago
    > I call it the TIE-fighter setup, I have the exact opposite setup, with the vertical screen in front of me. How would you call that setup?
    - lvturner 7y ago
      Inverse TIE-Fighter?
    - VistaBrokeMyPC 7y ago
      Satellite setup! (side monitors are solar panels?)
      - enriquto 7y ago
        not as awesome as "TIE fighter setup", but it does the trick
    - rypskar 7y ago
      Maybe Dumbo setup? The outer screens would be his ears. Not happy with the name, but best I could think of today. I'm a developer, so by definition bad at naming stuff. TIE-fighter setup is the lucky exception
- clarry 7y ago
  I'm using a 30" widescreen monitor and 8pt font. I get four tmux panes side by side, each with a little over 100 characters. I think getting an extra pane is worth way more than getting extra 20 characters of width per pane for the occasional long line. If it were up to me, I'd be happy to add a fifth pane and go for 80 columns. Unfortunately people at work picked long naming conventions and they're also writing massive functions with deep nesting :( I'd actually encourage a 80-character limit and deep indents (at least 4, preferrably 8 spaces) if only to force people to give their code better structure. I don't have a problem with long functions as long as they read straightforward, like a recipe from top to bottom, without too much branching and looping and jumping around. Unfortunately these massive deeply nested functions tend not to read straightforward at all.
- ProZsolt 7y ago
  I prefer 80/120. I try to write 80 character lines, but occasional 120 lines are accepted.
disposedtrolley 7y ago
A reasonable line width contributes so much to readability. While I'm fortunate enough not to experience much of it in the code I read, I do see a lot of websites which grossly violate sane line width rules by stretching the body text to the full width of the browser (looking at you Wikipedia ). Take https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity as an example. Edit: Martin Fowler's blog (https://martinfowler.com/ https://martinfowler.com/) is probably a good counterexample to this.
gorgoiler 7y ago
I love this. For as long as code needs to be maintained, code will always be just as much about communicating with people as it is about people communicating with machines. One thing I still enjoy about message passing OO (by which I really mean Ruby) is how it’s really easy to separate concerns to the extent that each file contains one module/class with one public and a few private methods in it. I went a bit bonkers this year and found myself doing one method per module, which is the extreme version of this. Languages with mixins are great for this too. Mixins are, amongst other things, a nice shortcut around composition that lets you put individual facets of functionality in separate files, albeit with fewer guarantees about code remaining uncoupled. It’s a shame Ruby’s module system doesn’t better support private for modules though.
- Gunax 7y ago
  According to the SICP “Programs must be written for people to read, and only incidentally for machines to execute.”
- ajnin 7y ago
  I don't see how splitting code in multiple modules makes it easier to communicate to others. It forces you to constantly switch places, which, knowing the limitations of the brain with regards to short term memory, would make it harder to keep a mental model. With mixins you don't even know where a particular function might come from, must be a nightmare following a trail when you don't know the code.
tylerl 7y ago
I first saw this in the Linux kernel style guide back in the 90s. The idea was that you should be able to read a function without scrolling. So that meant it would fit on screen in a standard terminal. It's a bit extreme for practical use, but the concept is important to keep in mind. I was helping a Jr programmers with a code review a few months back. He'd been told that a particular chunk of code was "unclear", with specific emphasis on 4-line bit of logic in a 30-ish line function. He had no idea how he could make the code "more clear". It did what it did; the logic was a bit complex but the code was exact and correct. The solution: factor out the 4 lines of code into a function. It was only ever called from that one place, but by making it a function you give the code a name, with clear inputs and outputs. Nothing changed about what the code did, but it became a lot easier to reason about. It's a helpful lesson that generally doesn't really sink in for the first few years.
- Gunax 7y ago
  Do you think that's a good practice? I have always been conflicted. For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable. But sometimes it just is easier to move a bunch of crap to a function and abstract it away.
  - vivekseth 7y ago
    I’d bet that the compilers mostly commonly used would probably inline a function only used once. If not, many languages provide an `inline` keyword to tell the compiler to in-line the function directly. Even if there was no way to inline a function, I tend to prefer code that is easy to understand over code that manages to shave off a few extra instructions. Code that is hard to understand will be hard to maintain and can lead to bugs in the future.
  - usr1106 7y ago
    > For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable. Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue. That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does. Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.
pubby 7y ago
I've seen this idea cargo-culted way too often. There's nothing wrong with long functions. In fact, long functions are often easier to grok than ones split apart into dozens of pieces. Create useful abstractions. Don't create abstractions for the sake of creating abstractions.
- bransonf 7y ago
  I share your sentiment. Some of the programmers I’ve worked with would build functions for every thing within a larger function. Need to chunk the data? Function. API Call? Function. Parse the response? Function. So I asked: “Are you ever going to use these internal functions for anything outside of this function?” And their response was: “No, but it makes debugging easier.” It does not. It makes it exponentially more difficult. Maybe I just work with too many terrible programmers...
  - enriquto 7y ago
    I have the opposite philosophy. The ideal function is only called once. If it is called more than once, I have a "call diamond" instead of a "tree" and this is a code smell.
    - raxxorrax 7y ago
      Harsh constraint. Probably difficult to come up with new sorting algorithms or substitutes for basic arithmetic functions after a while.
      - enriquto 7y ago
        I mean for functions that are called in the same context. Obviously external and well-abstracted functions can be called several times.
  - Nition 7y ago
    One middleground option if you have a long function but also want to break it into chucks for easy readability: In C# and some other languages you can put braces around a block of code without actually having any condition on it. Or just throw some big comment headers in.
dimino 7y ago
I cannot overstate how important this concept is. Write code (and DESIGN SYSTEMS) that fit in your brain, because the faster you can reload it back into your brain, the quicker you can dispatch bugs and new features down the line. Nothing in my professional career has caused me more anxiety than encountering complex code to solve a simple problem. It's infuriating, and has long lasting deleterious effects for the life of that code. What's especially insidious about this problem is that for folks who value short term success over sustainability, they'll struggle with this for a long time, and have all kinds of reinforcement to be skeptical that any of this is even a problem. Once you get used to struggling with complex code some people start to think it's all that can be written.
- NohatCoder 7y ago
  Artificially slicing up functions does not make the code fit in my brain, it just means that I have to load in more functions in order to have the required context.
  - dimino 7y ago
    Definitely, which is why doing it just to get small blocks of code won't work. It has to be part of the entire design, and sliced at real, logically separate spacings. It's hard! But immensely rewarding if you get it right. You have to be thoughtful as you design and build.
User23 7y ago
This is one of those things that is older than the printing press. We learned a long time ago that there is a more or less optimal column width for text and it's based on the physiology of the eye. I haven't been able to find a great reference online in a brief search, but this[1] has the basics. [1] http://maxdesign.com.au/articles/em/ http://maxdesign.com.au/articles/em/
alkonaut 7y ago
I have started to move in the other direction for C#. A long sequence of code that flows in one direction should be kept in one method if possible. Good reasons to break up a method are things that are not readability but other things such as re-use testability. If the methods are only called in one place and not performing a piece of work that is testable, then they shouldn’t be methods. But DoAll() { DoA(); DoB(); DoC(); } Is simply not better in any way than DoAll() { // A ... // B ... // C ... } Private methods will blur this somewhat. The key to readability is not having to jump around. Ideally of course methods are both short and reusable, readable without jumping etc, but given the choice between a 100 line method or the same code broken into 10 methods of 15 lines each (yes, more lines), where each method is only called once from a main method, I’d rather read the first. The 100 lines might indicate some other problem with the api (a chatty Dx12/win32-like API for example). This obviously varies from case to case, I think one of the worse things a team can do is enforce hard rules that invariably lead to “style rule-induced damage”.
- wruza 7y ago
  IDEs could make it readable and encourage to split code without splitting perception. A solution is: allow calls to be ▶expanded inline in the source view, as if it was written here* Renaming arguments to their caller-site counterparts would also help. * Code folding is not the same thing, as it doesn’t eject scope+args out of the “caller” and cannot be used in expression. Upd: I also would like to add that sources lack usual style formatting. //-sections usually should stand out, but one can only make comment bigger (2-3 lines with === filler), but not the text itself. It would be nice to have some rtf in code and css in IDE. Books are written like that, and that’s well-acknowledged way to structure instructions and descriptions.
  - eitland 7y ago
    > allow calls to be ▶expanded inline in the source view, If I understand what you mean, Visual Studio Code allows this. I guess Visual Studio does as well. The implementation feels a little clumsy to me, but hey, I'm the guy who thinks Netbeans and Eclipse where the best IDEs I've used, so I guess a bunch of you guys will think the solution is perfect.
Mikhail_Edoshin 7y ago
I find this an artificial metric. Normally code just gets split organically as you notice that you can reuse this bit here or that bit there. Some functions won't split and that's OK. (Reference to the 2k-plus-line main interpreter loop in Python.) Actual reuse is the primary drive for this. Trying to adhere to some other concept instead is dangerous. I've lost countless hours trying to make code "properly object-oriented", or "isolated", or "pythonic" until I realized it's all a delusion.
- jfengel 7y ago
  It wasn't always artificial. When you really were working on a screen that showed 24 lines of 80 characters, it was a good practice to be able to view your entire function at once. That was especially important since at the time we lacked tools like debuggers, and so there was more focus on being able to find bugs by reading. Today the hardware improvements make those numbers obsolete, but the numbers were picked in the first place because a "screenful" was picked to be a reasonable amount of information to handle at one time -- not just for code, but also for code. I was never religious about the rule, but it still feels like a good code smell to keep an eye on. If a function gets too big, I start wondering if it's really still doing one thing.
stefanfisk 7y ago
John Carmack's take on this seems a lot more sensible to me: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
wruza 7y ago
The question is, why didn’t the author write his article in smaller 50-word block tree, conveniently connected by a-hrefs and/or separated to multiple pages, all links well named. It is a straight wall of text instead, that is hard to follow and using implicit references all across.
- stefanfisk 7y ago
  <3
- fuzzy2 7y ago
  Oh but maybe he did. It's just that you're looking at the compiled version.
- cjfd 7y ago
  Actually, the more technical a text is the more likely it is to contain references and (sub)headers. Also, I certainly would not describe this text as a 'straight wall of text'. A straight wall of text would be a text without paragraphs or headers.
  - BigJono 7y ago
    Breaking text up like that is the equivalent of chucking some line breaks in a function and a few comment headings, not creating a bunch of pointless functions and scattering them around the file (or codebase).
- joelfolksy 7y ago
  1: a very good 2: That's 4: question Comment: 2 1 4.
js8 7y ago
I prefer another rule for short functions. You should be able to explain what the function is doing in one sentence. If you need two sentences, you should break it into more functions. On the other hand, if your descriptive sentence is basically just duplicating the statements in the function, then your function is most likely too small or too granular. Depending on situation, you might be able to fix it.
inertiatic 7y ago
Me and my coworkers are working with multiple, widescreen monitors. These can display, even in a crowded IDEs with larger fonts hundreds of characters in a line. Oh, and they have the capability of wrapping text. Yet, a lot of the purported best practices, a lot of the frequently used linters etc. complain about that 80 character limit. Now, when I'm reading Python that follows the actual best practices of named arguments and descriptive variable names, I might have to follow a function call so far down that I forget what it's name even is. Fun! I've also had the experience of trying to follow code that follows the other best practice of breaking out everything into a separate function. It's always a joy to have to follow that trail out of the call stack when trying to debug, and having to back out potentially tens of files while trying to navigate some unfamiliar code, losing all the rest of the context on each single jump.
- scoutt 7y ago
  > wrapping text Oh my. Who uses wrapping text for coding?
  - inertiatic 7y ago
    Someone who wants an extra large font for whatever reason, perhaps due to sight problems. The point is that this is an option.
  - twic 7y ago
    Why wouldn't you? You do need some sort of indication in your editor that the line is soft-wrapped. If you have line numbers in the gutter, then you already have that.
paggle 7y ago
Terrible advice. A method perform one coherent action... if that action takes 1000 lines of code due to some wacky business logic, then the function should be 1000 lines, not split into multiple functions just for the sake of some weird rule.
- kevinrav 7y ago
  did not agree about it, Wacky business logic can break up into small function or smaller business logic. The way to keep track in a huge function will make your brain struggle/question in middle of way. The good engineer need to find out where need to break. We need write code for readable and archive business logic.
9214 7y ago
Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096 bytes and fits into disk block). Makes no sense in the modern world of course, but, in the context of block editors, it creates a development environment where making complex and bloaty word definitions is actively discouraged -- an idea that Aaron Hsu briefly mentions in his APL talks [1]. [1]: https://www.youtube.com/watch?v=gcUWTa16Jc0 https://www.youtube.com/watch?v=gcUWTa16Jc0
- zentiggr 7y ago
  Of course, in the Forth environment, the more any word definition bloats, the harder the stack tracing you have to do in order to understand the operation flow, so keeping things neat and to the point is even more important. It might be a failing of my own, but I've always wanted a concatenative language IDE to have a stack window, with manual labeling, so I could see what all is on the stack and follow the information flow better.
blowski 7y ago
> Novice Programmer: "Putting all this code in one function would be easier to write." > Master Programmer: "You fool! You can't just stuff all your code into one function because it's easier to write!" So the Novice Programmer separated all the code out into different functions and showed the results to the Master Programmer. > Master Programmer: "You fool! Why have you broken this out into different functions when it all belongs together in the same function?" And in that moment the Novice Programmer achieved enlightenment.
- tempguy9999 7y ago
  > achieved enlightenment I haven't. What are you saying?
  - darkwater 7y ago
    Maybe that, no matter what you do, there will be always somebody telling you there's a better implementation for it.
  - gibagger 7y ago
    I believe that it means that some things aren't always very clear cut, and one could make a reasonable argument to do it either way.
    - tempguy9999 7y ago
      The best I could interpret it is to have it both ways; break it down into small private functions, then nest (edit: encapsulate) these in a larger one where they can't be seen by anyone else.
      - blowski 7y ago
        Both and neither. It depends on you and your team, the project requirements, the rest of the codebase, and so many other things. The choice you make is less important than _why_ you make it.
siscia 7y ago
I would argue exactly the contrary: https://redbeardlab.com/2019/02/07/write-long-function/ https://redbeardlab.com/2019/02/07/write-long-function/ Very seldomly the problem is to understand one function, most of the time the complexity is in understanding how everything fit together. Having dozen of little functions does not help at all. On the contrary having few, well designed, well interfaced functions that takes care of all corner cases and just work helps tremendously. Those functions are almost always long.
k__ 7y ago
I had some issues when giving 80 char wide code into print. 70 worked. Just as a small info :)
seaish 7y ago
I don't know how everyone uses such small font sizes. I think mine is set to 16pt. The one thing that frequently makes me ignore line lengths is URLs. They seem to be most readable when on one line, even if it's 200 characters long. Also, what kind of variable name is `maîtreD`? I doubt many regions have î on their keyboard.
- thrower123 7y ago
  Their eyes must be much better than mine. I think I would probably have eyestrain and be even more tired at the end of the day if I had to squint at 8pt font all day.
- ProZsolt 7y ago
  HiDPI displays make it much easier.
mhd 7y ago
I tend to have a rule/aspiration that I could frame as "80 || 24": don't force me to read too much in two axes. So a longer routine that does maths, maybe even with nested loops, but using short variables and few function calls is quite easy to follow. As are short routines that have long identifiers. Like your average OOP or Lisp code. I even think that multiple statements per line are falsely maligned. Wirth used them quite a lot, and not just in stuff meant for publication. If you've got everything on a few lines, it's not that hard to follow. Interesting sidenotes for this would be syntactic elements beyond functions/methods. Starting with nested functions, where I actually found the function-hoisted JavaScript variant better than Lisp's flets/labels or modern JS arrow functions. Other areas that don't seem to be investigated a lot would be inner-procedural refinements (ELAN, some C preprocessors), folding/structured editors and Knuth-style Literate Programming.
azernik 7y ago
> Like all other programmers, other people's code annoys me. The most common annoyance is that people write too wide code. > This is probably because most programmers have drunk the Cool Aid that bigger screens make you more productive. When you code on a big screen, you don't notice how wide your lines become. This is part of why I only ever edit code in a half-screen-width window; the other half of the screen is always filled with either another editor, or a terminal. This ends up coming out to more like 100 characters per line rather than 80, but the principle is the same.
tomxor 7y ago
There is a lot of disagreement here with the ideas presented, but i think most of the arguments are taking the ideas too literally and extremely... as with any advice there are no hard and fast rules. I have some guiding principles similar to the author which make me end up essentially doing the same thing (I also like to keep under 80w and roughly 24h, but there are many exceptions)... yet my principles are seemingly contradictory e.g: 1. minimalism, 2. holism. Notice that they are not imperative, they are merely principles / desirable attributes, by minimalism I usually mean what the author is talking about but in a more general way, keeping small code blocks is one such desirable... but this does not mean split everything up into micro functions that cause a horrible nest of layered calls, because that goes against the principle of holism... this I believe is also similar to what the author wants - holism is part of legibility, whereas reducing your function scope and interface are only immediate legibility of the local code. Ultimately what i'm talking about is balance, which is why I think it's better to present these ideas to people as principles rather than imperative rules which can be followed rigidly (wrongly).
kstenerud 7y ago
Or, to understand this one level deeper: Functions/methods should do one thing, and do that one thing well. In general, each of those one things should be smallish things that you use to compose bigger things, which also do one thing and do it well. 24 lines is as good a rule of thumb as any, as long as you're not actually counting the lines. Your goal is flow and readability (ultimately: maintainability), not some countable metric.
keymone 7y ago
Here’s a case for 80rule: our vision is (mostly) two dimensional, research shows reading comprehension drops as lines get longer, that’s why books and newspapers mostly have fairly narrow columns, comprehending code is less about reading but more about scanning and picking up context for things, much easier to do when perimeter is minimized. Lots of gut instinct here, not enough citations, maybe one day I’ll compile a more substantiated post about this.
raverbashing 7y ago
Sorry, this sounds a lot like motivational "feel good" advice that's in essence empty and confuses more than helps. "write small functions" sure, how does it help managing complexity? Now you have several tiny functions and need to jump across files and functions to understand how everything works (+ the overhead each function adds - parameters, return values, etc) Sure, small functions have their place, but sometimes it is easier to have a big block of code that does what you need. Or as another comment said, write small functions but big procedures. Now for my favourite pet peeve: that 80 columns is some kind of "best practice". In reality it has been cargo culted since the days of the initial IBM PC and there is no reason for such an arbitrary number to exist. But the church of 80 columns keep repeating their mantra mindlessly, mindlessly uglyfying lines of code which go over only a couple of characters beyond 80 columns and wasting coder time with this instead of actually asking the question: is the code actually easier to read now or not? Because to me, calling a function with one parameter in each line is extremely ugly (especially under-indented as the examples presented in the article) Is a line that's 85 characters essentially harder to read (especially now with multiple screen sizes and widths) than an 80 char one? No. I'm not advocating for writing 200 character lines of code, but to not be absolute about it.
ken 7y ago
> Most mainstream languages, however, seem to be verbose to approximately the same order of magnitude. My experience is mostly with C#, so I'll use that (and similar languages like Java) as a starting point. I see this, too. For a couple decades, all mainstream languages had roughly the same order-of-magnitude verbosity, and then when GC languages arrived, it took a big leap. Now we've plateaued here for a while. When closures became mainstream, that was a smaller leap. This leaves me optimistic for the future. I find Lisp to still be much more compact than mainstream languages. Maybe once this generation has fully accepted the current level functionality, and gotten tired or frustrated with it, we'll see another jump in mainstream language expressivity.
davvolun 7y ago
Agree fully, and as mentioned in the article > I tend to stay within it, but I occasionally decide to make my code a little wider. No coding rules should be religiously held. If you're trying to re-write an 81 column line to fit the rule, even though it's concise and more readable at 81 columns, you're doing it wrong.
rileyt 7y ago
This is really good advice. There are a ton of different reasons why you can end up breaking this rule and almost all of them are things you want to avoid: multi-purpose functions, adding to old functions that should be refactored, adding an extra case to an if statement that should be broken down, etc.
sethc2 7y ago
If his point is that you should dogmatically reduce long functions into a bunch of small functions, I think he is completely wrong. If his point is that when the clearest way to implement some functionality is with a single long function and not several small ones, and that that is likely indicative of poorly architected code and/or data models, I probably agree with him. Iff you have some poorly architected code that results in you writing a 500 line function, breaking that poorly architected code down into 20 small functions will only make things worse. However it might be that you could re-architect the code and data models in such a way that functions don't need to be large to be clear then that is probably a good thing. So please don't go breaking a long function into a bunch of smaller ones, where your small functions' names are effectively code comments, but if you can, rearchitect the code so that a set of smaller functions can accomplish the same task in a more clear way, I am all for it.
jitendrac 7y ago
I disagree with article. For me function is an abstraction of re-usable code to achieve a single goal(or Intended state). Think of the list of function in system as a list of APIs for a service, the more you create for unintended purpose, the more likely it is a tech-debt. so, I will say make function for a Goal/Intend in mind, abstract only generic logic to small functions, which have guessable behavior through identifiable by name. Long functions are good if they need to be.

170 points by nreece 7y ago

> You've probably heard about the 80/20 rule, also known as the Pareto principle. Perhaps the title lead you to believe that this article was a misunderstanding. I admit that I went for an arresting title; perhaps a more proper name is the 80x24 rule. You got me there. The 24 lines convention is interesting. Made me realize that linting rules exist for function length: javascript: https://eslint.org/docs/rules/max-lines-per-function https://eslint.org/docs/rules/max-lines-per-function Can't find the equivalent for python though

whoisthemachine 7y ago

I prefer 120 characters of width, modern monitors are wide-screen, I think it's ok to adjust a little to accommodate this reality.

mclehman 7y ago
My monitor may be widescreen, but my editor typically isn't.
JonathonW 7y ago
Same here; 80 characters just feels too narrow to me in most cases. I'd rather see 100 or 120 characters of width and be less constrained, at the expense of maybe having to scroll if I've got multiple files open in my editor. I also usually run my terminals at 120 characters wide, FWIW.
- AstralStorm 7y ago
  It's not like 80 is a hard width limit. The rule exists mostly to limit nesting and not text. More (nonredundant) text is better to a high degree. Likewise 24 line height limit should not include proper comments.
gorgoiler 7y ago
If you haven’t already heard the counter argument, then it’s less about screen width and more about being able to view multiple pieces of code side by side (split window editing, and side by side diffs for code review.) It’s also important to accommodate people wanting to do this with large type sizes, which becomes important as eyesight deteriorates.
- manicdee 7y ago
  All the editors I use have supported soft wrapping, so line length isn’t such an issue. For me it’s mostly about being able to grow each line of code without frying my brain like Perl’s leaning toothpick syndrome does.
  - mark-r 7y ago
    I find wrapped code much harder to read, unless it's indented properly. The wrapping breaks the flow.
  - babuskov 7y ago
    I hate soft wrapping. It makes the code much harder to read and reason about. Especially if someone else wrote it. I rather choose to scroll to the right to see long lines when needed.
  - manicdee 7y ago
    (Extremely late edit: “grok” not “grow”)
- PunchTornado 7y ago
  On most monitors today you can still have 120 characters and see 3 or 4 side by side tracks including the filesystem in another track.
  - forgottenpass 7y ago
    How big is "modern" these days? I have a multiple 22" 1920x1080 screens instead of one huge one, and after making the font as small as is still comfortable at my viewing distance I get 202 visible columns in maximized VS Code. At a still-workable but small enough size that I'll start unconsciously hunching at my desk I can get up to 271. Common laptop screen sizes are even more constrained. I also like to have one monitor turned to 1080x1920 for text editing and consoles. I'd never try to do a side-by-side diff on it, but it really makes you see just how many GUIs are downright wasteful of horizontal space.
rypskar 7y ago
You don't even need a wide-screen monitor for that. I like to turn my coding screen 90 degrees, to portrait mode, to get more vertical space and still can see the line at 120 characters. I call it the TIE-fighter setup, the screen in the middle is in landscape mode and the two others are in portrait mode, gives a lot of screen-space without having to turn the head much to see it all
- bransonf 7y ago
  This is my favorite monitor configuration and now I have a handy name for it, thanks!
- IggleSniggle 7y ago
  I also prefer the TIE-fighter setup, and didn't have a name for it until now. However, I find that 120 characters is too wide as soon as you want to do anything other than code on that screen.
- enriquto 7y ago
  > I call it the TIE-fighter setup, I have the exact opposite setup, with the vertical screen in front of me. How would you call that setup?
  - lvturner 7y ago
    Inverse TIE-Fighter?
  - VistaBrokeMyPC 7y ago
    Satellite setup! (side monitors are solar panels?)
    - enriquto 7y ago
      not as awesome as "TIE fighter setup", but it does the trick
  - rypskar 7y ago
    Maybe Dumbo setup? The outer screens would be his ears. Not happy with the name, but best I could think of today. I'm a developer, so by definition bad at naming stuff. TIE-fighter setup is the lucky exception
clarry 7y ago
I'm using a 30" widescreen monitor and 8pt font. I get four tmux panes side by side, each with a little over 100 characters. I think getting an extra pane is worth way more than getting extra 20 characters of width per pane for the occasional long line. If it were up to me, I'd be happy to add a fifth pane and go for 80 columns. Unfortunately people at work picked long naming conventions and they're also writing massive functions with deep nesting :( I'd actually encourage a 80-character limit and deep indents (at least 4, preferrably 8 spaces) if only to force people to give their code better structure. I don't have a problem with long functions as long as they read straightforward, like a recipe from top to bottom, without too much branching and looping and jumping around. Unfortunately these massive deeply nested functions tend not to read straightforward at all.
ProZsolt 7y ago
I prefer 80/120. I try to write 80 character lines, but occasional 120 lines are accepted.

disposedtrolley 7y ago

A reasonable line width contributes so much to readability. While I'm fortunate enough not to experience much of it in the code I read, I do see a lot of websites which grossly violate sane line width rules by stretching the body text to the full width of the browser (looking at you Wikipedia ). Take https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity as an example. Edit: Martin Fowler's blog (https://martinfowler.com/ https://martinfowler.com/) is probably a good counterexample to this.

gorgoiler 7y ago

I love this. For as long as code needs to be maintained, code will always be just as much about communicating with people as it is about people communicating with machines. One thing I still enjoy about message passing OO (by which I really mean Ruby) is how it’s really easy to separate concerns to the extent that each file contains one module/class with one public and a few private methods in it. I went a bit bonkers this year and found myself doing one method per module, which is the extreme version of this. Languages with mixins are great for this too. Mixins are, amongst other things, a nice shortcut around composition that lets you put individual facets of functionality in separate files, albeit with fewer guarantees about code remaining uncoupled. It’s a shame Ruby’s module system doesn’t better support private for modules though.

Gunax 7y ago
According to the SICP “Programs must be written for people to read, and only incidentally for machines to execute.”
ajnin 7y ago
I don't see how splitting code in multiple modules makes it easier to communicate to others. It forces you to constantly switch places, which, knowing the limitations of the brain with regards to short term memory, would make it harder to keep a mental model. With mixins you don't even know where a particular function might come from, must be a nightmare following a trail when you don't know the code.

tylerl 7y ago

I first saw this in the Linux kernel style guide back in the 90s. The idea was that you should be able to read a function without scrolling. So that meant it would fit on screen in a standard terminal. It's a bit extreme for practical use, but the concept is important to keep in mind. I was helping a Jr programmers with a code review a few months back. He'd been told that a particular chunk of code was "unclear", with specific emphasis on 4-line bit of logic in a 30-ish line function. He had no idea how he could make the code "more clear". It did what it did; the logic was a bit complex but the code was exact and correct. The solution: factor out the 4 lines of code into a function. It was only ever called from that one place, but by making it a function you give the code a name, with clear inputs and outputs. Nothing changed about what the code did, but it became a lot easier to reason about. It's a helpful lesson that generally doesn't really sink in for the first few years.

Gunax 7y ago
Do you think that's a good practice? I have always been conflicted. For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable. But sometimes it just is easier to move a bunch of crap to a function and abstract it away.
- vivekseth 7y ago
  I’d bet that the compilers mostly commonly used would probably inline a function only used once. If not, many languages provide an `inline` keyword to tell the compiler to in-line the function directly. Even if there was no way to inline a function, I tend to prefer code that is easy to understand over code that manages to shave off a few extra instructions. Code that is hard to understand will be hard to maintain and can lead to bugs in the future.
- usr1106 7y ago
  > For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable. Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue. That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does. Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.

pubby 7y ago

I've seen this idea cargo-culted way too often. There's nothing wrong with long functions. In fact, long functions are often easier to grok than ones split apart into dozens of pieces. Create useful abstractions. Don't create abstractions for the sake of creating abstractions.

bransonf 7y ago
I share your sentiment. Some of the programmers I’ve worked with would build functions for every thing within a larger function. Need to chunk the data? Function. API Call? Function. Parse the response? Function. So I asked: “Are you ever going to use these internal functions for anything outside of this function?” And their response was: “No, but it makes debugging easier.” It does not. It makes it exponentially more difficult. Maybe I just work with too many terrible programmers...
- enriquto 7y ago
  I have the opposite philosophy. The ideal function is only called once. If it is called more than once, I have a "call diamond" instead of a "tree" and this is a code smell.
  - raxxorrax 7y ago
    Harsh constraint. Probably difficult to come up with new sorting algorithms or substitutes for basic arithmetic functions after a while.
    - enriquto 7y ago
      I mean for functions that are called in the same context. Obviously external and well-abstracted functions can be called several times.
- Nition 7y ago
  One middleground option if you have a long function but also want to break it into chucks for easy readability: In C# and some other languages you can put braces around a block of code without actually having any condition on it. Or just throw some big comment headers in.

dimino 7y ago

I cannot overstate how important this concept is. Write code (and DESIGN SYSTEMS) that fit in your brain, because the faster you can reload it back into your brain, the quicker you can dispatch bugs and new features down the line. Nothing in my professional career has caused me more anxiety than encountering complex code to solve a simple problem. It's infuriating, and has long lasting deleterious effects for the life of that code. What's especially insidious about this problem is that for folks who value short term success over sustainability, they'll struggle with this for a long time, and have all kinds of reinforcement to be skeptical that any of this is even a problem. Once you get used to struggling with complex code some people start to think it's all that can be written.

NohatCoder 7y ago
Artificially slicing up functions does not make the code fit in my brain, it just means that I have to load in more functions in order to have the required context.
- dimino 7y ago
  Definitely, which is why doing it just to get small blocks of code won't work. It has to be part of the entire design, and sliced at real, logically separate spacings. It's hard! But immensely rewarding if you get it right. You have to be thoughtful as you design and build.

User23 7y ago

This is one of those things that is older than the printing press. We learned a long time ago that there is a more or less optimal column width for text and it's based on the physiology of the eye. I haven't been able to find a great reference online in a brief search, but this[1] has the basics. [1] http://maxdesign.com.au/articles/em/ http://maxdesign.com.au/articles/em/

alkonaut 7y ago

I have started to move in the other direction for C#. A long sequence of code that flows in one direction should be kept in one method if possible. Good reasons to break up a method are things that are not readability but other things such as re-use testability. If the methods are only called in one place and not performing a piece of work that is testable, then they shouldn’t be methods. But DoAll() { DoA(); DoB(); DoC(); } Is simply not better in any way than DoAll() { // A ... // B ... // C ... } Private methods will blur this somewhat. The key to readability is not having to jump around. Ideally of course methods are both short and reusable, readable without jumping etc, but given the choice between a 100 line method or the same code broken into 10 methods of 15 lines each (yes, more lines), where each method is only called once from a main method, I’d rather read the first. The 100 lines might indicate some other problem with the api (a chatty Dx12/win32-like API for example). This obviously varies from case to case, I think one of the worse things a team can do is enforce hard rules that invariably lead to “style rule-induced damage”.

wruza 7y ago
IDEs could make it readable and encourage to split code without splitting perception. A solution is: allow calls to be ▶expanded inline in the source view, as if it was written here* Renaming arguments to their caller-site counterparts would also help. * Code folding is not the same thing, as it doesn’t eject scope+args out of the “caller” and cannot be used in expression. Upd: I also would like to add that sources lack usual style formatting. //-sections usually should stand out, but one can only make comment bigger (2-3 lines with === filler), but not the text itself. It would be nice to have some rtf in code and css in IDE. Books are written like that, and that’s well-acknowledged way to structure instructions and descriptions.
- eitland 7y ago
  > allow calls to be ▶expanded inline in the source view, If I understand what you mean, Visual Studio Code allows this. I guess Visual Studio does as well. The implementation feels a little clumsy to me, but hey, I'm the guy who thinks Netbeans and Eclipse where the best IDEs I've used, so I guess a bunch of you guys will think the solution is perfect.

Mikhail_Edoshin 7y ago

I find this an artificial metric. Normally code just gets split organically as you notice that you can reuse this bit here or that bit there. Some functions won't split and that's OK. (Reference to the 2k-plus-line main interpreter loop in Python.) Actual reuse is the primary drive for this. Trying to adhere to some other concept instead is dangerous. I've lost countless hours trying to make code "properly object-oriented", or "isolated", or "pythonic" until I realized it's all a delusion.

jfengel 7y ago
It wasn't always artificial. When you really were working on a screen that showed 24 lines of 80 characters, it was a good practice to be able to view your entire function at once. That was especially important since at the time we lacked tools like debuggers, and so there was more focus on being able to find bugs by reading. Today the hardware improvements make those numbers obsolete, but the numbers were picked in the first place because a "screenful" was picked to be a reasonable amount of information to handle at one time -- not just for code, but also for code. I was never religious about the rule, but it still feels like a good code smell to keep an eye on. If a function gets too big, I start wondering if it's really still doing one thing.

stefanfisk 7y ago

John Carmack's take on this seems a lot more sensible to me: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...

wruza 7y ago

The question is, why didn’t the author write his article in smaller 50-word block tree, conveniently connected by a-hrefs and/or separated to multiple pages, all links well named. It is a straight wall of text instead, that is hard to follow and using implicit references all across.

stefanfisk 7y ago
<3
fuzzy2 7y ago
Oh but maybe he did. It's just that you're looking at the compiled version.
cjfd 7y ago
Actually, the more technical a text is the more likely it is to contain references and (sub)headers. Also, I certainly would not describe this text as a 'straight wall of text'. A straight wall of text would be a text without paragraphs or headers.
- BigJono 7y ago
  Breaking text up like that is the equivalent of chucking some line breaks in a function and a few comment headings, not creating a bunch of pointless functions and scattering them around the file (or codebase).
joelfolksy 7y ago
1: a very good 2: That's 4: question Comment: 2 1 4.

js8 7y ago

I prefer another rule for short functions. You should be able to explain what the function is doing in one sentence. If you need two sentences, you should break it into more functions. On the other hand, if your descriptive sentence is basically just duplicating the statements in the function, then your function is most likely too small or too granular. Depending on situation, you might be able to fix it.

inertiatic 7y ago

Me and my coworkers are working with multiple, widescreen monitors. These can display, even in a crowded IDEs with larger fonts hundreds of characters in a line. Oh, and they have the capability of wrapping text. Yet, a lot of the purported best practices, a lot of the frequently used linters etc. complain about that 80 character limit. Now, when I'm reading Python that follows the actual best practices of named arguments and descriptive variable names, I might have to follow a function call so far down that I forget what it's name even is. Fun! I've also had the experience of trying to follow code that follows the other best practice of breaking out everything into a separate function. It's always a joy to have to follow that trail out of the call stack when trying to debug, and having to back out potentially tens of files while trying to navigate some unfamiliar code, losing all the rest of the context on each single jump.

scoutt 7y ago
> wrapping text Oh my. Who uses wrapping text for coding?
- inertiatic 7y ago
  Someone who wants an extra large font for whatever reason, perhaps due to sight problems. The point is that this is an option.
- twic 7y ago
  Why wouldn't you? You do need some sort of indication in your editor that the line is soft-wrapped. If you have line numbers in the gutter, then you already have that.

paggle 7y ago

Terrible advice. A method perform one coherent action... if that action takes 1000 lines of code due to some wacky business logic, then the function should be 1000 lines, not split into multiple functions just for the sake of some weird rule.

kevinrav 7y ago
did not agree about it, Wacky business logic can break up into small function or smaller business logic. The way to keep track in a huge function will make your brain struggle/question in middle of way. The good engineer need to find out where need to break. We need write code for readable and archive business logic.

9214 7y ago

Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096 bytes and fits into disk block). Makes no sense in the modern world of course, but, in the context of block editors, it creates a development environment where making complex and bloaty word definitions is actively discouraged -- an idea that Aaron Hsu briefly mentions in his APL talks [1]. [1]: https://www.youtube.com/watch?v=gcUWTa16Jc0 https://www.youtube.com/watch?v=gcUWTa16Jc0

zentiggr 7y ago
Of course, in the Forth environment, the more any word definition bloats, the harder the stack tracing you have to do in order to understand the operation flow, so keeping things neat and to the point is even more important. It might be a failing of my own, but I've always wanted a concatenative language IDE to have a stack window, with manual labeling, so I could see what all is on the stack and follow the information flow better.

blowski 7y ago

> Novice Programmer: "Putting all this code in one function would be easier to write." > Master Programmer: "You fool! You can't just stuff all your code into one function because it's easier to write!" So the Novice Programmer separated all the code out into different functions and showed the results to the Master Programmer. > Master Programmer: "You fool! Why have you broken this out into different functions when it all belongs together in the same function?" And in that moment the Novice Programmer achieved enlightenment.

tempguy9999 7y ago
> achieved enlightenment I haven't. What are you saying?
- darkwater 7y ago
  Maybe that, no matter what you do, there will be always somebody telling you there's a better implementation for it.
- gibagger 7y ago
  I believe that it means that some things aren't always very clear cut, and one could make a reasonable argument to do it either way.
  - tempguy9999 7y ago
    The best I could interpret it is to have it both ways; break it down into small private functions, then nest (edit: encapsulate) these in a larger one where they can't be seen by anyone else.
    - blowski 7y ago
      Both and neither. It depends on you and your team, the project requirements, the rest of the codebase, and so many other things. The choice you make is less important than _why_ you make it.

siscia 7y ago

I would argue exactly the contrary: https://redbeardlab.com/2019/02/07/write-long-function/ https://redbeardlab.com/2019/02/07/write-long-function/ Very seldomly the problem is to understand one function, most of the time the complexity is in understanding how everything fit together. Having dozen of little functions does not help at all. On the contrary having few, well designed, well interfaced functions that takes care of all corner cases and just work helps tremendously. Those functions are almost always long.

k__ 7y ago

I had some issues when giving 80 char wide code into print. 70 worked. Just as a small info :)

seaish 7y ago

I don't know how everyone uses such small font sizes. I think mine is set to 16pt. The one thing that frequently makes me ignore line lengths is URLs. They seem to be most readable when on one line, even if it's 200 characters long. Also, what kind of variable name is `maîtreD`? I doubt many regions have î on their keyboard.

thrower123 7y ago
Their eyes must be much better than mine. I think I would probably have eyestrain and be even more tired at the end of the day if I had to squint at 8pt font all day.
ProZsolt 7y ago
HiDPI displays make it much easier.

mhd 7y ago

I tend to have a rule/aspiration that I could frame as "80 || 24": don't force me to read too much in two axes. So a longer routine that does maths, maybe even with nested loops, but using short variables and few function calls is quite easy to follow. As are short routines that have long identifiers. Like your average OOP or Lisp code. I even think that multiple statements per line are falsely maligned. Wirth used them quite a lot, and not just in stuff meant for publication. If you've got everything on a few lines, it's not that hard to follow. Interesting sidenotes for this would be syntactic elements beyond functions/methods. Starting with nested functions, where I actually found the function-hoisted JavaScript variant better than Lisp's flets/labels or modern JS arrow functions. Other areas that don't seem to be investigated a lot would be inner-procedural refinements (ELAN, some C preprocessors), folding/structured editors and Knuth-style Literate Programming.

azernik 7y ago

> Like all other programmers, other people's code annoys me. The most common annoyance is that people write too wide code. > This is probably because most programmers have drunk the Cool Aid that bigger screens make you more productive. When you code on a big screen, you don't notice how wide your lines become. This is part of why I only ever edit code in a half-screen-width window; the other half of the screen is always filled with either another editor, or a terminal. This ends up coming out to more like 100 characters per line rather than 80, but the principle is the same.

tomxor 7y ago

There is a lot of disagreement here with the ideas presented, but i think most of the arguments are taking the ideas too literally and extremely... as with any advice there are no hard and fast rules. I have some guiding principles similar to the author which make me end up essentially doing the same thing (I also like to keep under 80w and roughly 24h, but there are many exceptions)... yet my principles are seemingly contradictory e.g: 1. minimalism, 2. holism. Notice that they are not imperative, they are merely principles / desirable attributes, by minimalism I usually mean what the author is talking about but in a more general way, keeping small code blocks is one such desirable... but this does not mean split everything up into micro functions that cause a horrible nest of layered calls, because that goes against the principle of holism... this I believe is also similar to what the author wants - holism is part of legibility, whereas reducing your function scope and interface are only immediate legibility of the local code. Ultimately what i'm talking about is balance, which is why I think it's better to present these ideas to people as principles rather than imperative rules which can be followed rigidly (wrongly).

kstenerud 7y ago

Or, to understand this one level deeper: Functions/methods should do one thing, and do that one thing well. In general, each of those one things should be smallish things that you use to compose bigger things, which also do one thing and do it well. 24 lines is as good a rule of thumb as any, as long as you're not actually counting the lines. Your goal is flow and readability (ultimately: maintainability), not some countable metric.

keymone 7y ago

Here’s a case for 80rule: our vision is (mostly) two dimensional, research shows reading comprehension drops as lines get longer, that’s why books and newspapers mostly have fairly narrow columns, comprehending code is less about reading but more about scanning and picking up context for things, much easier to do when perimeter is minimized. Lots of gut instinct here, not enough citations, maybe one day I’ll compile a more substantiated post about this.

raverbashing 7y ago

Sorry, this sounds a lot like motivational "feel good" advice that's in essence empty and confuses more than helps. "write small functions" sure, how does it help managing complexity? Now you have several tiny functions and need to jump across files and functions to understand how everything works (+ the overhead each function adds - parameters, return values, etc) Sure, small functions have their place, but sometimes it is easier to have a big block of code that does what you need. Or as another comment said, write small functions but big procedures. Now for my favourite pet peeve: that 80 columns is some kind of "best practice". In reality it has been cargo culted since the days of the initial IBM PC and there is no reason for such an arbitrary number to exist. But the church of 80 columns keep repeating their mantra mindlessly, mindlessly uglyfying lines of code which go over only a couple of characters beyond 80 columns and wasting coder time with this instead of actually asking the question: is the code actually easier to read now or not? Because to me, calling a function with one parameter in each line is extremely ugly (especially under-indented as the examples presented in the article) Is a line that's 85 characters essentially harder to read (especially now with multiple screen sizes and widths) than an 80 char one? No. I'm not advocating for writing 200 character lines of code, but to not be absolute about it.

ken 7y ago

> Most mainstream languages, however, seem to be verbose to approximately the same order of magnitude. My experience is mostly with C#, so I'll use that (and similar languages like Java) as a starting point. I see this, too. For a couple decades, all mainstream languages had roughly the same order-of-magnitude verbosity, and then when GC languages arrived, it took a big leap. Now we've plateaued here for a while. When closures became mainstream, that was a smaller leap. This leaves me optimistic for the future. I find Lisp to still be much more compact than mainstream languages. Maybe once this generation has fully accepted the current level functionality, and gotten tired or frustrated with it, we'll see another jump in mainstream language expressivity.

davvolun 7y ago

Agree fully, and as mentioned in the article > I tend to stay within it, but I occasionally decide to make my code a little wider. No coding rules should be religiously held. If you're trying to re-write an 81 column line to fit the rule, even though it's concise and more readable at 81 columns, you're doing it wrong.

rileyt 7y ago

This is really good advice. There are a ton of different reasons why you can end up breaking this rule and almost all of them are things you want to avoid: multi-purpose functions, adding to old functions that should be refactored, adding an extra case to an if statement that should be broken down, etc.

sethc2 7y ago

If his point is that you should dogmatically reduce long functions into a bunch of small functions, I think he is completely wrong. If his point is that when the clearest way to implement some functionality is with a single long function and not several small ones, and that that is likely indicative of poorly architected code and/or data models, I probably agree with him. Iff you have some poorly architected code that results in you writing a 500 line function, breaking that poorly architected code down into 20 small functions will only make things worse. However it might be that you could re-architect the code and data models in such a way that functions don't need to be large to be clear then that is probably a good thing. So please don't go breaking a long function into a bunch of smaller ones, where your small functions' names are effectively code comments, but if you can, rearchitect the code so that a set of smaller functions can accomplish the same task in a more clear way, I am all for it.

jitendrac 7y ago

I disagree with article. For me function is an abstraction of re-usable code to achieve a single goal(or Intended state). Think of the list of function in system as a list of APIs for a service, the more you create for unintended purpose, the more likely it is a tech-debt. so, I will say make function for a Goal/Intend in mind, abstract only generic logic to small functions, which have guessable behavior through identifiable by name. Long functions are good if they need to be.