Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

The point where you cease to understand how your code works

Discussion in 'General Discussion' started by keithsoulasa, Jul 16, 2012.

  1. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    1,984
    Anyone their yet, I just added extra code to force the non-working code to act right ...
     
  2. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    5,215
    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.
     
  3. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    1,984
    I needed to ram more functionality in my app though , so it happens ....
     
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,727
    its all about experience, come back in five years with a new set of problems to moan about :)
     
  5. ZeroByteDNA

    ZeroByteDNA

    Joined:
    Jun 18, 2012
    Posts:
    1,042
    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.
     
  6. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,287
  7. Morning

    Morning

    Joined:
    Feb 4, 2012
    Posts:
    1,141
    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 :)
     
  8. dogzerx2

    dogzerx2

    Joined:
    Dec 27, 2009
    Posts:
    3,854
    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!
     
  9. diddykonga

    diddykonga

    Joined:
    Jun 9, 2011
    Posts:
    151
    Tbh, if your forgeting how your code works, you shouldnt be typing that piece of code anyways (or copying and pasting from where ever)
     
  10. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    1,984
    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
     
  11. Democre

    Democre

    Joined:
    Mar 31, 2010
    Posts:
    345
    spaghetti for the win!

    Because, yea, that'll work out in the long run.
     
  12. JohnnyA

    JohnnyA

    Joined:
    Apr 9, 2010
    Posts:
    4,764
    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.
     
    Last edited: Jul 16, 2012
  13. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,462
    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.
     
  14. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
    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.

    Gigi.
     
  15. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,615
    I mainly find myself lost in complex data structures... thats about it tho.
     
  16. kingcharizard

    kingcharizard

    Joined:
    Jun 30, 2011
    Posts:
    1,137
    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...
     
  17. drewradley

    drewradley

    Joined:
    Sep 22, 2010
    Posts:
    3,063
    For me, it comes shortly after the word "Using".

    Kidding.

    Mostly.

    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!
     
  18. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    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.
     
  19. Stephan-B

    Stephan-B

    Unity Technologies

    Joined:
    Feb 23, 2011
    Posts:
    2,269
    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.
     
  20. ZeroByteDNA

    ZeroByteDNA

    Joined:
    Jun 18, 2012
    Posts:
    1,042
    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.
     
  21. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
     
  22. shaderbytes

    shaderbytes

    Joined:
    Nov 11, 2010
    Posts:
    900
    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.
     
  23. Foam

    Foam

    Joined:
    Jun 13, 2012
    Posts:
    322
    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.
     
  24. khanstruct

    khanstruct

    Joined:
    Feb 11, 2011
    Posts:
    2,865
    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.
     
  25. SevenBits

    SevenBits

    Joined:
    Dec 26, 2011
    Posts:
    1,953
    Immediately after I write it... :)
     
  26. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,777
    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.
     
  27. mada

    mada

    Joined:
    Jul 2, 2012
    Posts:
    53
    I was going to write something like this last night, but was too lazy. Thanks :)
     
  28. Khyrid

    Khyrid

    Joined:
    Oct 8, 2010
    Posts:
    1,781
    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.
     
  29. jasonkaler

    jasonkaler

    Joined:
    Feb 14, 2011
    Posts:
    241
    +1 here.

    A good tip I found:
    Write your comments first, then your code.
    e.g.
    First add
    // 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).
     
  30. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    1,984
    implementation specifics

    Its just one thing thats not acting right , i basically wrote an over ride to force it to act right
     
  31. Vert

    Vert

    Joined:
    Mar 23, 2010
    Posts:
    1,093
    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.
     
    Last edited: Jul 18, 2012
  32. SevenBits

    SevenBits

    Joined:
    Dec 26, 2011
    Posts:
    1,953
    Sometimes, though, design is so easy that I never need to plan.
     
  33. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,777
    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.
     
  34. RicheyMB

    RicheyMB

    Joined:
    Jul 20, 2009
    Posts:
    111
    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.
     
  35. RicheyMB

    RicheyMB

    Joined:
    Jul 20, 2009
    Posts:
    111
    I loves this :)
     
  36. Democre

    Democre

    Joined:
    Mar 31, 2010
    Posts:
    345
    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.
     
  37. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,240
    Erm, nothing? It's not like Unity Technologies suddenly vanishing would cause the engine to stop working.

    --Eric
     
  38. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,777
    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.
     
  39. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    799
    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.
     
  40. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    1,984
    With most of my code if it fails I'm screwed anyway, its fun to be young and reckless ...
     
  41. returnString

    returnString

    Joined:
    Jul 10, 2010
    Posts:
    248
    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.
     
    Last edited: Jul 20, 2012
  42. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    5,215
    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.
     
  43. HarvesteR

    HarvesteR

    Joined:
    May 22, 2009
    Posts:
    499
    ^^ 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. ;)

    Cheers
     
  44. ShadoX

    ShadoX

    Joined:
    Aug 25, 2010
    Posts:
    255
    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.
     
  45. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,293
    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).
     
    Last edited: Jul 20, 2012
  46. lmbarns

    lmbarns

    Joined:
    Jul 14, 2011
    Posts:
    1,474
    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.
     
  47. ZeroByteDNA

    ZeroByteDNA

    Joined:
    Jun 18, 2012
    Posts:
    1,042
    Discussions about these studies popped up earlier in the year:

    http://www.sciencenews.org/view/generic/id/338406/title/Vodka_delivers_shot_of_creativity/
     
  48. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,293
    And it's not only booze.
     
  49. ColossalDuck

    ColossalDuck

    Joined:
    Jun 6, 2009
    Posts:
    3,246
    Lol, I do it all the time. Of course, I hate it after, and redo it so I can understand it.
     
  50. MrProfessorTroll

    MrProfessorTroll

    Joined:
    Sep 1, 2013
    Posts:
    383
    I made a game a few years back, tis was my first game, and looking at the code makes me wanna cry
     
unityunity