[stackoverflow]

I know LOC is generally a bad concept, but I am curious about everyone's experience. On average, when do you think a project goes from, "This is pretty simple and manageable" to "Oh my god, what was I doing?"

I have found once you breach 4-6 source files with 200-300 LOC it tends to get pretty muddy and in need of source control and careful documenting.

What tends to be your threshold?

[GunnerInc]

Usually right after I type

    push    NULL
    call    GetModuleHandle
    mov     hInst, eax

I ask myself, what the hell am I thinking but I go on and end up with over thousand of lines of code...

This post has been edited by GunnerInc: 16 August 2011 - 05:04 PM

[tlhIn`toq]

4-6 files of 200-300 lines? And you consider that chaotic?
No offense, but to me that sounds like doing a lot of typing before doing much planning.

My average desktop application has maybe 4-6 projects in it, not counting the installer project.

Each project probably averages a dozen classes, not counting customer error classes, custom eventargs classes... I mean real workhorse classes.

So all up I would say one solution probably has 200+ files with 100+ methods per file. My current project, just the MainForm.cs file is 1150 lines. Multiply that by several forms, and non-form classes.

For me, things usually go sideways about the time the boss says:

boss said:

I want you to make a program that does: x,y,z. Using this new piece of hardware that you'll need to read the SDK for and write in support. And I've already promised the client it will be installed in 30 days.

There is nothing like writing a new program from scratch, using a new piece of hardware for the first time, using a vendor's SDK for the first time.

This post has been edited by tlhIn`toq: 16 August 2011 - 05:11 PM

[stackoverflow]

I generally don't plan too much. I usually sketch out a few ideas and draw some UML and hit the ground running. I find if I plan too much things never get done. It's all about finding that balance and usually if one doesn't plan enough you are sure to be in chaos sooner.

My current project started off with 4 files and was a done deal. Now it's 20+ source files with a mess of scripting files and twice as many resources.

I generally,

1* Sketch a plan
2* Code like crazy until the chaos is up to my ears
3* Refactor and optimize a little
4* Go back to step 1/2

This post has been edited by stackoverflow: 16 August 2011 - 05:19 PM

[Curtis Rutland]

Quote

I have found once you breach 4-6 source files with 200-300 LOC it tends to get pretty muddy and in need of source control and careful documenting.

Quote

I generally don't plan too much. I usually sketch out a few ideas and draw some UML and hit the ground running.

Don't take offense to this, but it sounds like you're a hobbyist. If you find your projects getting chaotic at 300 LOC, there's a reason for it: you don't plan enough or organize enough. You say that you don't want to overplan, but how are you ever going to tackle a large project if you can't keep track of it past four files or 300 LOC?

If you do this for a living, you learn ways to be organized. Like tlhin`Toq said, my projects actually consist of several projects in a "solution." We break stuff out into referenced libraries, break libraries across classes, and break class functionality across methods. It's all about organization, and you can't do that without some serious planning. Especially if you're going to work with more than one person.

[jon.kiparsky]

Listen to Curtis and tlhin`Toq, they know what they're talking about.

Just spitting code is fine if you're trying to work out a simple idea, or map out an approach, but you'll be throwing that code away when you've learned what you can learn from it. And then you'll be starting from scratch, mapping out the structure of what you're going to do.
This may seem like a bit more of a geek thing than you want to do, but whiteboards are not super expensive. Hang one on your wall and draw out your ideas before you start writing them, that will probably help you organize your thoughts a bit.

Just to repeat what both of the lads have said, if your method can't handle more than a few classes, it's not working for you.

One more thing:

Quote

I have found once you breach 4-6 source files with 200-300 LOC it tends to get pretty muddy and in need of source control and careful documenting.

I recommend you always work in source control, even if you're a one-man band. Set up a local repo on your dev machine and get used to coding with suspenders. And you should really make a habit of reviewing, refactoring, and documenting your code. I usually make a pass through one or two source files when I find myself at a stopping point, trying to get my next direction. I look at each method, I make sure it's correctly commented, and I look for ways to simplify what I'm doing.
The documentation and the refactorings might or might not improve things, but the review keeps my mental image of the codebase fresh, which is very useful.

[jon.kiparsky]

Oh, and speaking of projects going out of control, you really ought to read Ed Yourdon's book "Death March". It's an in-depth study of how this sort of thing happens, and it'll give you a little perspective... well written, too.

[tlhIn`toq]

My personal approach:

• Assume that everything is going to grow to a big project.
  
• Assume that I am going to die in the middle of it, so it needs to be documented and in-code commented as if someone else with no detailed info is going to take it over.
  
• Assume that when I am done, or half-done, the boss is going to call with major changes. So everything must be very modular with no side effects, so it can be easily reorganized or called in different orders.

If every project is going to be a big project, then all my projects start out the same way, are organized the same way, are consistent.

I hate seeing situations where "For this project I did it this way, for that project because it was a little bigger I did this instead, but for that big project I went this route". That leave no path for growth from a little project to a big project.

They are ALL big projects, even the little ones. Organize accordingly.

[stackoverflow]

Thanks, lots of great replies and even a book!

I actually have a white board but I have learned it's not nearly big enough. I may look into a much larger whiteboard or possibly one of those white board racks that have a dual sided board.

My current project is constantly expanding and these techniques will help a lot. Well-- the design is kind of out the window already since the project is up and stable and expanding.

I am taking the current version and trying to make it more stable and refactor the code-- adding in a user bug reporting system and some other tweaks to get feedback and make the program more friendly.

I don't think I will proceed with expanding the project until I have refactored the current code base and have a clear design planned out for the expansion.

[jon.kiparsky]

tlhIn`toq, on 18 August 2011 - 11:39 AM, said:

Assume that everything is going to grow to a big project.

True, that. A project is either useful, or it isn't. If it isn't, it's useless, so let's forget about it. If it's useful, people will use it, and then they'll want to make it do more. Ergo, if you or someone after you will not be extending this, it's probably useless, and you should stop wasting time on it.
(the only exception is your CS 210 homework - learn your data structures!)

[EDIT: I'm assuming that your university uses the CS210 course number for the data structures and algorithms course. That would be sensible, anyway, since it's really the first thing you should do once you know the basics of code, arrays, conditionals, and loops.]

This post has been edited by jon.kiparsky: 18 August 2011 - 05:00 PM

[Curtis Rutland]

Quote

I recommend you always work in source control, even if you're a one-man band.

I second that. I use Team Foundation Server at work, and Github at home for my play stuff. Once you get used to it, you'll never want to not use it. Every time you screw something up or switch computers, you'll be thankful, because you have your last revision (or an earlier labeled revision) backed up in source control.

[stackoverflow]

I have grown quite fond of Mercurial!

[jon.kiparsky]

Whichever you like, I'm not taking a position on that. Probably the best thing is to try each one, and see what feels best for you. As long as you have the ability to roll back, you're going to get the idea.

[Curtis Rutland]

I'm still trying to get used to the idea of the distributed version control, myself. TFS at work is set up for single check-outs, so that only one developer may be modifying a file at a time. You can set it for non-exclusive checkouts that uses a diff tool when you check in, but that's caused more problems than it's solved.

[jon.kiparsky]

I've only used subversion for this, so maybe some mercurial and git fans will chime in to fill things out a little, but from the svn perspective it's not difficult to merge changes together. The only problem is when you have two people making extensive changes in precisely the same territory - but that usually means you have two people doing the same work. When I've seen that problem before, it's always been a matter of poor communication. Granted, that communication is enforced by single checkout, but the lack of it is probably a symptom of something deeper.

In the simplest terms, you can lock a file or a directory in svn, so you can get the single checkout if you want it, but it's better to let the collision happen and figure out what went wrong. That way you can smoke out the guys who want to motor through and turn every knob and flip every button, and focus them down on one thing at a time.

Really, talking about good design, it's a problem if your changes to this method have to percolate out to a lot of other areas: it means someone didn't think about the design very well to begin with, and it's probably better to start thinking about it now, rather than just wiring bits and pieces together and hoping nothing goes wrong.

Which brings us back around to the original question quite nicely, I think.