4 ms·

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) anytim

by 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?
- chimprich 10y ago
  However, if you have a 1000+ line function that you split into small functions you can pretty easily write a few unit tests per function to see which, if any, of those chunks have problems and then need to be fixed. It's pretty much impossible to write unit tests that can sensibly test a non-trivial 1000+ line function. You might get away with it if it's doing something very straightforward but I wouldn't be very confident in it.
  - jblow 10y ago
    This is fine if you believe that unit testing every 40-line chunk of code is remotely worth the time and effort. I don't think that is true for most applications. How long does it take you to write and test all those tests? Could you have been doing other things with that time? At 40 lines of functionality, the tests are going to be at least as big as the things you are testing (??), so what kind of a multiplier are you taking just on lines of code written? How much does that cost? [I run a software company where I pay for the entire burn rate out of my own pocket. So these questions are less academic for me than they are for many people.]
    - chimprich 10y ago
      It's true that there's a non-zero cost for each test, but overall I think tests speed up development rather than slow it down (unless you go crazy with the tests, and providing you're fairly decent at writing tests). I don't believe it's worth testing all paths through the code, but I'd aim for significantly over 50% coverage to have any degree of confidence in the codebase. I estimate I write about 2:1 unit tests to code in terms of tests to functions but tests should be quite a bit faster to write than the code they're testing. I think I'm at the low end of how much I test my code compared to other engineers, however. Perhaps it is different in game development. One of the big advantage of writing tests is that you can aggressively refactor with confidence; if you're planning to stop improving your codebase once the game is released maybe this isn't an issue? Plus bugs are perhaps less of an issue if you inconvenience the gamer rather than lose someone cash, and maybe you aren't expecting to hand code over to new developers.

by bdavisx 10y ago

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?
chimprich 10y ago
However, if you have a 1000+ line function that you split into small functions you can pretty easily write a few unit tests per function to see which, if any, of those chunks have problems and then need to be fixed. It's pretty much impossible to write unit tests that can sensibly test a non-trivial 1000+ line function. You might get away with it if it's doing something very straightforward but I wouldn't be very confident in it.
- jblow 10y ago
  This is fine if you believe that unit testing every 40-line chunk of code is remotely worth the time and effort. I don't think that is true for most applications. How long does it take you to write and test all those tests? Could you have been doing other things with that time? At 40 lines of functionality, the tests are going to be at least as big as the things you are testing (??), so what kind of a multiplier are you taking just on lines of code written? How much does that cost? [I run a software company where I pay for the entire burn rate out of my own pocket. So these questions are less academic for me than they are for many people.]
  - chimprich 10y ago
    It's true that there's a non-zero cost for each test, but overall I think tests speed up development rather than slow it down (unless you go crazy with the tests, and providing you're fairly decent at writing tests). I don't believe it's worth testing all paths through the code, but I'd aim for significantly over 50% coverage to have any degree of confidence in the codebase. I estimate I write about 2:1 unit tests to code in terms of tests to functions but tests should be quite a bit faster to write than the code they're testing. I think I'm at the low end of how much I test my code compared to other engineers, however. Perhaps it is different in game development. One of the big advantage of writing tests is that you can aggressively refactor with confidence; if you're planning to stop improving your codebase once the game is released maybe this isn't an issue? Plus bugs are perhaps less of an issue if you inconvenience the gamer rather than lose someone cash, and maybe you aren't expecting to hand code over to new developers.