Did you ever cut corners to solve a problem?

[EmanP]

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

[Drenius]

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

[opiop65]

@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!

[NegativeZero]

I used the GOTO function

[opiop65]

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.

[CodeHead]

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.

[ags1]

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...

[Drenius]

Yep.

[kingroka123]

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.

[aldacron]

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!

[xsvenson]

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.

[Varkas]

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.

[ClickerMonkey]

Nope, never.

[gimbal]

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.

[ags1]

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.

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

[wessles]

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

[kingroka123]

I used the GOTO function

*Australian accent* Cleva Girl

[lcass]

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...

[RobinB]

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.

[cylab]

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.

[Rayexar]

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.

[Troubleshoots]

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.

[tom_mai78101]

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.

[opiop65]

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

[Ghidra]

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.