A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'General Discussion' started by keithsoulasa, Jul 16, 2012.
Anyone their yet, I just added extra code to force the non-working code to act right ...
Nope. If it ever gets to that point, it's a poor reflection on my organization skills. I have taken over codebases that were so broken like that, though. That's when it's time to refactor.
I needed to ram more functionality in my app though , so it happens ....
its all about experience, come back in five years with a new set of problems to moan about
I used to skip typing comments. I used to come up with all sorts of shorthand for variables, functions, etc. I used to lump as much code into a single file as I could.
Then I got older...started forgetting where I put the keys, couldn't find the TV remote, would get up to go do something and completely forget what it was...ahem.
I now type comments (Hell, I even put comments in the lolcode post in another thread), try to come up with very clear names for variables/functions/etc, and I try to keep as little code in a single file as possible - each of the files nicely named and placed within a clear folder structure.
I used to code faster, imho - but going back and looking at some of the old stuff...I've got no clue what I was trying to do...meh.
Big ball of mud
After some attempts I found that coding in "modular" fashion is the easiest way to organize, at least for me. Components have to be as independent from each other as possible unless they belong in a "family". For example skills or weapons could depend on some kind of manager but that manager should be able to work standalone as long as it gets all info passed to it. So instead of fetching from some "mana" variable, you just use a skill and send an int to it.
Another thing I do is have "dummy" functions that call other functions so that I can easily replace entire modules without having to seek every function name and rename it.
I also draw visual maps of my code and modules. Both before coding and during. Helps navigating a lot.
Obviously this is not as fast as doing a more direct approach, but optimized code is hard to read. No premature optimization
Yeah, I find the "modular" thing to work very well. Now I try to do small pieces of code my brain can handle, that I just know they work, and try not to touch them.
And next item should be a new script, if possible not related to previous stuff.
If something isn't working well, it's a lot easier to debug, and spot the source of the problem.. you can disable the scripts that you suspect are giving you trouble, and see what happens right away. It's like commenting out code...but better and faster!
Tbh, if your forgeting how your code works, you shouldnt be typing that piece of code anyways (or copying and pasting from where ever)
its all my code, but I just ran into a bug where it was doing something I really didn't want it to .
So I just coded a ugly , but functional workarround
spaghetti for the win!
Because, yea, that'll work out in the long run.
Occasionally, particularly back when I used to work in R&D, I will get in zone where I have a complex problem in my head and code a solution without consciously understanding everything I have done. Usually I can go back and figure it out but generally its not worth the effort, if the function passes it test cases then its okay by me*.
These days the problems tend to be complex because they have lots of parts, but each part is quite simple, so it doesn't really happen anymore.
* The function is a black box but its external behavior is well understood so it can easily be tested or replaced.
Badly written code/architecture. Methods are too long, code is not refactored.
Usually if you avoid the above you should always know what your code is doing.
Optimize the right thing: your engineering time. This is your most valuable resource. This means: small functions, unambigious names (even if long), never pre-optimize for performance (adds complexity), add comments, fewer behaviors, fewer interactions, less coupling between things, ...
In one word? Simplicity.
I mainly find myself lost in complex data structures... thats about it tho.
When i write my code I write it one of two ways..
1. if I'm the only one who will be working with the scripts i write them how i feel comfortable and how i can work fast.
2. If I'm writing for someone else i usually take my time try to optimize it to the best of my ability and make it clear to read with many comments..
If your code cause a bug and you couldn't look over the previously written code and figure out the problem its a problem for you.. this has happened to me a few times and I re wrote everything and tested bit by bit.. I would also optimize my code the best i can....
I think you should re write your code, all of it. Why would i suggest this? Simple your workaround may cause future problems and bugs which are worse than the original bug you ran into now.. you need to start over and deBUG your code. You don't have to, but if I was you I would...
For me, it comes shortly after the word "Using".
Actually, I've surprised myself with how much I've learned (re-learned really) since picking up Unity a couple of years ago. I used to know just enough to mess things up. Know I know enough to REALLY mess things up!
I write my code to be innately self-documenting so even if I forget how something works it's pretty easy to understand how it works. I also try and avoid spaghetti code at all costs since a game should be as elegant internally as it is externally.
Sometimes I wish I could get a CPU and RAM upgrade.
Unfortunately brain surgery isn't up to my standards yet so I don't want to risk it.
Have to wonder, how many people picked up certain habits in regard to how they code...based on trying to build something of a security net at a job.
"Oh man, his code is so hard to read...we need to try to keep him around."
As well as the aversion to documentation, sort of thing.
TheOfficeGuy: Don't forget to document your changes.
TheCubeGuy: Uh...yeah...sure...I'll get right on that.
Patching code functionality errors is always a no no, it might seem like a good idea at the time , a short cut quick fix - but ultimately it promotes a convoluted and unstable architecture , with each patch of this nature you loose control of whats actually happening and when many such patches combined start to cause problems you will be playing guessing games and moving bugs around.. Endeavour to make sure you have a clear understanding of why its behaving badly and alter your code to fix it properly.
I cease to understand how my code works about every 30 minutes. It's called a bug. Assuming I write bugs, which I don't.
That aside, the previous poster is correct---if you want to get from point A to B, it's ok to slap a bunch of crap together to get a feel for the end result, but that doesn't mean you keep the code like that for forever (or even for the day). Cludge to fix other cludge will eventually screw you.
But, again, nothing wrong with vomiting up a bunch of code real quick if you need to test a game/app mechanic or just get the feel for how something will eventually work.
I was once on a 15 hour programming stint, trying to get a bit of code working. Somewhere near the end, I fell asleep at the computer (but managed to keep typing). When I woke up, my code was working... still no idea how it works.
Immediately after I write it...
If you don't understand how it works, that implies to me that you skipped design and went straight to coding.
There's a big difference between not remembering implementation specifics about parts of your code and not understanding how it works in general. The former is perfectly normal, the latter is a recipe for disaster. Consider a team environment, where there's a number of other people implementing code which interacts with your own but which you know few if any specific details about. If you're all working to a common design, no problem. If you're all just winging it, integration is going to be a consistent nightmare.
I was going to write something like this last night, but was too lazy. Thanks
I forget my logic, I fully understand what I'm designing but I forget how I was using a variable or what object was handling initiating firing off various functions etc. I have started to write detailed explanations for my code at the top of every script in addition to normal comments throughout the script. It has helped a lot.
A good tip I found:
Write your comments first, then your code.
// This procedure adds two numbers
Then write the method that does exactly that.
If you're coding something other than what your comment says, you're on the wrong path (You're going to have a bad time).
Its just one thing thats not acting right , i basically wrote an over ride to force it to act right
Been there, I hate it when I don't program enough and forget little nuances with how certain functions(mine or library) work. Usually tracing the code helps.
I am a heavy user of comments now. Learned quickly in school when I had to drop working on something and pick it back up later as fast as possible that clean well documented code is a savior of your own time. I mean, why not bang out a few functions between classes? Nothing like having stop and go limited time programming to force good habits just so you don't spend hours on a short assignment trying to rethink your own logic/code to find out where you stopped or why something doesn't work.
Sometimes, though, design is so easy that I never need to plan.
Sure, but refer back to what shaderbytes said.
It all starts with "just one thing". If you don't know why it was misbehaving in the first place, you have no idea what other problems the unknown behaviour may cause in the future. And if/when something does pop up, the problem is compounded by the fact that there's two conflicting pieces of code. If you change something in the original, then your changes will have unexpected results because of the override, which is (probably) undocumented in the original code because you couldn't find it in the first place. This essentially means that your code slowly becomes a minefield of unpredictable logic traps.
Still... in a production environment where the number one priority is to get the job done, sometimes the pragmatic approach is to kludge your way out of a problem to buy time to fix it later. The important thing is that you then set aside time to fix it as soon as possible. Hopefully you have the support of your managers/project coordinators in that. The ones who don't understand software development will just say to get on with the next thing. The ones who do understand it will give you a day or two now knowing it's a massive time and risk saver later on down the track.
Weighing up the benifit of getting something fixed verses getting something finished is a constant battle. At the company I work for we liken it to debt. We can borrow the time from here but we'll have to go back and fix it later, which will take us longer to do as we'll have to get to this point in the process again and it may have cost xxx in support because the problem isn't fixed.
I loves this
I've been to several conference topics on this. They call it technology debt. It's just as real as the costs of licensing and staff salaries. It's not just related to the time it takes but also costs of switching to better tools or license models.
For example most of us in these forums have a technology debt in our projects just from using Unity. It's not a huge debt or a realized debt at the moment, but what would happen if Unity suddenly folded before your project is completed? How much would you have to recode? How much would you have to spend on a new engine? It most likely won't occur, but that doesn't reduce the debt. Finish the project to pay off the debt.
On a smaller scale we incur debt by our choice of language in Unity.
Erm, nothing? It's not like Unity Technologies suddenly vanishing would cause the engine to stop working.
That depends on a lot of things, though, doesn't it? If you're making your game on a platform where Unity has to keep itself up to date in regards to changes - iOS for instance - then if Unity did go bust the clock would start ticking as to when your product couldn't keep up due to reliance on outdated middleware. That might not matter for some projects, but it might matter for others.
One thing I always wonder when looking at other people's code around here is that you guys rarely use Try/Catch blocks. Is your code that rock solid or do you just hope that nothing will ever go wrong? Personally, my first iterations of scripts usually come without any safety measures to test out whether my approach works in the first place, but I try to catch (har) most potential errors later.
Also, +1 on component based game development. Still got to remind me to break down my code into smaller components every now and then.
With most of my code if it fails I'm screwed anyway, its fun to be young and reckless ...
Exceptions are just that, exceptional. More often than not, they're a sign that something else isn't working correctly, and you actually want them to be thrown to help you diagnose the problem. Try/catch is also a fairly rare thing in games, not least because exceptions are moderately expensive.
Only throwing them is expensive (causes a stack rewind). Usually best to catch exceptions at the bottom level, so you know exactly what went wrong, otherwise, you have to run through a trace of inner exceptions and stack traces to pinpoint the problem. You should try/catch exceptions when doing things like File IO, Network IO, (ie, things outside of your control), especially when you need to do cleanup work or recovery. But it's silly to try/catch something like array handling (etc), when you should just validate the bounds yourself before processing.
^^ What he said. Try/Catch blocks aren't meant to patch up faults in logic. They're meant to be used to gracefully handle an exception from some system you had no control over (like reading files which could be user-tweaked), and throw a pretty error dialog, instead of letting the program crash.
If you're using Try/Catch blocks to ignore logic errors, you're doing it wrong.
About implementation practices, one thing I frequently find myself using is what I call the placeholder-to-final method. Basically, your first version of anything is a very quick, hacky job just to get it working, to see how the system/feature performs and feels to the user. Then, as you continue working on it, you rewrite the old code or just dump it and start again, now knowing what the road ahead looks like. Yes, it means having to do some work twice, but if there's ever a time to rewrite a hacky system, it's as soon as you're done hacking it up.
I only run into such situations when I haven't slept a lot for days or when I'm drunk. Except that when I'm drunk I usually end up writing code that works, but end up having no idea on the next day why it works w/o taking 5~10 min to check it again.
I appreciate bugs in procedural code, sometimes you stumble over very interesting things you otherwise never would come up with. Beside of this hunting down those bugs can help you to understand things on a deeper level. Coding whilst being drunk is great fun, everything, well, the important part, is under control then. Coding whilst falling asleep is no fun at all, you produce tons of bugs, stare at the source and oversee things over and over again, you must be afraid of that you hands cause unwanted input, etc and this code is a pain to fix the next day(s).
I just had to use try/catch to handle exceptions for the first time for a java program for school last week. Never used it prior to that. It was to handle errors if the user supplies the wrong input file, or if they enter invalid input into text fields.
In my unity projects I usually just add code as I implement features, eventually there is a ton of code, but it's all just features I wrote, not sure how I would stop understanding how it works unless you're trying to hack up other people's code. But then again you can always debug.log to track the flow of the program to make sure things trigger properly and are working with the right data.
Discussions about these studies popped up earlier in the year:
And it's not only booze.
Lol, I do it all the time. Of course, I hate it after, and redo it so I can understand it.
I made a game a few years back, tis was my first game, and looking at the code makes me wanna cry