Hi, i heard bad coding can be a major problem with games and can can slow them down, but how do you know if your code is sloppy or what is sloppy coding?
Thanks for reading.
http://martijnvanbeek.net/weblog/78/sloppy_code.html
First hit on google…
And in terms of game performance unoptimized code is what you want to look for. Like for example performing checks every frame instead of once in the start of the game. I’m sure you can find numerous examples of unoptimized code on these forums and on google.
Sloppy coding is usually used to describe when a piece of code isn’t very expandable or versatile. Like it works now, but try to add or subtract something and it breaks the whole thing. People also sometimes call it “hacky”. Kind of like if you have to fix a broken shelf in your house. If you stick it back up with duct tape that would be sloppy, if you bring out the tools and do it right it will take longer, but it will work better.
If you are a beginner don’t worry about having sloppy code. If you are new your code WILL be “sloppy” and there is nothing you can do about it. As you progress and learn, your code will get cleaner and more efficient.
Usually means poorly structured, lack of planning ahead, etc. It would also include lack of decent commenting and documentation.
“Hacky” can be sloppy, but I’ve seen some ingenious and totally surreal code that contradicts that. Especially when it does things that shouldn’t be possible.
Sloppy coding is a construction-phase problem (as opposed to a design-phase problem). It often happens when you don’t allocate enough resources for construction and do-it-yourself, pay someone incompetent, or ask your construction team to take shortcuts. Poorly constructed code is usually cheaper up-front, but you end up paying much more in long-term costs when your code’s unreliable, low-performing, difficult to understand, expensive to debug, expensive to extend, and/or not re-usable.
If you want to learn the technical details of software construction and good vs sloppy coding, a great book focused mostly on that subject is Steve McConnell’s “Code Complete”.
As with a house, some signs of shoddy construction are obvious, but some you won’t notice for days, weeks, or months without the help of a trained inspector. If someone’s authoring alot of code for you, it may make sense to have a second programmer to code review selected bits of their work. Ask them to be specific in their criticisms and give the original programmer a chance to respond.
Requirements * Architecture * Construction * System Test * Post-release
You’ve only mentioned construction (coding). Even before construction comes the design phase. It’s cheaper to identify most problems during design than to identify them during construction or testing. If you hire a team to build a house with a basement, and only after they dig for a couple days realize the basement’s below the water line and the walls won’t support the roof, you’ve wasted money!
Agreed. You generally want to avoid hacks, but sometimes they’re a necessarily evil, and their existance in code especially if well-documented doesn’t imply sloppiness. When MacGyver stops a nuclear meltdown with a sticks of chocolate, it’s hacky, but not sloppy. Now, if the original designer of the nuclear facility sealed everything with melted chocolate bars, that’s both hacky and sloppy!
Sloppy code is usually caused when you code before you think, and when your goal is getting the current feature to work at the expense of future development.
To me it means it’s written with the aim of getting it to work as quickly as possible regardless of how efficient it is, ie not very optimized, using a lot of higher-level stuff which is slower, etc.
Indeed…do not give into the temptation to make quick-fix hacks, no matter how much it seems like “hey, it can’t hurt, and I don’t feel like completely redoing this code”. You WILL regret it later. Speaking from experience.
–Eric
exactly
Sloppy coding is easy and quick to do.
But it always slows you down over time, and costs more in terms of maintenance.
See “Technical Debt”
It really depends on the problem you are solving. Often it might turn out to be faster and better to build one to throw away. The perfect architecture (for a big scale project) cannot be foreseen, no matter how hard and long you think before you code. It is something that will evolve during the development. You might spend days even weeks thinking about the structure of your code, the objects that you want to have and not get anywhere. Flaws in the design will become aparent only at later stages.
Finally, even with bad design the code can still be functional.
Take for example latin alphabet vs chinese alphabet. Latin alphabet is good design, symbols representing sounds, combine few symbols to build words. Chinese alphabet, each symbol represents a word, terrible design if you ask me, yet, functional. (Over a billion people use it after all).
If you can envision the correct design from the start, this will save you time and effort. So think hard before you code but don’t think too long or you will fall into a deadlock. If you feel you are not making much progress on the design anymore, just start coding. If later you find out you have a bad design, you can start over or live with it depending on the situation. Even if you start over, the time you spent so far is NOT wasted. You can usually save the algorithms that you used, and now you do have a better design in mind, don’t you.
I’m trying to optimize my mind-blowing
if (..) {..} else { if (..) {..} else { if (..) {..} else {..}}}
where “…” some code up and come with solution:
switch (true) { case .. : .. break; case .. : .. break; case .. : .. break; case .. : .. break; }
Is it still spaghetti/sloppy coding? 
Sloppy coding is all my work. Especially when I’ve had a pot noodle over the keyboard.
switch (true)
If this is C#, your new code won’t compile. If the switch expression is of type boolean, you can have at most three cases (true, false, default) and your has four. Beyond that, it rarely makes sense to use a switch statement when the switch statement expression is a constant. And it’s rarer still that using a switch statement is the right choice when we’re dealing with boolean values. At least it’s not spaghetti code. 
Nah - it is actually working (I got 3 cases now, any of them will execute if condition is “true”, and only one would run, since there is a break). Sure this is JavaScript (or so called “UnityScript”, name copyright and trademark by dreamora).
It figures! Unityscript blasphemy. It’s an interesting tool. I would probably avoid it when if/else would do just as well, but I could see it simplifying code in some cases.
I often simplify complex if/else logic by factoring out the common situations between them, revising my variables as my old ones aren’t serving me well, or switching to a state machine.
Sloppy coding is nearly indistinguishable from drunk coding, except that sloppy coding doesn’t use repeat loop as often or create corrupt bidirectional relationships, both however do result in dangling pointers. In addition unlike the close cousin of both apathetic coding it does correctly terminate lines.
Sloppyness in generally just means being lax about maintaining a standard approach to formatting of your code and code safety, not being a defensive coder (i.e. not checking after allocations that the object exists, allowing dangling pointers to exist), more or less you can say any bug in code that is your own fault and results in any poor IO/Memory management is caused by sloppy coding, in addition any spaghetti code that others cannot read and maintain can also be attributed to sloppy coding, you can see it’s really an umbrella term for not paying attention and making mistakes, which everyone in fact does. It doesn’t necessarily cover all bad code though, for instance sometimes bad code can be quite intentional and quite brilliant in it’s own way, but it’s still nasty as hell. If you want an example of truly evil coding practice that’s really highlighting problems in compiler practices then look up Duffs Device. That’s a good example of evilness that’s not sloppy. There’s also intentional obfuscation and many other hard core coding tricks that people use that while inherently “bad” and perhaps to the untrained eye may appear sloppy which are in fact only evil when used in a group project situation.
Here’s a few examples:
Everything in Main.
One gigantic source file,
Global variables everywhere.
No error checks.
Use the wrong type of syntax for a certain situation, example, tons of nested for/next loops when a switch/case could be used.
Declare inappropriate variable container types or sizes, ie: int instead of a bit or boolean for true false.
No optimization. The ‘It runs’ attitude.
I think I’ll stop here because we could write a book on bad/sloppy programming.
Edit: Oh, just saw some people already wrote some of what I wrote… See what I did (didnt read all posts in thread) is probably sloppy forum posting 
indeed. It is sloppy forum posting