Did you ever cut corners to solve a problem?

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 :frowning:

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

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

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.

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.

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…

Yep.

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.

[quote=“opiop65,post:3,topic:45476”]
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:


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:


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!

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.

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

Nope, never.

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.

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.
[/quote]

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

Australian accent Cleva Girl

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…

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.

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.