Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Code is getting convoluted  (Read 4497 times)
0 Members and 1 Guest are viewing this topic.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #30 - Posted 2012-12-11 17:29:37 »

Accessors (getters and setters) are a big pain in the ass.  The Java language should have followed the Uniform Access Principle, but it doesn't, so accessors are here to stay.  They might take up extra space in a program listing, but they shouldn't be at all cumbersome to generate -- every IDE has the ability to generate accessors for you, so learn that feature.  That or use Lombok which will generate them invisibly so they don't even show up in your source.

Offline Roquen
« Reply #31 - Posted 2012-12-11 17:35:02 »

Following with my theme...I think it's a better to get an idea of "why" you want to hide implementation details first, before blinding following the "wrap the accessors " dogma.  (And yeah, getter/setters should be hidden behind the scenes...but I'll leave at that or I might start ranting about operator overloading again).  Beside, invoke the "refactoring fairy" when you get it wrong isn't a big deal.
Offline Cero
« Reply #32 - Posted 2012-12-11 18:17:01 »

One thing that I haven't understood from my classes is the idea of having variables private and using getters and setters. I feel like the code is much easier to use when variables are public,
http://en.wikipedia.org/wiki/Principle_of_least_privilege
setter and getters are also useful when you always wnat to do something else, when calling a method. For instance, whenever increase the money, I want a sound effect to play; so instead of manipulating a money variable directly, you call changeMoney(40) which plays a sound automatically - crude example

Roquen is quite right.
You should KNOW what good software design is, and what practices are good, which are bad and why and what the pitfalls are exactly.
But you don't have to adhere to these rules if you don't think its necessary. Especially in game programming where it is important to get something done.
Almost all these rules are for big codebases with a lot of people working on it, constant evolution and re-use... that sort of thing, the "worst/best" case

Doesn't mean you should take a dump on your codebase; but especially when you are the only one that will use this code that you are writing, you should do, what you think makes sense.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #33 - Posted 2012-12-11 18:21:09 »

BTW, business apps are often some of the most hacked-up crap you can imagine.  The average piece of open source code tends to be engineered better because the programmer would be too embarassed to release anything less.

