Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Did you ever cut corners to solve a problem?  (Read 2158 times)
0 Members and 1 Guest are viewing this topic.
Offline EmanP

Junior Member


Projects: 2
Exp: 3 years


Satisfaction never guaranteed.


« Posted 2013-12-07 23:13:01 »

I remembered this, and wanted to share with you.

I was programming with Java2D in my more novice days, and I wanted to make the screen maximized, but so that the user could not resize it. I was perplexed with how to do it. I came up with this, unintended by the Java2D authors, solution: I took the Robot class to manually move the mouse over to the maximize button, and then disabled resizing at the very same second.

Did you ever make a program cut corners or do something that would be frowned upon by others?

EDIT: Wrong discussion section. Can't remove Sad

Signed- EmanP
Offline Drenius
« Reply #1 - Posted 2013-12-08 01:19:52 »

Made my first java game with JLabels, so... yes...
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #2 - Posted 2013-12-08 02:43:51 »

@OP that's actually an impressive way of forcing the user into something, good for you!

I hate cutting corners just because I feel like later on I'll need to do it right, so I try to make myself learn it right the first way. That being said, I remember when I first started out programming my first language was C++ and I knew nothing about loops. Well, I tried to make a simple text based game, and instead of learning how to use loops to keep my program running, I used the GOTO function, which isn't at all recommended, and can cause some issues in large programs. Looking through my source code, pretty much everything had a goto function attached to it. For all of you that don't know, GOTO pretty much tells the code to jump back to a specified method (I believe, maybe you could just jump back anywhere in the code, not just methods.)

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

JGO Knight


Medals: 30
Projects: 2
Exp: 3 years


Zero but not.


« Reply #3 - Posted 2013-12-08 02:50:29 »

I used the GOTO function

Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #4 - Posted 2013-12-08 02:55:41 »

Honest to god, years later that's how I feel! I sit here and laugh at myself for ever considering using that terrible line of code, but I guess we all begin somewhere!

Don't get me wrong, in a small program I'm sure its ok tobuse, but definitely expect the old timers to glare at you.

Offline CodeHead

JGO Knight


Medals: 41


From rags to riches...to rags.


« Reply #5 - Posted 2013-12-08 04:58:38 »

Don't get me wrong, in a small program I'm sure its ok tobuse, but definitely expect the old timers to glare at you.

That depends on your definition of "old timer". Those of us who remember what it was like to write assembly are quite used to the concept. I still find them useful when I have to do VBA development at work. Thanks to the lack of a break or continue statement, they are sometimes the only way to accomplish a given task. Speaking of which, I've had to abuse the monstrosity of "On Error Resume Next" more times than I care to mention.

Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
Offline ags1

JGO Ninja


Medals: 55
Projects: 2
Exp: 5 years


Make code not war!


« Reply #6 - Posted 2013-12-08 18:47:01 »

My development methodology is:

1. Hit problem.
2. Identify corners.
3. Cut corners. All corners.
4. Refactor.
5. Refactor.
6. Refactor.

The number one priority is getting the code working. Once something is working it is easy and fun to improve it. Although admittedly some short cuts can hang around in the code for months before I think of the right way to solve them...

Offline Drenius
« Reply #7 - Posted 2013-12-08 18:48:13 »

Yep.
Offline kingroka123

JGO Knight


Medals: 29
Projects: 5
Exp: 1 year


Gamer's Helmet


« Reply #8 - Posted 2013-12-09 03:00:24 »

Well when i was experimenting with physics the objects going too fast would fall through blocks so i basically just wrote some code to teleport it where it needed to be. It solved the problem tho.

Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #9 - Posted 2013-12-09 03:45:09 »

I used the GOTO function, which isn't at all recommended, and can cause some issues in large programs.

Actually, not really. The evil reputation goto has comes from the old days when you could use it to jump to any point at all in the program. That tremendously increases the cost of maintenance, because any time you edit a section of code you need to be extra careful about updating or removing any gotos if you need to. This was especially true in languages like BASIC and FORTRAN, where you used line numbers to branch around:

1  
2  
10 PRINT "Hello World"
20 GOTO 10


