I have defined a number of things in my game just to make things shorter and quicker to type really.
Just to name two:
IC = icon
IS = icon_state
I have never actually thought anything of it till now but is it efficient to do things this way?
As I said, I did it to code faster and since i am going out in like a minute. I thought I would ask here rather than try look something up.
ID:151485
![]() Sep 3 2010, 1:22 am
|
|
The time saved up front is also lost (and then some) through poor readability. This is compounded if you are in a group project.
During debugging (which is inevitable, things do go wrong and you are not a perfect machine yourself that writes perfect code first time), it becomes a pain to read. During extension and modification of code you wrote 6 months ago, it becomes a pain to read. The existing language works on the principle of being standard for everyone, across all projects. It becomes natural to read given enough time and practice. Redefining bits of it like that will throw away that time spent and bring you back to zero, usually with less "common sense" cues in names as well. |
Midgetbuster wrote:
And lets be honest are you REALLY that lazy to type out icon_state and icon? i mean come on.. The only answer i can give to that question unfortunately is... Yes, Yes I am. However i do get what you and Ste are saying. You can go to far with this simple defining business. I think i will keep defining icon, icon_state and density simply because it helps the tedious progress of putting a lot of turfs in. As future readability goes i dont think a turf will ever be an issue. |
Stephen001 wrote:
The time saved up front is also lost (and then some) through poor readability. This is compounded if you are in a group project. This is patently false. No time is saved up front. The time spent typing is absolutely negligible compared to the time spent figuring out what to do. |
Tonyth wrote:
I have defined a number of things in my game just to make things shorter and quicker to type really. It's good if you want to fit your game into 8k for the Cartridge Classic contest. That's about it in this case. |
Tonyth wrote:
(...)it helps the tedious progress of putting a lot of (...) in That hints at the fact that you aren't properly using the advantages of the object-oriented programming paradigm supported by BYOND. Inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviours called objects which can be based on previously created objects. |
Schnitzelnagler wrote:
That hints at the fact that you aren't properly using the advantages of the object-oriented programming paradigm supported by BYOND. I have never heard of object-orientated programming before. Sounds like a clever way of copy and paste however I do believe i do something at least similar to the inheritance method suggested by how you described it. turf That is how i would normally compile a turf. |
And this proves the concern that had been raised before. To somebody like me, who doesn't know the context and hasn't had the chance to read the project's functional specification, there is literally no meaning to this mess.
Why are you creating this many different type of 'grass'? Oh and, as you can see, you only had to define density once, so you saved yourself typing four characters and two with icon. Not to mention that you didn't have to explicitly define density at all, given that the default for this variable is indeed zero, so you saved two characters for icon and wasted three defining a variable that you didn't have to, while creating a rather tricky mess of code. |
I could see the point in the whole long list of grasses.
In some games and im going to go out on a whim here and say his is going to be one of those he classifies those as new grasses for say near water near sand or something similar to that. eg. half water and half grass or a grass spot surrounded by water |
I can get how this can be a mess to anyone apart from myself. That to me though is just easier.
If i just take one state: turf It is in the grass directory CI means inside corner TR means top right So this is the Top Right Inside corner for my grass icon and as midget said they are all like half grass half whatever. That is just clear to me and as far as coding a turf in goes personal preference is all that matters really. I have reverted all of the defined abbreviations in all of my main coding systems, as i said in an earlier post. As I agree with what everyone has said in here. On how you can indeed go to far with it. EDIT: I also dont have a clue why i defined density in the turf. Sh*t happens i guess xD |
It's still a huge mess. Even when I had to make oodles of turfs for things like this, I'd call them top_right, top_left_inside, bottom_left_outside, or whatever. Please make note, it took me less than three seconds to type each set of words, and it makes a lot more sense than your mess, which I would have to carry around a manual to understand.
|
DivineTraveller wrote:
It's still a huge mess. Even when I had to make oodles of turfs for things like this, I'd call them top_right, top_left_inside, bottom_left_outside, or whatever. Please make note, it took me less than three seconds to type each set of words, and it makes a lot more sense than your mess, which I would have to carry around a manual to understand. lol ^_^ |
And lets be honest are you REALLY that lazy to type out icon_state and icon? i mean come on..