Good engineering is as much about being able to understand and work with your own code as it is about being robust in the face of change.  One thing the eXXXTREME!!! DøøD! Programming crowd gave us (other than a name I can't help but make fun of) that's actually useful is a huge emphasis on the importance of tests.  Not just writing tests, but writing them first, or at worst, simultaneously.  And not just ensuring complete test coverage, but writing your code in such a way that tests are easy and natural to write.  Tests not only help you verify proper behavior, which is nice when you're constantly changing things around, they also make you use the API you're designing much earlier, which can clue you in to design problems early, even if all the tests are passing.

Making everything testable has a huge positive impact on your design, because it forces you to modularize things so you can write isolated unit tests with alternate stub/mock implementations of dependencies. Now for games with their heavy graphical component, automated unit tests are probably not so doable.  But everything else should be as easy or easier to test than to use in real-world code.
Offline Roquen
« Reply #34 - Posted 2012-12-11 18:59:56 »

Quote
business apps are often some of the most hacked-up crap you can imagine.
Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code??  Who'd a thunk!

Quote
Good engineering is as much about being able to understand and work with your own code as it is about being robust in the face of change.
Exactly..and in here is part of the "artistic" element.  We all develop techniques and styles as our skills evolve.  Brilliant code today is likely to be bloody-aweful in a few years time.  The bottom line here is there's no replacement for experience...so get off your bottom and program!

EDIT:
OP: I clicked on your blog where you have a mention of Jobs & Richie.  The really ironic thing here is that http://en.wikipedia.org/wiki/John_McCarthy_%28computer_scientist%29 died soon thereafter and is never mentioned in popular press.  It's kinda dicky of me to measure the worth of some person's life...but McCarthy's contributions make Richie's look pretty scant.
Offline Danny02
« Reply #35 - Posted 2012-12-11 19:24:38 »

Quote
business apps are often some of the most hacked-up crap you can imagine.
Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code??  Who'd a thunk!

the point is that most business software is just quickly thrown together code snippets without any methodology.

And pls don't give crappy advice like, use this only when working on a huge cooperate software project, because it doesn't matter for your little game. Let me tell you something, every big software started small and in the beginning a lot of people think like this and end up with some crappy software after some years.

I do work a bit for a little software firm which does software for small industry businesses, there is one project which started small. And the boss told everybody just to finish it as fast as possible, because it was a one time only thing anyways.
Now we ended up making the software at least 5 times bigger and licensing it to several other companies. I can tell you how much fun it is to work with the old l agency code. We had to rewrite a lot of modules just because it is so a big pain in the ass to work with them.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #36 - Posted 2012-12-11 19:32:11 »

I do work a bit for a little software firm which does software for small industry businesses, there is one project which started small. And the boss told everybody just to finish it as fast as possible, because it was a one time only thing anyways.
Now we ended up making the software at least 5 times bigger and licensing it to several other companies. I can tell you how much fun it is to work with the old l agency code. We had to rewrite a lot of modules just because it is so a big pain in the ass to work with them.
And still your boss was (probably) right. It's extremely important to publish a product to client #1, even if it sucks behind the scenes. That first client has to use it first, before it can become a success. Trying to get it absolutely right for client, and you probably never get it good enough, and miss deadline after deadline, before the developers deem it 'worthy'.

Your boss is there to keep the business running, not to win a prize in code quality. That the maintenance is a burden, is just a minor inconvenience - for the business - regardless of what is it to you.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Roquen
« Reply #37 - Posted 2012-12-11 19:33:57 »

There's really something to be said for the "worse is better" model.

Quote
And pls don't give crappy advice like, use this only when working on a huge cooperate software project, because it doesn't matter for your little game.
You should try re-reading what I wrote.  I implied no such thing.
Offline Cero
« Reply #38 - Posted 2012-12-11 19:49:08 »

There's really something to be said for the "worse is better" model.
I think its only important when lives are on stake or big sums of money.

Quote
On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after lift-off.
...
development costing $7 billion
destroyed rocket and its cargo were valued at $500 million
...
software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,768, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
Not really so much a software engineering problem, but still makes me angry that a lazy programmer caused this (more than angry obviously);
IMO space shuttle code should be THE most sophisticated code there is. Maybe on par with CERN code.


Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #39 - Posted 2012-12-11 19:57:31 »

The problem with software engineering, is that, as opposed to the designs of (structural) architects, there is no margin to work with. It either works or it doesn't. When you build a bridge, you typically make it capable of handling 3 times the maximum stress it will be subjected to throughout its projected lifespan. There is no such concept in programming. A single typo or brain fart will bring the entire application down, while a rusty bolt will not affect the structural integrity of the bridge to the extend that it will collapse in the next few decades. So, there you go, there is no safety net in programming, and unless we manage to reliably put complex business logic in neural nets, it will stay this way. Forever.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #40 - Posted 2012-12-11 20:00:12 »

Not really so much a software engineering problem, but still makes me angry that a lazy programmer caused this (more than angry obviously);
IMO space shuttle code should be THE most sophisticated code there is. Maybe on par with CERN code.

The Ariane 5 incident is a *lot* more complicated than "a lazy programmer". The integer overflow is just one piece of a big chain of events that caused the overall failure.

Most interestingly, the code was correct when originally written. The situation couldn't occur on the hardware it was written for, and only later was the same code reused on a different hardware where the error was now possible. You could equally pin the blame on hardware engineers for not having sufficient documentation to describe the differences or on testing for not fully exercising the functionality of the system as a whole. But pinning blame in a complicated failure like that is neither helpful nor interesting.

It's been a while since I read the full investigation report into Ariane 5. Have you read it? I would recommend it for anyone who wants an insight into how tiny errors (both technical and people) can propagate and grow.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Cero
« Reply #41 - Posted 2012-12-11 20:16:40 »

well it is still an unacceptable mistake
you have "all" the time and money in the world to prepare such a system
its just such goddamn waste, and people could have died too, just because some people didn't triple check after all parts were in place

Offline sproingie

JGO Kernel


Medals: 202



« Reply #42 - Posted 2012-12-11 21:08:52 »

Quote
business apps are often some of the most hacked-up crap you can imagine.
Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code??  Who'd a thunk!

No, it's more like they're designed without any methodology in the first place, often by the "guy who knows some programming".  The world of "business apps" is full of one-offs that people thought was throwaway code when written, that's still running 10 years later.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #43 - Posted 2012-12-11 21:10:33 »

Ariane 5 is a great study.  Google "Therac 25" for another case study in design failures and how they compound each other.  This one actually did kill people.
Offline Cero
« Reply #44 - Posted 2012-12-11 22:26:00 »

Ariane 5 is a great study.  Google "Therac 25" for another case study in design failures and how they compound each other.  This one actually did kill people.

Way to make me more depressed on this subject.
Quote
X Ray machine
...
causing him to scream
..
displayed the word "MALFUNCTION"
...
AECL personnel, as well as machine operators, initially did not believe complaints. This was likely due to overconfidence.
You gotta love humans.

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #45 - Posted 2012-12-12 03:11:59 »

I already have packages and classes and I feel like it's organized, but I still have to search through my classes to find certain methods and variables. For example, I'm in the process of drawing the equipment my player has equipped in the UI and it took me a few minutes to trace back through the player class and equipment class where I actually stored the equipment information. Also when I add more character classes(archer, wizard, etc) to my game, I'm going to have to go through quite a few java classes to add functionality for a new character class. I'm worried that it will be easy to miss places that I would need to add code for full functionality. Is this just inherent in bigger games?

I could upload my whole zip file project, but I feel it would be a lot to look through.

What IDE are you using?  Finding methods and variables should be as easy as tab completion.

Adding a new class shouldn't require onerous amounts of work if you have a default implementation (e.g. MouseAdapter implements most of the MouseListener interface).

Probably best if you can post an example.  Then you'll get more distinct feedback.
Offline ReBirth
« Reply #46 - Posted 2012-12-12 05:19:54 »

I love that this thread turning from game dev to human killing program Grin

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #47 - Posted 2012-12-12 09:44:23 »

I love that this thread turning from game dev to human killing program Grin

I don't believe Eclipse has a plugin for that yet. Maybe try Netbeans?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #48 - Posted 2012-12-12 11:25:46 »

This is why I'll never ever write safety critical software. My code is shit.

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #49 - Posted 2012-12-12 17:19:30 »

There's KillAllHumans for IntelliJ but the author hasn't updated it since Idea 8 and there's no reviews, wonder why that is?
Offline ReBirth
« Reply #50 - Posted 2012-12-13 03:39:09 »

I don't believe Eclipse has a plugin for that yet. Maybe try Netbeans?
Just to try that? nah Cheesy

Offline Best Username Ever

Junior Member





« Reply #51 - Posted 2012-12-13 04:57:24 »

The problem with software engineering, is that, as opposed to the designs of (structural) architects, there is no margin to work with. It either works or it doesn't. When you build a bridge, you typically make it capable of handling 3 times the maximum stress it will be subjected to throughout its projected lifespan.

I wouldn't say there's no margin to work with in certain kinds of software projects. It's just that it's between almost working and functioning rather than between basic functionality and working correctly with future problems in mind. Also:

1. Build bridge
2. Use and maintain the bridge for a few years
3. Wonder why you're still putting money into a project that's already finished
4. Keep using bridge for three times the projected lifespan
5. Argue over the best thing to do with the bridge
6. Build another bridge to accommodate more traffic without shutting down the old one
7. Goto 2
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (26 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (34 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!