In C and C++, this is no longer an issue. The goto statement (it's not a function) is restricted to the current function scope. You can't jump to arbitrary locations in the program. And, you have to use named labels, so modifying code doesn't modify the point you jump to as it does when line numbers are the target. A common idiom in C, where there are no exceptions, is to use goto for error handling in cases where it makes sense. For example, imagine this totally contrived hypothetical function:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
foo* create_foo( int x ) {
    foo* foo = create_foo();
    if( !foo ) goto FAILURE;

    if( !do_something_with_foo( foo ))
        goto FAILURE;

    if( !do_something_else_with_foo( foo ))
        goto FAILURE;

    return foo;

FAILURE:
    log_error( "Failed to create foo." );
    if( foo ) deallocate_foo( foo );
    return 0;
}


I've done a lot of C over the years and have used this idiom often, particularly in resource loaders. It's a very useful, and very safe, idiom. The evil reputation, which was rooted in real issues, does not apply in modern languages, but still lingers. Much like the Java performance myth.

That said, using goto for loops certainly is considered abuse!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline xsvenson
« Reply #10 - Posted 2013-12-09 09:48:50 »

I don't really like to cut corners, but there are occasions where the code just needs to work and needs to work now... and then never gets changed.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Offline Varkas
« Reply #11 - Posted 2013-12-09 09:51:08 »

Did you ever make a program cut corners or do something that would be frowned upon by others?

Yes, definitely. Just document it well enough so that you later remember why this workaround was made, and how it is supposed to work.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #12 - Posted 2013-12-09 14:18:49 »

Nope, never.

Offline gimbal

JGO Knight


Medals: 25



« Reply #13 - Posted 2013-12-09 14:27:35 »

Yeah sure, always under the guise of "its only a temporary solution".

Of course nowadays I know that there is nothing as permanent as a temporary solution.
Offline ags1

JGO Ninja


Medals: 55
Projects: 2
Exp: 5 years


Make code not war!


« Reply #14 - Posted 2013-12-09 18:04:13 »

If you NEVER have to revisit the code and improve the workaround, then that just proves you were justified in cutting the corner in the first place.

Quote
Of course nowadays I know that there is nothing as permanent as a temporary working solution.

Offline wessles

JGO Wizard


Medals: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« Reply #15 - Posted 2013-12-09 20:27:08 »

What if a raptor attacks you because you cut a corner.

Offline kingroka123

JGO Knight


Medals: 29
Projects: 5
Exp: 1 year


Gamer's Helmet


« Reply #16 - Posted 2013-12-10 00:04:59 »


*Australian accent* Cleva Girl

Offline lcass
« Reply #17 - Posted 2013-12-11 17:22:40 »

LOL, I look back at code I have written 2 months ago and I think really? Often I cut corners but just leaving my methods unfinished so in a "working" state...
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


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

Most of the time i write some hacky prototypes to try out some new ideas.
After a while it gets really dirty (and probably works), then i rewrite it to a more cleaner solution.
Offline cylab

JGO Ninja


Medals: 43



« Reply #19 - Posted 2013-12-12 11:58:13 »

edited to fit the usual day job environment:

Most of the time i write some hacky prototypes to try out some new ideas.
After a while it gets really dirty (and unfortunately works), then my boss comes around and releases the solution into production.

Mathias - I Know What [you] Did Last Summer!
Offline Rayexar

Junior Member


Medals: 2
Exp: 5 years



« Reply #20 - Posted 2013-12-12 12:44:17 »

I can definitely relate to the "temporary working solution". Another corner I cut, although not to solve a particular problem, is using static a lot, because it's quicker and easier, and I don't seem to run into any problems.
Offline Troubleshoots

JGO Knight


Medals: 36
Exp: 7-9 months


Damn maths.


« Reply #21 - Posted 2013-12-12 13:29:00 »

Eww please never show me your code. If I have more than 3 uses of the static keyword in a small project it's refactoring time for me.

Why are all OpenGL tutorials written in Brainf**k?
Offline tom_mai78101
« Reply #22 - Posted 2013-12-24 12:52:26 »

I actually never cut corners. Or in other words, I don't know any corners I can actually cut. Never occurred to me. Nope.

Unless you "define" corners for me. Once you've define a few, and you tell me this and that, I'll first ask you for the reasoning behind all of these, and then ask you to tell me how to "cut" those corners.
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #23 - Posted 2013-12-24 16:35:26 »

I really don't think you're serious but still...

Offline Ghidra

Senior Newbie


Medals: 3



« Reply #24 - Posted 2013-12-30 00:12:21 »

Actually, not really. The evil reputation goto has comes from the old days when you could use it to jump to any point at all in the program. That tremendously increases the cost of maintenance, because any time you edit a section of code you need to be extra careful about updating or removing any gotos if you need to.

I came across the following words when I was teaching myself how to program C out of the Kernighan and Ritchie text:  "C provides the infinitely-abusable goto statement, and labels to branch to.  Formally, the goto is never necessary, and in practice it is almost always easy to write code without it.  We have not used goto in this book" (65, 2nd Edition).

I never even looked at goto again after reading this, given that many regard K&R as the final word on all things C (so, naturally, I did too).  Then, years later, I found myself writing very handy and functional nested loops that needed to exit out of multiple layers when a certain condition or conditions were met.  I started wondering why the hell there isn't a special version of break for this purpose.  So to cope with this deficiency I would declare extra boolean variables to keep track of the nested loop's execution state.  It was only while reading about some of the more obscure features of Java that I rediscovered goto statements--called "labeled breaks"--and cursed myself (and K&R) for having written them off for so long.

As was previously mentioned, they can be incredibly useful and purposeful. 
Pages: [1]
  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.

TehJavaDev (17 views)
2014-08-28 18:26:30

CopyableCougar4 (26 views)
2014-08-22 19:31:30

atombrot (39 views)
2014-08-19 09:29:53

Tekkerue (36 views)
2014-08-16 06:45:27

Tekkerue (33 views)
2014-08-16 06:22:17

Tekkerue (22 views)
2014-08-16 06:20:21

Tekkerue (33 views)
2014-08-16 06:12:11

Rayexar (67 views)
2014-08-11 02:49:23

BurntPizza (45 views)
2014-08-09 21:09:32

BurntPizza (36 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!