4 ms·

What size of codebase are you talking about? If it's 100,000 lines of code, and you break stuff every 40 lines, you have now introduced 2500 procedures many of

by jblow 10y ago

What size of codebase are you talking about? If it's 100,000 lines of code, and you break stuff every 40 lines, you have now introduced 2500 procedures many of which don't really need to exist. But because they do exist, anyone who comes along now has to understand this complex but invisible webbing that ties the procedures together -- who calls who, when and under what conditions does this procedure make sense, etc. It introduces a HUGE amount of extra complexity into the job of understanding the program. (Also you'll find the program takes much longer to compile, link, etc, harming workflow). I regularly have procedures that are many hundreds of lines, sometimes thousands of lines (The Witness has a procedure in it that is about 8000 lines). And I get really a lot done, relatively speaking. So I would encourage folks out there to question this 40-line idea. See also what John Carmack has to say about this: 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...

chimprich 10y ago
Carmack in that link isn't exactly giving unqualified support to your position. The first sentence links to where he's now a big fan of functional programming and supports programming using combinations of pure functions.
- jblow 10y ago
  Obviously, he's a different person and has a different opinion. My experience has been that people on HN tend to interpret that part of the posting a little more extrapolatingly than I do. I think he is saying something pretty obvious, which is that when you can structure things in terms of pure functions, you don't have to worry about the side-effects that are one of the main issues you need to contend with when factoring things apart. This is different from being a "fan of functional programming", i.e. believing you should use current functional programming languages to build your projects, or whatever.
pvg 10y ago
I'm curious about the 8000 line procedure and what made it the best approach in your case. Also, how do you navigate inside it?
- jblow 10y ago
  It's the procedure that constructs most of the puzzle panels in the game. Usually I just search for the name of the puzzle I want to edit (which is also how you'd do it if it were a ton of different procedures).
  - pvg 10y ago
    Hah, that's cheating! I'm not trying to defend an 'N-lines' rule which seems too obviously silly to even argue about but people do often break out chunks of code into procedures to give them logical, navigable names. You have names inside your big procedure.
bdavisx 10y ago
I realize you're in the gaming world, and that might be much different; but in the business application world (and I don't mean simple CRUD applications) anytime I've seen code like you describe, 1,000+ lines in a single class, let alone a single method, it's a complete mess.
- kayamon 10y ago
  It's usually the same in the gaming world too.
- jblow 10y ago
  When you factor it into a bunch of 40-line things, is it really less of a mess, or is it just that you can't see the mess any more -- maybe it looks clean, but if you pick up the rug, the room is filled with dust? I think also what you're talking about is a function of programmer skill. I think if you have a good programmer write a 1000-line procedure, and a bad programmer write a 1000-line procedure, you are going to get drastically different things ... just like with anything.
- lj3 10y ago
  If you were to take a poorly written 1000+ line function and split it up into 25 functions, you still have a complete mess AND you don't know where to find anything. If you look closer at those 1000+ line functions that are a dumpster fire you'll see the issue is probably more to do with tight coupling and/or hidden state changes to "global" variables than it is the length of the function itself. A good example of a 1000+ line function I've written for business applications was for processing JSON for the initial state of a web app. You have a lot of data coming in, you need to do a lot of verification and transcribing backend data structures to frontend data structures. It's easier to do it all in one place than it is to break it into many little functions that only get called once anyway.
  - Jtsummers 10y ago
    So you have a massive switch/case like: switch(JSON.someparam) { case A: //code to translate A_server -> A_client case B: //code to translate B_server -> B_client ... } Check all your cases have breaks? That you didn't accidentally introduce a new variable into your scope or clobber a variable already in scope?
RotsiserMho 10y ago
I don't think it's a given that breaking it down introduces complexity. I've found that creating a sub-function for the sole purpose of just giving it a name does wonders for making it easier to understand the code. Names describe intent and are easier to remember than lines of code by themselves.

by jblow 10y ago

chimprich 10y ago

Carmack in that link isn't exactly giving unqualified support to your position. The first sentence links to where he's now a big fan of functional programming and supports programming using combinations of pure functions.

jblow 10y ago
Obviously, he's a different person and has a different opinion. My experience has been that people on HN tend to interpret that part of the posting a little more extrapolatingly than I do. I think he is saying something pretty obvious, which is that when you can structure things in terms of pure functions, you don't have to worry about the side-effects that are one of the main issues you need to contend with when factoring things apart. This is different from being a "fan of functional programming", i.e. believing you should use current functional programming languages to build your projects, or whatever.

pvg 10y ago

I'm curious about the 8000 line procedure and what made it the best approach in your case. Also, how do you navigate inside it?

jblow 10y ago
It's the procedure that constructs most of the puzzle panels in the game. Usually I just search for the name of the puzzle I want to edit (which is also how you'd do it if it were a ton of different procedures).
- pvg 10y ago
  Hah, that's cheating! I'm not trying to defend an 'N-lines' rule which seems too obviously silly to even argue about but people do often break out chunks of code into procedures to give them logical, navigable names. You have names inside your big procedure.

bdavisx 10y ago

I realize you're in the gaming world, and that might be much different; but in the business application world (and I don't mean simple CRUD applications) anytime I've seen code like you describe, 1,000+ lines in a single class, let alone a single method, it's a complete mess.

kayamon 10y ago
It's usually the same in the gaming world too.
jblow 10y ago
When you factor it into a bunch of 40-line things, is it really less of a mess, or is it just that you can't see the mess any more -- maybe it looks clean, but if you pick up the rug, the room is filled with dust? I think also what you're talking about is a function of programmer skill. I think if you have a good programmer write a 1000-line procedure, and a bad programmer write a 1000-line procedure, you are going to get drastically different things ... just like with anything.
lj3 10y ago
If you were to take a poorly written 1000+ line function and split it up into 25 functions, you still have a complete mess AND you don't know where to find anything. If you look closer at those 1000+ line functions that are a dumpster fire you'll see the issue is probably more to do with tight coupling and/or hidden state changes to "global" variables than it is the length of the function itself. A good example of a 1000+ line function I've written for business applications was for processing JSON for the initial state of a web app. You have a lot of data coming in, you need to do a lot of verification and transcribing backend data structures to frontend data structures. It's easier to do it all in one place than it is to break it into many little functions that only get called once anyway.
- Jtsummers 10y ago
  So you have a massive switch/case like: switch(JSON.someparam) { case A: //code to translate A_server -> A_client case B: //code to translate B_server -> B_client ... } Check all your cases have breaks? That you didn't accidentally introduce a new variable into your scope or clobber a variable already in scope?

RotsiserMho 10y ago

I don't think it's a given that breaking it down introduces complexity. I've found that creating a sub-function for the sole purpose of just giving it a name does wonders for making it easier to understand the code. Names describe intent and are easier to remember than lines of code by themselves.