3 ms·

Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with All

Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with Allman. That makes a difference at least in my case.

RobertRoberts 9y ago
Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once. Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?
- defertoreptar 9y ago
  All the time, but to be honest, it's mainly side by side when I do. This is useful when building one function that acts on some other part of the code and I don't want to scroll / swap files back and forth. I more meant it in the sense that it's nice to be able to soak in more of the code at once and avoid unnecessary scrolling.
- MaulingMonkey 9y ago
  Refactoring might have you adding a parameter to a function, and then feeding that additional parameter to the function at it's call sites. Even when you only have one call site and thus are in the "2 functions" case - these two functions are often separated by multiple "irrelevant" functions. The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is on my memory.
  - RobertRoberts 9y ago
    >The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is on my memory. I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time. I work on projects with upwards of 100k lines of code consistently, the very idea that anything relevant will fit on one screen is absurd, so I am always curious what kinds of projects people work on where the relevant code is literally within a half screen of each other.
    - MaulingMonkey 9y ago
      I tend to work on gamedev codebases roughly near a 1mloc (both above and bellow.) In one recent refactoring I recently managed to get a class declaration (that was previously local to a single .cpp and had all functions defined inline in one go) to fit on a screen. I use small fonts, 4k resolution monitors, portrait orientation, and I still had to cull some "GetFoo gets a foo" style worthless doc comments to accomplish it. (I kept the comments that actually added anything of meaning.) Given that above description, you can probably guess I don't have everything on screen at all times, not even close. But I'll refactor off small files of related functionality where I can, subdivide things that are getting unwieldy, etc. - put private/static functions near the public/exported functions that call them, break things up into (sub)modules, etc. and get good grouping. > I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time. Taken to the extreme, any such rule absolutely will. I certainly don't have that as a hard and fast rule. Or even as a guideline per se - it's more a faint but distant dream, or perhaps a feverish hallucination, a reminder of codebases past. But there's often plenty of cruft and low hanging fruit that can be fixed up in these codebases. Everyone has their "just one small change" to check in, so things build up and they don't jump to "okay, this is one line too many - time to refactor." I practice pain driven development - when it's getting to be a pain to keep enough of something my head to do whatever sweeping changes or overhauls I might need to do, see if some pure or near-pure refactoring changes it. No expected behavior changes, often not even class or structural changes - often literally just regrouping code by topic and category via cut and paste. Horrific diffs, but low-risk checkins, and often a lot easier to reason about afterwards, and suddenly related code is often on the same screen. (Although far from always.)
      - RobertRoberts 9y ago
        It sounds like we are on the same page. It's hard to tell with brief forum comments what people mean. I am just used to the reality that you _must_ switch contexts all the time, and it's _normal_ simply because the code bases are too big. Yes, it's nice when things are close together, but in my case it's so rare as to not be point to consider trying to achieve, but more like a mental joke like "Hey, Bob. Come here and check this out! Two functions and template I am working on all fit on the same screen!" And Bob's like "wooooah, dude". And then we take a group selfie with my monitor and have a laugh, print out a poster of the selfie for the bulletin board for a few months, then throw it away during a cleanup and move on... But to have people say "It's important to save whitespace so stuff can all be on the screen to avoid context switching" seems completely and utterly pointless.

RobertRoberts 9y ago

Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once. Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?

defertoreptar 9y ago
All the time, but to be honest, it's mainly side by side when I do. This is useful when building one function that acts on some other part of the code and I don't want to scroll / swap files back and forth. I more meant it in the sense that it's nice to be able to soak in more of the code at once and avoid unnecessary scrolling.
MaulingMonkey 9y ago
Refactoring might have you adding a parameter to a function, and then feeding that additional parameter to the function at it's call sites. Even when you only have one call site and thus are in the "2 functions" case - these two functions are often separated by multiple "irrelevant" functions. The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is on my memory.
- RobertRoberts 9y ago
  >The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is on my memory. I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time. I work on projects with upwards of 100k lines of code consistently, the very idea that anything relevant will fit on one screen is absurd, so I am always curious what kinds of projects people work on where the relevant code is literally within a half screen of each other.
  - MaulingMonkey 9y ago
    I tend to work on gamedev codebases roughly near a 1mloc (both above and bellow.) In one recent refactoring I recently managed to get a class declaration (that was previously local to a single .cpp and had all functions defined inline in one go) to fit on a screen. I use small fonts, 4k resolution monitors, portrait orientation, and I still had to cull some "GetFoo gets a foo" style worthless doc comments to accomplish it. (I kept the comments that actually added anything of meaning.) Given that above description, you can probably guess I don't have everything on screen at all times, not even close. But I'll refactor off small files of related functionality where I can, subdivide things that are getting unwieldy, etc. - put private/static functions near the public/exported functions that call them, break things up into (sub)modules, etc. and get good grouping. > I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time. Taken to the extreme, any such rule absolutely will. I certainly don't have that as a hard and fast rule. Or even as a guideline per se - it's more a faint but distant dream, or perhaps a feverish hallucination, a reminder of codebases past. But there's often plenty of cruft and low hanging fruit that can be fixed up in these codebases. Everyone has their "just one small change" to check in, so things build up and they don't jump to "okay, this is one line too many - time to refactor." I practice pain driven development - when it's getting to be a pain to keep enough of something my head to do whatever sweeping changes or overhauls I might need to do, see if some pure or near-pure refactoring changes it. No expected behavior changes, often not even class or structural changes - often literally just regrouping code by topic and category via cut and paste. Horrific diffs, but low-risk checkins, and often a lot easier to reason about afterwards, and suddenly related code is often on the same screen. (Although far from always.)
    - RobertRoberts 9y ago
      It sounds like we are on the same page. It's hard to tell with brief forum comments what people mean. I am just used to the reality that you _must_ switch contexts all the time, and it's _normal_ simply because the code bases are too big. Yes, it's nice when things are close together, but in my case it's so rare as to not be point to consider trying to achieve, but more like a mental joke like "Hey, Bob. Come here and check this out! Two functions and template I am working on all fit on the same screen!" And Bob's like "wooooah, dude". And then we take a group selfie with my monitor and have a laugh, print out a poster of the selfie for the bulletin board for a few months, then throw it away during a cleanup and move on... But to have people say "It's important to save whitespace so stuff can all be on the screen to avoid context switching" seems completely and utterly pointless.