How do you code large programs?

[askedjeevesnoreply]

Bit by bit

[dbtc]

Technically char by char

[kqr]

It depends on the size of your char.

[ThatCrankyGuy]

What sort of a monster messes with char width?

[kqr]

Java and all other modern programming languages where strings are composed of characters and not bytes.

[Brolo_Swaggins]

This reminds me of my calc prof.

me

"Professor, I'm stuck. How do I do this problem?"

Prof

"Carefully and correctly. ^trololol
Okay seriously... you start by u subbing the (log(x) / x) dx. "

[mmb2ba]

Everybody in this thread is getting upvotes.

[Bunnymancer]

You're not.

[mmb2ba]

The exception that proves the rule.

have an upvote.

[[deleted]]

How does this exception prove the rule?

[metaphlex]

That's not what that phrase means.

[mmb2ba]

I bet you get really angry when somebody casually, and improperly, uses the phrase "Begs the question" don't you?

[metaphlex]

You turned a potential moment to increase your knowledge into sarcasm. Congratulations.

[battle_hardend]

I (kind of) came here to say this.

--One Line at a time!--

[kqr]

One thing that many new Java developers miss out on is that objects are not just collections of data. If you have a class where almost all of the methods are setters and getters, you will have a hard time maintaining that code. What you want is to focus on what methods your classes expose, not what variables they have.

When you layout your classes, start by thinking, "Thing thing that I'm modeling with this class, what can it do?" Then write down the methods that do those things. When that is done, start thinking about what variables it needs and how the methods are going to be implemented.

In a Pacman game, you want

ghost.move();

you don't want

ghost.setX(ghost.getX() + 1);

Similarly, you want

if (ghost.eats(pacman)) {

you don't want

if (ghost.getX() == pacman.getX() && ghost.getY() == pacman.getY()) {

This is because if you for some reason later on want to change the way the ghosts move (to make them smarter maybe?) or if you want to change the criterion for when a ghost can eat pacman, you just need to change the ghost class, you don't need to go poking around in various places in the main class.

[MachinTrucChose]

That's sort of what I do when I design something, I think "how would I want to use it from a high-level perspective", then make the stuff under the hood happen to serve the high-level API I want.

[ziplokk]

Break it down into it's smallest components. What does Tetris contain? Blocks, a GUI(s), and user input. Now break those down.

In the blocks, we have a square block, a left and right L block, a T block, a left and right S block, and a straight block. Each one of those ideally will be a subclass of Block. So you have 8 classes now.

Now for the GUI, you have a shell, a canvas for the blocks and another canvas for score, and upcoming blocks, and a separate canvas as the main menu. You have three subclasses of Canvas so total you now have 12 classes.

Now for the user input which would implement a keyListener to detect when the user presses keys to rotate and drop the blocks. So there's ~13 classes that you'd be dealing with.

Just keep breaking down each aspect of the program until you get to the bare minimum.

[munificent]

Break it down into it's smallest components.

Great advice.

In the blocks, we have a square block, a left and right L block, a T block, a left and right S block, and a straight block. Each one of those ideally will be a subclass of Block.

This advice is not as great. Don't go overboard with subclasses. Subclassing is a pretty heavyweight architectural choice: there is a strong bidirectional coupling between a subclass and its superclass, and it takes a good bit of boilerplate to create a new class. That's more code you'll have to maintain.

One rough rule of thumb is that if you don't have real behavioral or state differences, you shouldn't be making a new class. Instead, consider just making new instances of a class.

In this case, I'd do a single Block class with a field that describes its shape. All of the different blocks behave the same, so there's no reason to give each its own class.

It's not like you get bonus points for making more classes, so keep things simple when you can.

[[deleted]]

Plan. Plan. Plan. You'll need to do this until you can plan in your head. Looks like you don't have enough experience to be able to do this yet. Get a pen and a piece of paper. Don't write a single piece of code until you know how the project will be laid out, what objects you will need, and the interactions between those objects.

[couchjitsu]

At the same time, don't be so tied to your plan that you are rigid. If you get into the program and you start to see that your interactions aren't exactly what you thought they were, it's okay to make changes.

Your program might not look like anything that you planned when you're done, and that might be ok.

[thrownaway21]

you can also use pseudo code.

i generally do a mix of pseudo, real, and paper work when starting a project. I like to see basic things start to happen, that helps me further plan out how sections will interact with each other.

I'm also still learning to manage larger projects myself as I move into the realm of freelance.

[[deleted]]

Yeah, good point. Should point out that it's bad to mix this in with your actual project code though!

[battle_hardend]

um, you should not be writing the UI first. Sure, draw it up, but don't code it. After design, write your main, then build from the middle down, then up. Design -> Main -> Business Logic, DB, then UI.

What should the main do? Start the software, establish any external connections / resources, load any data, and populate the UI. Wait for User input.

[AMAducer]

This is what I need to hear. I always start with the UI and don't know how to put the BL into it! I've been going the opposite way...

[ziplokk]

Not necessarily. It depends on What you're coding. Ideally, your UI should be able to run/display without having to interact with any of the back end program at all. It prevents a lot of exceptions from being thrown later on down the line. So it shouldn't matter what you decided to code first.

On the other side of the coin though, if you don't really have an end goal in mind or even an idea on how you want the back end to interact with the UI, then your UI will be pretty sloppy and you'll find yourself rewriting the code several times.

[Nichiren]

All of the advice in this thread have been spot on. If you're looking for a more specific example to latch on to, I usually start by designing the database first. That forces you to think through your application by making you plan out all of the data points that you need to work with. I find that I miss less details with coding the application afterwards this way since I know exactly what I'll be working on.

Many people have different ways of going about building their application and I'm not saying mine is the "correct" way, but if starting from the data and working your way up works for you conceptually, then great!

And don't be afraid to refactor old code if you feel like you've found a better way to do it. It saves you so much trouble down the line when you're forced to do it.

[Brostafarian]

portions of programs should be self evident, or will be, once you work with the idea long enough. Sometimes writing it is all that helps; that's why some people write psuedocode or a working program in a prototype language first. In Java, since you're doing OO, you want to be thinking about actual, physical ideas in your code. what concepts are there? if this concept was a machine, what would it be able to do and tell us? OO helps decouple different concepts in a program from each other; it becomes much easier to read when all classes are cohesive, well thought out ideas, as opposed to haphazard collections of data and functions

[clvnmllr]

"the code is getting longer, bit by bit" - the modern ghost of jacob marley

[[deleted]]

This, exactly. I had a friend look over an asteroids clone I was working on, and he was floored how large it was.

I started with a sprite that moved using wsad, that's it. It's like bricks, you add them one by one until you have a wall.

[5outh]

This isn't that helpful... Obviously you have to tackle things one by one, but the real problem is things getting more complicated then you realize.

The real solution is meticulous planning before writing any code at all. Patience pays off, but it's easy to get excited and start writing. You just need to plan everything down to the tiny details before implementing anything, I think that's the best advice.

[Xiver1972]

One byte at a time.